Part 3 — The Model Zoo  ::  Chapter 15

3.4 The Development View

The Process view held the running system consistent. The Development view steps off the runtime entirely and looks at the source: how the code is packaged into modules, which layer may depend on which, and who owns each piece. It is the view the people and agents who build the system reason through. Before an agent changes a line it must answer two questions — where am I in this codebase, and what may this file touch? — and this view is the map that answers them.

One general type anchors the view. A bill of materials captures a project's dependencies, direct and transitive — the software supply chain a build rests on. Two real models embody the view on live code. The first is the component and zone model, the ownership and boundary map. The second is the rule-metadata registry, the slice of the domain registries that models the governance rules themselves — the same typed rule index this book's own catalogue is generated from, so the book itself is partly governed by a model it describes.

Learn more about this governance mechanism: component and zone model.

Learn more about this governance mechanism: domain registries.

A bill of materials — the view's general type — is the dependency graph of a build: every third-party package it pulls in, direct and transitive, the SBOM lens on the code. It is a development-view concern because a dependency is a packaging fact, not a runtime one: it decides what the build fetches and what a fresh checkout must resolve. The discipline it enforces is completeness. Every package the code or the quality gates use must appear in the matching manifest, or a fresh checkout's build breaks on a resolve the developer never saw fail. An out-of-band install that never lands in the manifest is invisible to the bill of materials, and invisible is where a supply-chain surprise lives.

So much for what the build depends on. The next model answers the question an agent asks first: where am I, and what is this file allowed to touch?

3.4.1 The component & zone model

A typed catalog of every component's code zone — its focus directories, its tags, its boundary kind, its external seams, its read surfaces — so "which component owns this file, and what may touch it" is a queried fact rather than a per-tool guess.

(a) Quality property it helps assess. Two, both drifting silently the moment a directory moves.

(b) Constructs and relations. A typed registry keyed by component.

(c) Visual depiction. The natural diagram, Figure 3.4-1, is a component flow — the registry feeding the tools that read it, with a reverse-mapping test joining registry to real tree. Reused from the model's appendix Structure slot:

One component registry, every tool reading the same ownership answer The component registry feeds the boundary lints, the agent dispatch, and the dynamic context injection, so every tool reads the same ownership answer. A reverse-mapping test joins the registry to the real directory tree and fails the build if the declared zones and the tree disagree in either direction. Component registry Boundary lints Dispatch Context injection Real directory tree Reverse-mapping test
Figure 3.4-1. The component registry feeds the boundary lints, dispatch, and context injection — every tool reads the same ownership answer — and a reverse-mapping test joins it to the real tree in both directions.

(d) Invariants, and how they are checked. A reverse-mapping test and boundary lints, collected in Table 3.4-1:

Table 3.4-1. Invariants of the Development view — each with its temporal shape and the check that holds it.
InvariantTemporal shapeHow it is checked
Every declared zone matches a real directory□P (safety)Reverse-mapping test, model ⊆ reality — a declared zone with no directory is a finding.
Every source directory is owned by exactly one component□P (safety)Reverse-mapping test, reality ⊆ model — an unowned or double-owned directory is a finding.
No component reaches a seam its boundary kind forbids□P (safety)Boundary lint over the declared seam set.

(e) Traceability and derivation direction. Model-from-code. The reverse-mapping test re-reads the real directory tree and reconciles the declared zones against it, so the tree is the ground truth. The join key is the focus directory: a reader round-trips from a Component record to the files it owns by that path prefix, and dispatch, lints, and context injection all resolve ownership through the same key.

Also seen in: Logical (a component is a functional-structure unit). Rendered in full here.

That model maps the code. What maps the governance itself? The next registry turns the lens on the rules — and, because this book is generated from that same index, on the book you are reading.

3.4.2 The rule-metadata registry

The rule-metadata registry is the self-referential slice of the domain registries: the governance rules' own metadata, and so the model the governance machinery — and this book — are partly governed by. It assesses rule-index consistency, whether the published rule index matches the rules declared in the code. The distinctive move: the metadata is extracted from inline blocks at each rule's own site, then generated into the index. The description of a rule lives next to the rule it governs, so it cannot rot into a separate document nobody updates. Two gates hold the round-trip — a completeness lint fails a rule that omits a required field, and a freshness lint fails a committed index that differs from a regeneration. The result is a registry that can round-trip from a published rule straight to the code site that declares it, checked on every build. The appendix walks its schema and both gates in full; the component & zone model above is the worked example this view teaches through.

---

The Development view maps how the source is organized for the people and agents who build it. Next, the Physical view: where the built parts actually run, and under what per-host cost and load policy.

© James C. Davis, 2026–present