Chapter 13 – From Maps to Enforceable Constraints
Chapters 8, 10, and 12 established the pieces of this boundary: Map proposals limited to selected surfaces, a protected control plane, and separate Adoption and Admission paths. This chapter draws those mechanisms together around one question: when does a selected Map claim stop being merely advisory?
Documentation drifts when nothing checks whether a declared fact or rule still holds. One selected claim becomes enforceable when a protected mechanism checks its relationship with observed Terrain and routes a mismatch as a finding.
The whole Map does not cross that boundary at once. One property does.
Together, the preceding mechanisms create checked links between representations rather than a direct compiler from natural-language intent to reality. A contract may be observed Terrain for a documentation updater and an authoritative Map for an implementation workflow. Its role depends on the property being governed and the declared direction of authority.
AI may propose translations between those representations. The protected check establishes only the selected correspondence at that boundary; it does not prove that the source captured the right intent or that the translation preserved every unstated concern.
One Claim, One Direction, One Check
One property, one direction, one protected check
From Map Claim to Enforceable Relationship
A relationship becomes enforceable only after the workflow declares which side is authoritative for one property and protects the check that compares them.
Route declarations define the current endpoint inventory. An updater proposes a documentation patch limited to the selected Map surface. A check outside candidate authority compares it before separate Adoption.
An adopted API contract defines the intended interface. A workflow proposes implementation changes within named effects. Protected compatibility checks run before separate Admission.
Name the property and direction before execution.
The updater or implementation step changes only the named surface.
The gate compares the candidate with the authoritative source.
A passing relationship does not authorize its own effect.
Enforcement remains selective. Passing this gate establishes the named correspondence, not universal correctness or truth.
Before enforcing a relationship, declare its authority direction:
| Map surface | Authority for the checked property | Permitted response to mismatch |
|---|---|---|
| Generated inventory, such as public interfaces | Observed Terrain | Propose a Map revision limited to the selected surface |
| Prescriptive rule, such as allowed dependencies | Adopted Map | Stop or propose a Terrain correction within the declared effect envelope |
This prevents a dangerous shortcut: observe current behavior, rewrite
the policy to match it, then declare compliance. If the authority itself
appears wrong, the current workflow ends blocked and names
the external decision required. A Map-Updater may propose a revision
only to a Map surface permitted by its Mission and adopted policy. A
Map-driven reconciliation Mission may instead propose a Terrain
correction under the adopted Map. A change to a protected Map, policy,
authority, workflow, or control surface requires a Governance Mission.
Each proposal remains subject to separate Adoption or Admission,
according to its target.
A generated Public Interfaces block illustrates the
boundary. The pinned source revision exposes one additional
parameter:
## Public Interfaces
- charge(amount, currency)
+ charge(amount, currency, idempotency_key)A deterministic extractor reads the actual public signatures. The workflow compares them with the selected Map block and, when they differ, produces a candidate patch in an isolated workspace. A check outside candidate authority re-extracts the candidate block and requires a literal match with the pinned source. Chapter 10’s separation between proposal and Adoption still applies: the candidate remains a Map proposal until separate authority adopts it.
After every required check passes, complete records
proposal closure: the final artifact is a supported Map proposal, and
the Run Record is sealed. If the two surfaces already agree and no
candidate effect exists, the run ends no_change. If a
required source is missing, the run ends blocked only when
it names the external repair needed; otherwise it ends
failed. Every terminal path seals the Run Record.
For an adopted dependency rule, the same mechanism runs in the opposite direction. The workflow observes dependency edges and may propose a Terrain correction within its declared effect envelope. It cannot edit the allowlist that grades it.
The complete mechanism is therefore small: one declared property, one authority direction, one observation, one protected check, and one declared handoff—Admission when Terrain changes, Adoption when a Map changes.
Different Artifacts, Same Boundary
A schema, policy, or infrastructure declaration becomes enforceable only for a named property. A protected mechanism must evaluate that property, and a required execution or admission path must act on the result.
| Map artifact | Selected enforceable relationship | Boundary |
|---|---|---|
| API specification | Requests, responses, or compatibility conform to the pinned contract | Protected contract checks and release Admission |
| Infrastructure as code | Observed or proposed infrastructure corresponds to adopted configuration | Plan, drift, destination, and admission controls |
| Policy as code | A decision input satisfies the adopted rule bundle identified for that decision | Protected evaluator plus mandatory execution or Admission gate |
The same principle applies less mechanically to higher-level Maps. A tone guide may become a template plus human review rather than a hard schema. A runbook claim may become a Sensor that detects a known unsafe state. The point is not to make every sentence executable. It is to select claims whose authority, observation, and consequence justify maintaining an enforcement boundary.
What Selective Enforcement Buys
Selective enforcement prevents specific failures:
- a mismatch on the checked surface cannot remain invisible once the required Sensor runs;
- a protected gate can prevent the known forbidden state on the path it controls;
- findings, proposal closure, and Admission remain distinct;
- under protected-sink and trust-root assumptions, retained evidence can explain the decision.
The limit is equally important. A passing gate establishes only the named property under the named inputs, extractor, check, and policy. It does not prove that the source specification is wise, that the rest of the Map is current, or that unobserved behavior is correct. A synchronized source can still be verbose, irrelevant, or wrong outside the checked surface.
Enforcement should therefore be selective. It is warranted where a consequential claim can be observed and the cost of undetected drift exceeds the cost of maintaining the check. Volatile narrative guidance should remain advisory when a hard gate would create more false authority than assurance.
Software Development as Code does not require every useful outcome to be fully specified. Exploratory work may therefore have only containment checks for effects, budgets, protected controls, and evidence. Those checks can establish that the attempt remained inside its boundaries; they cannot establish that the artifact is correct. A declared oracle or an authorized human’s recorded judgment must still support the proposal before separate Admission or Adoption.
The enforcement boundary is consequently modest but important. It turns one selected relationship from advice into a check while preserving the distinction between correspondence and truth.