Skip to content

Context-to-Map Routing Table

Dispatch table — instantiates Context-Keyed Representation Switching

A declarative lookup that maps each context key to the representation it should activate — the explicit, auditable dispatch table at the center of the switch.

At the heart of a context switch is a single question — given this context key, which representation? — and Context-to-Map Routing Table answers it as data, not code: an explicit, enumerable table whose rows pair each context key with the map it selects. Its defining virtue is that the selection logic is inspectable and changeable — adding a context is adding a row, and you can read off exactly what any key resolves to without tracing through branching logic. It presumes the context has already been resolved to a clean key upstream and that the maps themselves live in a store; its one job is the transparent lookup that turns a settled key into an active representation. It is the classic dispatch table, applied to representation switching.

Example

A globally-deployed application must format numbers, dates, and currencies correctly per locale. The context key is a locale identifier — de-DE, en-IN, ar-EG — and the routing table pairs each with the formatting map it should use: decimal comma versus point, digit-grouping style (1,00,000 versus 100,000), calendar and numeral system. At render time the app reads the active locale and dispatches through the table. Supporting a new market is a new row keyed to its locale, not a rewrite of formatting logic — and anyone can audit the table to see precisely what ar-EG will produce. The real-world locale data behind such tables (as standardized in CLDR/ICU) is this mechanism at production scale.

How it works

Its distinguishing property is that the mapping is declarative and auditable: an enumerable set of key→map rows rather than imperative selection logic, so the routing is transparent, diffable, and editable without touching behavior. It does no perception — it trusts that a cue model or disambiguator has already handed it a clean key — and it does no storage of the maps themselves. A match policy (exact, longest-prefix, priority order) breaks ties when keys overlap, and misses are meant to be surfaced, not silently absorbed.

Tuning parameters

  • Key design — how contexts are encoded as keys: flat identifiers versus composite or pattern keys. Composite and pattern keys generalize across many contexts but risk overlap and ambiguous matches.
  • Match policy — exact match, longest-prefix, or priority-ordered rules, which determines how overlapping keys are resolved.
  • Miss handling — what happens on a key with no row: an explicit hard error versus deferral to a fallback. Silent defaults hide coverage gaps.
  • Update discipline — how rows are added, reviewed, and versioned as new contexts appear, so the table does not drift from reality.

When it helps, and when it misleads

It is the right tool when contexts are enumerable and you want selection to be transparent, auditable, and changeable as data rather than as code — the case for most rule-driven dispatch.

Its characteristic failure is table drift: reality grows a context the table lacks, so it misroutes or silently falls through to a default, and stale rows keep pointing at retired maps. The classic misuse is a catch-all default that quietly swallows unknown contexts — making the table look total while it is really guessing. The discipline is to make misses loud, review the table against the live distribution of contexts, and hand a genuine "unknown" to an explicit fallback that announces it rather than a default row pretending to know.[1]

How it implements the components

  • context_key_space — its rows enumerate and give structure to the space of context keys the system recognizes.
  • representation_selection_rule — the table is the selection rule, expressed declaratively: key in, representation out.

It does NOT perceive or resolve the context — turning raw cues into a clean key is Gated Expert Router's (soft) and Finite-State Map Selector's (stateful) work — and it does not define the behavior for an unrecognized key, which is Safe Default-Map Fallback's.

Notes

It selects but does not perceive. A wrong key handed in yields a confidently-wrong map out, so the table's correctness rides entirely on whatever resolves the context upstream — the table cannot detect that it was given the wrong key, only faithfully route it.

References

[1] A dispatch table (or virtual method table) selects behavior by looking a key up in an explicit table rather than through branching code — the declarative, auditable form of selection. Its perennial weakness is the silent default: a catch-all row that makes the table look complete while hiding every context it never actually anticipated. ↩