Chapter 1 – A Minimal Governed Loop

Keep Code and Docs in Sync

The loop aligns one code surface with one doc or spec block through a bounded change step, an independent check, and retained evidence. The change step emits a patch or works in an isolated candidate workspace; it does not adopt its own result. Chapter 7 later turns the goal into a typed Mission Object and separates that authority from the Run Record for one execution.

This first version stays deterministic so the mechanism is visible without model output, API failure, or non-convergence. Chapter 2 adds stochastic work; Chapter 5 adds bounded recovery.

The Smallest Useful Loop

The pattern needs one small code surface and one doc or spec block that should mirror it.

A concrete first loop can be a public-interface sync. The code is the observed source. The generated inventory is the description that should mirror it. A bounded writer proposes the update, an independent comparison checks it, and a small evidence record preserves what happened. The book calls these roles Terrain, Map, Effector, Validator, and Ledger.

A file is not authoritative in every context. Authority belongs to the specific property being decided. Here, source code defines the exported-signature inventory, but it does not define intended API policy or compatibility. This loop makes the following declaration:

Code is not authoritative for intended API policy, compatibility, or behavior. Those properties require their own adopted Maps and scope-matched Validators. If the architecture block were an API contract rather than a generated inventory, the direction would reverse: the contract would be Map authority, code would be observed Terrain, and a mismatch would fail instead of rewriting the contract. Chapter 10 generalizes this as property-specific authority.

The loop enters with one intent: update only the generated Public Interfaces inventory so it exactly matches the exported Terrain signatures. One compact trace shows the complete claim:

The Validator result is structured evidence, not a reassuring sentence. This loop has no separate Judge because there is no policy choice to make. Its scope-matched Validator covers the narrow correspondence claim, and each evidence class has one semantic outcome:

If correspondence or scope failed but the recorded outcome says success, the record contradicts its own evidence. Reject that account rather than preserving it as valid run history. The Validator does not apply the patch, and a successful proposal does not make itself authoritative. A Terrain-changing candidate would likewise require separate admission.

The implementation needs four things: a bounded writer, an independent check, a fixed mapping from each result to an outcome, and one stable interface through which the loop runs. For one mechanically decidable property, a separate decision layer adds nothing.

The check must still be strong enough for the claim made at that scope. A unit test or the corresponding verification step in the V-model supports only the property it checks. Here, exact signature comparison decides the inventory claim; it says nothing broader about API intent, compatibility, behavior, or design quality. Chapter 5 introduces a Judge only when evidence can support more than one allowed transition or requires interpretation.

Stable Interface

Put the Effector and Validator behind a stable interface that humans, continuous integration, and agents can all call. They should invoke the same operation and receive the same structured result while implementations remain swappable. After alignment, the same interface returns a no-op without changing the contract.

Git can preserve the patch, but a patch alone is not a Ledger. Even this minimal record ties the intent and input state to the diff, Validator result, terminal transition, and seal. Later chapters add Mission identity, Validator versions, approvals, and richer output evidence.

The negative case is part of the contract: a deliberate Map/Terrain mismatch must produce machine-readable evidence and must not advance. After a corrected proposal is separately adopted, the next run should produce a no-op.

From One Loop to a Factory

One bounded loop is the unit of trust, not the destination. When its inputs, effects, checks, outputs, result, and evidence are stable, it can become a dependable step inside a larger workflow. The enclosing workflow may consume its declared outputs and sealed result. It may not turn a failed step into success, inherit undeclared effects, or treat the step’s evidence as new authority.

Scale comes from accumulating these workflows around recurring changes. Evidence from a reliable recurring class of low-risk work can support a policy proposal for deeper delegation. If independently adopted, that policy may trigger or admit later instances without a new human decision. Human attention then moves toward exceptions, novel intent, protected rule changes, and high-consequence admission. The aim is fewer routine interruptions per admitted change, not autonomy for its own sake.

This is why the first loop stays small. A step must be narrow enough to reason about before it can be trusted as part of something larger. We have made one change process explicit and checkable: its intent, effects, evidence, outcomes, and separate adoption path are visible. Finite, inspectable failure is the floor; the larger ambition is a factory in which most recurring steps converge toward stated intent within their budgets. The following chapters make the process probabilistic, versioned, composable, and protected without abandoning that unit.