A typed map of every component's code zone and seams.

Component & zone model

Intent — A typed catalogue of every component's code zone (focus-dirs, tags, boundary kind, external seams, read surfaces), so "which component owns this file, and what may touch it" is a queried fact, not a guess.

Motivation — the failure it kills

Governance constantly asks "which component owns this file? what zone is it in? what boundary kind, what seams?" Answered ad hoc, with a hardcoded path list here and a grep there, those answers drift the moment a component is added or a directory moves, and the tool keeps passing while reasoning about a stale map. It is also the map an agent needs to know where it is in a large codebase.

Why it's not just "infer it from the directory layout"

Inferring component ownership from paths re-implements a fragile heuristic per tool, and the meaning of a zone (its boundary kind, its sanctioned seams, its read surfaces) isn't in the layout at all. The component model names those facts once, in a typed registry, and a reverse-mapping test asserts the model matches the real tree in both directions. Ownership becomes a fact you query from one authoritative place, so every tool reads the same answer and a moved directory fails the parity test instead of silently staling each tool's private inference. This is the map agents operate through: dispatch reads it for zones, lints read it for scope, dynamic context-injection reads it to slice constraints.

Mechanism

The Component registry is a typed dataclass set (leaf/group/meta kinds, focus_dirs, tags, docs, dockerfile, k8s manifest); the Boundary & seam classifiers classify each component's boundary, its outside-touching seams, and its read-side surfaces. A Reverse-mapping parity test holds the model↔reality parity.

Prerequisites

• A typed component registry with the fields consumers need (zones, tags, boundary, seams).
• A reverse-mapping test so the model can't silently diverge from the tree.
• Consumers that read it (lints, dispatch, DCI) rather than hardcoding paths.

Consequences & costs

• Add-a-component upkeep — a new component means a registry row + boundary/seam classification, or the reverse-mapping test fails (deliberately).
• Centralization blast radius — a wrong zone misroutes every consumer at once (the fix-once affordance's cost).

Known uses

• The Component registry (read by the lint fleet, dispatch, and audit surfaces).
• The boundary / seam / read-surface classifiers.
• The Reverse-mapping parity test (model↔tree parity).

Related mechanisms

• Bridge — agents consume it (dynamic-context-injection slices constraints by component; role-typed-dispatch reads zones) ◀──▶ it governs the product (boundary/seam lints, focus-dir scoping).
• Counterpart — drift-parity-gates: the reverse-mapping test that keeps it honest.
• See also — meta-model-consumption (read it, don't hardcode) · query-surface (the Model query tool component subcommand).