Skip to content

Shared Backbone with Context Adapters

Architectural pattern — instantiates Context-Keyed Representation Switching

Keeps one shared trunk that every context reuses and swaps only a small context-specific adapter, so switching maps means changing the adapter, not the whole model.

Shared Backbone with Context Adapters factors every context-map into two parts: one large backbone that captures what all contexts have in common, and a small per-context adapter that specializes it. Switching context means swapping the tiny adapter while the backbone stays resident. Its distinguishing idea is that it makes the shared substrate explicit and deliberate — instead of maintaining a separate full map per context, or averaging them into one mediocre map, it isolates the true common ground once and expresses each context as a thin delta on top of it. Because the backbone persists across a switch, it is the bridge between contexts; only the delta changes.

Example

An enterprise assistant serves the Legal, Medical, and Engineering departments. Each needs a different map of terminology, tone, and citation rules, but all three share ordinary language competence. Three full models would be expensive and would share no learning; one averaged model would be mediocre for each. A Shared Backbone with Context Adapters keeps a single large backbone and attaches a small department adapter on top. A query from Legal followed by one from Medical simply loads the Medical adapter over the same resident backbone. The company gets three genuinely specialized behaviours at a fraction of three-full-models' cost — and when it improves the backbone, all three departments get better at once.

How it works

  • Factor each context-map into a shared backbone (common to all) plus a small context-specific adapter (the delta).
  • Keep the backbone resident and store the adapters cheaply.
  • Switch context by swapping the active adapter over the fixed backbone.
  • Improve once, propagate widely: a backbone change lifts every context; an adapter change alters only its own.

Tuning parameters

  • Backbone / adapter split — how much capacity lives in the shared trunk versus the per-context adapter. More in the backbone means more sharing and less specialization; more in the adapters, the reverse.
  • Adapter size — larger adapters specialize harder but cost more per context and dilute the "thin delta" benefit.
  • Backbone mutability — a frozen backbone is stable and safe for all contexts; a jointly-updated one adapts but ripples every change to every context.
  • Adapter composition — one adapter per context, or stackable adapters that compose a context from reusable parts.

When it helps, and when it misleads

Its strength is that it captures what is genuinely common across contexts once and specializes cheaply, making switches lightweight and letting shared improvements propagate everywhere; adapters[1] are a proven way to get many context-maps out of one substrate. Its failure modes trace to a single assumption — that a real shared invariant exists. When contexts have little in common, the backbone becomes a bad average and the adapters strain to compensate; a change to the backbone silently perturbs every context at once (shared-fate risk); and a thin adapter may simply lack the capacity for a context that is truly different. The classic misuse is forcing genuinely incompatible contexts onto one backbone to save cost, producing a trunk that fits none of them well. The discipline is to verify the contexts actually share invariants before committing to a backbone, and to treat every backbone change as a multi-context event that needs cross-context regression testing.

How it implements the components

Shared Backbone with Context Adapters fills the shared-structure subset — the machinery that makes contexts reuse a common core:

  • shared_substrate_scope — the backbone is the shared substrate made explicit: the deliberately-chosen scope of structure held common across all context-maps.
  • context_transition_bridge — because only the adapter changes on a switch, the persistent backbone bridges contexts: shared state carries straight across and just the thin delta swaps.

It does not protect one context's parameters from another's updates (that's Selective Parameter Freezing), keep maps apart by naming them (that's the Context-Tagged Namespace Partition), or select which adapter a given context should call (that's the Context-to-Map Routing Table).

Notes

Backbone-with-adapters shares the substrate by design — one trunk, many thin deltas — whereas Context-Tagged Namespace Partition and Selective Parameter Freezing keep maps separate on a shared substrate. Choose this pattern when contexts have real common structure to exploit; choose an isolation mechanism when they must not interact. The Gated Expert Router is its close cousin — routing among specialized experts rather than composing backbone plus adapter.

References

[1] Adapter modules (a form of parameter-efficient fine-tuning) — small trainable components inserted into a large frozen backbone to specialize it per task or domain. Used here as designed: the thin per-context delta over a shared trunk. ↩