Skip to content

Context-Tagged Namespace Partition

Isolation partition — instantiates Context-Keyed Representation Switching

Carves the one shared substrate into per-context tagged regions so each representation lives in its own namespace — the same name resolves to a different map depending on the active tag, and inactive maps sit walled off rather than overwritten.

If several context-specific representations share one substrate, the first thing that can go wrong is that one silently overwrites or contaminates another. Context-Tagged Namespace Partition is the structural artifact that prevents that: it qualifies every name by the active context tag, so the same identifier resolves to a different representation per context, and each context's map physically lives in its own region. Its defining contribution is isolation by construction — a write made under one tag cannot land in another tag's space — and, as a consequence, inactive contexts' maps persist intact in their own partitions instead of being clobbered. It draws the walls; it does not decide which side of them you are on.

Example

Split-horizon DNS is exactly this artifact. The hostname intranet.acme.com resolves to a private 10.x address when the query comes from inside the corporate network, and to a public address — or nothing — when it comes from outside. One name, one resolver substrate, two representations, selected by a context tag (the source network, or "view"). The partition is what keeps the internal view from leaking into the external one: an update to the internal zone lands only in the internal partition and cannot corrupt what the outside world sees. Generalized, that is a Context-Tagged Namespace Partition — every lookup is implicitly qualified by the active tag, and each tag's map is walled off from the others on the shared substrate.

How it works

Its distinguishing move is providing isolation, not selection. Every name is implicitly tagged by the current context, so operations are scoped to one partition by construction rather than by a rule someone has to remember to check. Because each context owns a region, the maps for contexts that are not active simply sit there — intact and ready — which makes the partition double as the inactive store. Something else entirely decides which tag is active; the partition's only job is to guarantee that whatever is active cannot reach across the wall into what is not.

Tuning parameters

  • Partition granularity — one namespace per context versus shared sub-regions. Finer partitioning gives stronger isolation but duplicates anything that could have been shared.
  • Boundary hardness — hard walls (physically separate stores) versus soft ones (tag-prefixing on shared storage). Harder resists leaks and side channels but costs more to run.
  • Shared-versus-partitioned split — what stays common across all contexts (true invariants) versus what is per-context. Over-partitioning fragments things that should be shared and creates drift between copies.
  • Default/unqualified handling — what a name with no tag, or an unrecognized tag, resolves to.

When it helps, and when it misleads

It is the right foundation wherever the same key legitimately means different things in different contexts and cross-contamination is the primary risk — you want each map coherent and untouchable from the others.

Its signature failure is the leaky partition: a shared global, a cache, a log, or some side channel gives false isolation that was never actually tested, so contexts bleed into each other through the seam you forgot. The classic misuse is assuming "we tagged it" is the same as "it is isolated," and shipping without ever probing the boundary. The discipline is to test the boundary with an interference probe and to keep genuinely shared invariants in a deliberate shared layer rather than duplicating them per tag, where they will silently diverge.[1]

How it implements the components

  • shared_substrate_scope — it defines the one substrate that hosts every representation and the extent it carves up.
  • representation_isolation_boundary — the per-tag walls are the isolation boundary; a write under one tag cannot reach another's region.
  • inactive_representation_store — because each context keeps its own partition, the maps of inactive contexts persist there intact, ready for re-activation.

It does NOT select which tag is active — that is Context-to-Map Routing Table's and Gated Expert Router's — and it does not isolate representations that share learned parameters, which is Selective Parameter Freezing's job.

Notes

The partition holds maps apart but neither chooses among them nor tests its own tightness. Its isolation is only as real as the boundary — a partition with a shared side channel is isolation on paper only — so it depends on an interference probe to earn trust, and on a deliberate shared layer for the invariants that should not be duplicated per context.

References

[1] Split-horizon DNS resolves the same hostname differently depending on the querying context (network view), each view isolated from the others. It is a concrete instance of context-tagged namespacing; its failure modes — a leaked internal record, a shared cache serving the wrong view — are the general leaky-partition risk in miniature. ↩