The models-bridge — the MBSE substrate between agents and codebase

<!-- summary: Typed models between agents and codebase — the MBSE substrate that makes scaling possible. -->

The third role in the catalogue. Not "agent" and not "product," but the layer that couples them: typed models of the system that agents read to reason about the codebase, and that govern it (a limited slice — config, docs, IPC contracts — is generated from them too). This is the interface through which a context-bounded agent operates a context-exceeding codebase — the thing that lets agentic engineering scale past a toy.

     AGENT CONTROLS   ◀────  THE MODELS-BRIDGE  ────▶   PRODUCT / CODEBASE
     (govern fleet)    read    (typed system-models)   govern & generate   (the artifact)

  brief-linting  ┐                 ┌ system-model catalog ┐               ┌ NetworkPolicy / wiring gen
  dyn-ctx-inject ┼── query/inject ─┤ meta-sync ══ drift   ├── parity/gen ─┼ deployment topology
  role-dispatch  ┘                 │ query-surface        │               └ boundary / seam lints
                                   └ codegen · read-no-copy ┘

Why this matters

1 · Executable documentation that cannot drift. These models are not prose — they are data that tools, lints, and deploy scripts read on every run, and that generate real artifacts (NetworkPolicy, service wiring, API docs, docker). Because they are continuously used and validated, the build fails the moment a model diverges from the code — the drift & parity gates enforce exactly that, the one gate the rest here depends on: a bridge is only useful if the map equals the territory, and a lying map is worse than none. The deepest dividend shows under a re-platforming: change the substrate (deployment engine, storage, concurrency model) and a faithful map mostly survives untouched — the elements that do move localize precisely where the old substrate had leaked a semantic guarantee into the design, turning a migration from a leap into a bounded, checkable walk over the model.

2 · The barrier was always human. Model-Based Systems Engineering — modelling your system as typed source-of-truth — has long been possible and rarely done: maintaining the models and satisfying the drift gates is tedious, and humans resent the nagging.

3 · Agents dissolve the barrier. That disciplined, repetitive upkeep is exactly what agents do without complaint — so agentic engineering finally makes MBSE practical, and the same models let an agent operate a codebase larger than its context in the first place.

4 · The bridge earns most where the model has never been. A frontier model carries strong priors for the code it saw often — a CRUD web app, a REST service, the popular framework. Point it at novel, obscure, or research and HPC software and those priors turn against you: the model reaches for the nearest reference class it knows and imposes the wrong one, confidently. The bridge's value rises as the code departs from that training distribution. A typed model states the domain's real shapes — its states, its seams, its invariants — where the model's own prior states the wrong ones. The bridge is how an engineer hands the agent the priors its training never gave it, so the further the system sits from the well-trodden path, the more the model must reason through the map instead of through a guess.

The <!--census:bridge:word-->21<!--/census--> mechanisms — one method, two subjects (a Y)

The role is a Y: one method (the trunk) reified toward the two subjects the bridge couples — the product it ships and the orchestration that builds it. The <!--census:bridge_method:word-->thirteen<!--/census--> method-mechanisms are subject-agnostic; the <!--census:bridge_models:word-->eight<!--/census--> models split by subject, with three that serve both faces (the shared spine).

The method — the trunk (subject-agnostic). The pattern, plus the machinery that holds any model true:

Product-facing models — the method pointed at the shipped artifact:

Orchestration-facing models — the method pointed at the agent fleet / dev substrate:

Shared-spine models — one model, both faces:

The bridge relationship — the Y's two exits

Every model here carries a bridge edge. The agent side consumes the model to reason; the model governs or generates its subject — the product (SOA, journeys, WCAG facts) on the product-facing arm, the fleet / dev-substrate (locks, mediators, layers) on the orchestration-facing arm — and the drift gate keeps model and reality equal. The Y's two exits are these two governed subjects; the trunk is the method they share. The shared-spine models straddle the fork — one model whose two faces govern each subject in turn.

Naming note: per the catalogue's reference policy, these entries name the system-models/ substrate and its files directly — that directory is their subject.