Chapter 13 – From Documentation to Enforceable Constraints
Destination: Selected Map claims become enforceable rather than merely advisory.
Chapters 8, 10, and 12 established the pieces of this boundary: bounded Map proposals, a protected control plane, and mandatory policy 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 the movement 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. A bounded updater proposes a documentation patch. A protected comparison checks correspondence before separate adoption.
An adopted API contract defines the intended interface. A bounded workflow proposes implementation changes. Protected behavior and compatibility checks run before separate admission.
Name the exact property and direction before execution.
The updater or implementation step changes only the bounded surface.
The protected gate compares the candidate with the authoritative source.
A passing relationship does not authorize its own effect.
Enforcement remains selective. Passing this gate establishes one declared 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 bounded Terrain-to-Map revision |
| Prescriptive rule, such as allowed dependencies | Adopted Map | Block or propose a bounded Map-to-Terrain correction |
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 stops. A separately authorized Map-Updater, reconciliation Mission, or Governance Mission may propose a change under its own authority.
Consider a generated Public Interfaces block. The fixed
source revision exposes one additional parameter:
## Public Interfaces
- charge(amount, currency)
+ charge(amount, currency, idempotency_key)A deterministic extractor reads the actual public signatures. A bounded workflow compares them with the selected Map block and, when they differ, produces a candidate patch in an isolated workspace. A protected check re-extracts the candidate block and requires an exact match with the fixed source. Chapter 10’s separation between proposal and adoption still applies: the candidate remains a Map proposal until separate authority adopts it.
If the two surfaces already agree, the outcome is a no-op. If a required source is missing, the workflow cannot claim alignment.
For an adopted dependency rule, the same mechanism runs in the opposite direction. The workflow observes dependency edges and may propose a bounded Terrain correction. 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 separate adoption path.
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 fixed 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 exact adopted rule bundle | 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. Use it where a consequential claim can be observed and the cost of undetected drift exceeds the cost of maintaining the check. Leave volatile narrative guidance 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 authorized human 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.