Concepts: How Governed Change Works

These concepts describe an architecture for turning uncertain proposals into change with bounded effects and inspectable evidence. They are most useful as a system, not as isolated definitions.

The central path is simple: Intent Compilation turns adopted intent into a Mission proposal; binding resolves its execution-defining references; semantic and policy review evaluate the fully bound proposal; Activation authorizes its exact identity; and preflight verifies that identity and its dependencies are present, intact, and executable. Bounded execution then produces a Candidate, validation records findings and evidence, a policy-bound decision selects a declared route, and the run reaches a terminal result. Separate Admission or Adoption determines whether a supported proposal changes Terrain or authority.

Use this page to understand the mechanism, see where each term stops, and follow links into the chapters. For the compact canonical list, see Appendix B: Core Vocabulary. For the relationships among the protocol artifacts and decisions, see Appendix C: Protocol and Object Model.

The system in one trace

Suppose a team asks an AI-enabled workflow to add cursor pagination to GET /api/users without breaking existing clients.

flowchart TB
    I["Adopted intent"] --> Q["Mission proposal"]
    Q --> B["Bind identities"]
    B --> V["Semantic + policy review"]
    V --> A["Activation"]
    A --> H["Preflight<br/>identity + dependencies"]
    H --> P["Bounded execution<br/>Candidate"]
    P --> X["Validation"]
    X --> E["Recorded findings<br/>and evidence"]
    E --> J["Policy-bound decision"]
    J -->|"refine"| P
    J -->|"close"| R["Terminal result<br/>proposal closure if applicable<br/>Run Record sealed"]
    R --> G["Declared handoff"]
    G --> T["Admission to Terrain"]
    G --> D["Adoption of Map or policy"]

Fix intent and authority. The released compatibility contract is an adopted Map for the response-shape property. Current source and behavior are Terrain. Before Activation, binding resolves the authority source, base revision, decisive checks or check-validation protocols, policy, and other execution-defining references to immutable identities. Semantic and policy review evaluate that fully bound Mission Object. Activation authorizes its exact content-addressed identity. Preflight then verifies that identity and its bound dependencies remain present, intact, and executable.
Build a scope-bounded input. A Context Graph records the relevant relationships among the endpoint, released contract, generated client, tests, and compatibility checks. Policy selects a Context Packet containing only the authority and evidence needed for this run.
Produce one proposal. A Stochastic Generator runs through an Effector with bounded effects. Its first Candidate changes the response from an array to an object and updates candidate-controlled tests to agree with that interpretation.
Validate and record. The Workflow retains candidate-produced tests and their results as supporting Evidence. A candidate-independent Sensor computes the actual changeset, while the Scope Guard denies undeclared effects. A candidate-independent compatibility Validator compares the candidate with the released baseline and records its finding. The supporting tests cannot replace that required check or redefine compatibility.
Decide without moving the target. A policy-bound rule routes the findings. The first compatibility failure can guide another attempt inside the Bounded Refinement Loop, but it cannot widen scope or redefine compatibility. A Judge is needed only if the evidence can support more than one permitted route.
Close the finite run. A corrected candidate preserves compatibility and passes every required check. The run ends complete: it produced a supported proposal, not a deployed change. The Run Record is sealed, and the Ledger retains the evidence.
Revalidate before changing reality. The Mission Gate checks the current base, policy, effects, evidence, approvals, and candidate identity. If they still match, separate Admission makes the candidate effective in Terrain. Base drift can still deny admission without rewriting the sealed Run Record.
Keep learning separate from authority. Evidence from several runs may support a later Map, workflow, Validator, or policy proposal. A Map-Updater may prepare a Map proposal when its Mission and adopted policy permit the surface; a Governance Mission is required for a protected Map, workflow, Validator, policy, authority, or control surface. Only separate Adoption makes the proposal authoritative.

The workflow can still be wrong. Its narrower guarantee is that selected authority, effects, checks, transitions, and admission decisions remain explicit and enforceable under the stated trust assumptions.

Find a concept

Browse by the question the concept helps answer.

1. Direction, state, outcomes, and authority events

Every governed change needs a declared direction: what currently exists, what may define the desired property, what is merely proposed, and which later event can make the proposal real.

The architecture separates three authority events. Activation authorizes one exact, fully bound and reviewed work contract to run. Admission makes a Candidate effective in Terrain. Adoption makes a Map or policy authoritative.

Authority belongs to a property, not automatically to a file type. Source code can define the current exported-signature inventory while remaining unable to define intended compatibility policy. An API contract can be observed evidence in one workflow and the authoritative Map in another.

Map

Canonical definition. A structured, versioned representation of intent or observed system structure. A Map is authoritative only for the declared property and scope granted by its adopted source or policy.

Why it matters. A Map tells a workflow which representation may settle a particular intent or description claim. Example. An adopted OpenAPI contract may govern public compatibility, while a generated route inventory describes what the current service exposes. Boundary. No document, schema, or codebase is universally authoritative; its authority must name the property and scope.

Related. Terrain, Candidate, Adoption. Deep dive. Chapter 1: The Smallest Useful Loop.

Terrain

Canonical definition. The current system state a loop can observe or affect, including source, configuration, infrastructure, runtime behavior, and external operational facts. Terrain observations are property-, source-, scope-, and time-bound; they establish no claim beyond those bounds.

Why it matters. Terrain gives Sensors and Effectors an explicit system boundary to observe or affect. Example. A pinned source revision, current deployment configuration, and measured runtime behavior may all be Terrain for one Mission. Boundary. Terrain may change and is observed through bounded Sensors. A snapshot establishes only its declared properties and scope at its bound time; it cannot establish a permanent optimum or recover why the system was built or what policy ought to be.

Related. Map, Sensor, Admission. Deep dive. Chapter 8: Map-Driven Reconciliation: Map to Terrain.

Candidate

Canonical definition. A proposed state: neither admitted Terrain nor an adopted Map or policy.

Why it matters. Calling an output a Candidate prevents plausible work from being confused with admitted reality. Example. A model-generated patch, proposed policy revision, or regenerated documentation block remains a Candidate while checks and review are pending. Boundary. Retaining, content-addressing, or repeatedly reproducing a Candidate does not make it Terrain or an adopted Map.

Related. complete, Admission, Adoption. Deep dive. Chapter 5: State, Results, and Sealing.

`complete`

Canonical definition. A terminal result indicating that the run produced its declared output and satisfied its completion conditions. In a proposal-producing run, that output is a supported proposal; a report-producing run may complete without proposing a change. The Run Record is sealed.

Why it matters. complete records that a run satisfied its declared completion conditions; it does not classify every completed run as proposal-producing. Example. A compatible API patch may end complete with a supported proposal, while a checked maintenance scan may end complete with only its declared report. In both cases, the Run Record is sealed. Boundary. complete does not mean merged, deployed, approved, admitted, or adopted.

Related. Candidate, Mission Gate, Admission. Deep dive. Appendix A: Completion Without Admission.

`no_change`

Canonical definition. A terminal result indicating that the required property already held and no candidate effect exists. The Run Record is sealed.

Why it matters. A verified no-change result records useful work without inventing a change. Example. A Map-Updater reads every required source, completes the comparison, and finds that the selected Map surface already agrees with Terrain. Boundary. Missing, stale, or contradictory evidence is not agreement and must not be reported as no_change.

Related. Map-Updater, Validator, blocked. Deep dive. Chapter 5: State, Results, and Sealing.

`blocked`

Canonical definition. A terminal result that names the external repair or decision required before a new linked run can proceed. The Run Record is sealed.

Why it matters. blocked names an external repair or decision that internal retries cannot supply. Example. A separate owner must grant missing authority, restore the accepted Oracle, or repair the evidence environment. Boundary. The terminal result must name that action; if none can be named, use failed. A resolution creates a new linked run and never reopens the sealed Run Record.

Related. Oracle, Run Record, failed. Deep dive. Chapter 5: Oscillation and Failure Routing.

`failed`

Canonical definition. A terminal result for exhausted, non-convergent, or otherwise unsuccessful execution when no named external repair or decision can unblock a new run. The Run Record is sealed.

Why it matters. Finite, inspectable failure is safer than an agent that keeps trying or summarizes exhaustion as success. Example. A loop consumes its attempt budget without comparable progress; its sealed Run Record retains the candidates, findings, and stop reason. Boundary. Use blocked instead when a named external decision or repair could unblock a new run.

Related. blocked, Bounded Refinement Loop, Ledger. Deep dive. Chapter 5: Finite Stopping.

Activation

Canonical definition. The separately authorized event that permits one exact Mission identity to run.

Why it matters. Activation separates a fully bound, reviewed work-contract proposal from authority to execute it. Example. After binding resolves the base, authority sources, checks, policy, and other material references, adopted policy authorizes that content-addressed Mission identity. Boundary. Activation authorizes only that exact identity. Preflight performs the separate presence, integrity, and executability check; it cannot select, replace, change, or rebind a dependency.

Related. Mission Object, Admission, Adoption. Deep dive. Chapter 7: The Mission Lifecycle.

Admission

Canonical definition. The separately authorized event that makes an exact candidate effective in Terrain. Its authorization may be a current human decision or a delegation already encoded in adopted policy; either way, it remains outside candidate-producer authority.

Why it matters. Admission keeps candidate production separate from changes to operational reality. Example. A protected gate revalidates a supported code-patch proposal against the current base and policy before merging or deploying it. Boundary. A Validator pass, Judge decision, or complete result cannot admit its own Candidate.

Related. Mission Gate, Candidate, Adoption. Deep dive. Chapter 10: The Mission Gate.

Adoption

Canonical definition. The separately authorized event that makes an exact proposed Map or policy identity authoritative. It may atomically apply and select the proposal or atomically select an exact artifact staged earlier under non-authoritative isolation. Staging alone is not Adoption and cannot govern production.

Why it matters. Adoption marks the separate decision that changes what will govern later work. Example. An adopter may atomically apply and select a supported policy proposal, or validate an exact copy installed earlier in a shadow slot and atomically select it. Boundary. Pre-Adoption staging must remain isolated and non-authoritative; it cannot govern production. Adoption changes a Map or policy, while Admission changes Terrain. Neither follows automatically from a supported proposal.

Related. Map, Governance Mission, Admission. Deep dive. Chapter 10: Changing Protected Controls.

Back to the concept index

2. Work contracts and evidence

A prompt asks for work. A governed workflow states what may happen, records what did happen, and ends finitely. Authority and execution history remain separate so the run cannot rewrite its own contract after seeing inconvenient evidence.

Workflow

Canonical definition. A finite, governed execution graph of sequential, conditional, or parallel steps with declared authority, effects, transitions, stopping conditions, evidence requirements, and a declared, output-appropriate handoff such as local acceptance, report delivery, Admission, or Adoption.

Why it matters. The Workflow makes multi-step behavior inspectable as a finite graph rather than an open-ended conversation. Example. Prepare input, generate a patch, run checks, route findings, reach a terminal result, seal the Run Record, and follow the output’s declared handoff. Boundary. A Workflow may contain loops, branches, parallel steps, and child workflows, but every run still needs declared terminal conditions and an output-appropriate handoff such as local acceptance, report delivery, Admission, or Adoption.

Related. Loop, Mission Object, Governed Loop Network. Deep dive. Chapter 2: Beyond One Model Call.

Loop

Canonical definition. Repetition of a step, subsequence, or complete workflow at a declared scale. Each workflow run remains finite, reaches one terminal result, and seals its Run Record.

Why it matters. Naming the repeated unit prevents continuous operation from becoming one immortal process whose state and authority drift. Example. A check-and-refine subsequence may repeat three times inside one run, while the complete maintenance Workflow runs again each night. Boundary. Repetition does not remove budgets, terminal outcomes, or the requirement to seal each Run Record.

Related. Workflow, Bounded Refinement Loop, Run Record. Deep dive. Chapter 5: Finite Stopping.

Mission Object

Canonical definition. A versioned work-contract artifact. A draft may contain symbolic references. Before Activation, binding resolves every execution-defining reference to an immutable identity, and semantic and policy review evaluate the fully bound proposal. Activation authorizes that exact Mission identity. Its bound content fixes the objective, authority, effects, outputs, checks, budgets, routing, and approval policy for one run.

Why it matters. The Mission Object moves executable authority out of chat and fixes it before candidate production begins. Example. A documentation Mission binds its base, authority sources, checks or check-validation protocols, policy, editable README block, three-attempt budget, and docs-owner adoption path before Activation. Boundary. A draft may contain symbolic references, but final review and Activation require immutable bindings. Preflight can verify only the already-authorized identity and dependencies; it cannot finish defining or rebind the contract.

Related. Context Packet, Run Record, Scope Guard. Deep dive. Chapter 7: What Belongs in the Contract.

Evidence

Canonical definition. A recorded, identity- and provenance-bearing observation, artifact, or check result tied to a declared claim or decision. Candidate-produced artifacts and results from new or modified checks may count as evidence. Whether they independently corroborate a claim is a separate question of provenance, authority, and shared failure modes. A decisive check—or the protocol that validates a new or modified check before it becomes decisive—must remain outside the candidate producer’s ordinary write authority.

Why it matters. Evidence gives a later decision an inspectable basis instead of an unrecorded assertion. Example. One Workflow may generate a patch and a regression test, then record that test, the unchanged integration-suite identity, the execution environment, and every result. Boundary. Candidate-produced tests and results are evidence, but they cannot by themselves redefine acceptance. Adopted policy determines their weight and protects the decisive rule or the protocol used to validate a new check.

Related. Validator, Run Record, Mission Object. Deep dive. Chapter 3: Checks as Workflow Evidence.

Run Record

Canonical definition. The logically append-only execution record and retained evidence for one activated Mission. When the run reaches a terminal result, the Run Record is sealed with its retained evidence; later intervention creates a linked record.

Why it matters. The Run Record preserves what happened without allowing evidence to rewrite what was authorized. Example. It references the already-bound baseline and records the Context Packet, runtime observations, attempts, findings, actual effects, decisions, outputs, budget use, and terminal result for one activated Mission. Boundary. Later intervention creates a linked record rather than editing history.

Ledger

Canonical definition. Logically append-only, reconstructable evidence for Activation, attempts, effects, findings, decisions, terminal results, Admission, and Adoption. Its guarantees depend on a protected sink and trust root.

Why it matters. A Ledger lets a later reader reconstruct why a transition, Activation, Admission, or Adoption was allowed and reject contradictions in that account. Example. It preserves an ordered link from Activation through attempted effects and Validator reports to the terminal result, sealed Run Record, and any later Admission or Adoption decision. Boundary. JSONL, a Git history, or a database table is not trustworthy by format alone; guarantees depend on a protected sink and trust root.

Back to the concept index

3. Context architecture

Useful context is not the largest prompt available. It is the smallest reproducible input that contains the authority and evidence needed for one scope-limited decision.

Context selection anchors on a concrete target, expands only across relationships needed to understand and check it, and prunes by read authority, write scope, relevance, denied surfaces, and finite budgets.

Context Graph

Canonical definition. The versioned structure from which a scope- and size-bounded input is selected. Its nodes identify sources; its typed edges record why those sources relate.

Why it matters. The graph makes the relationships used for context selection explicit and reproducible. Example. Nodes identify an endpoint, its released contract, implementation, generated client, owner, and checks; typed edges record implements, generates, or is checked by. Boundary. It can begin as a repository-local index and does not need to become an organization-wide knowledge graph.

Related. Context Packet, Sensor, Semantic Density. Deep dive. Chapter 6: Build a Context Graph.

Context Packet

Canonical definition. The scope- and size-bounded, ordered, provenance-bearing input assembled for one Mission from its authority and evidence.

Why it matters. The packet records the scope- and size-bounded input a run actually received. Example. A failing tax case anchors a packet containing the approved rule, function, direct helpers, and checks, while excluding unrelated endpoints and writable surfaces. Boundary. Retrieval may suggest sources, but policy selects them; changing authority, writable scope, budgets, or required checks requires a new Mission.

Semantic Density

Canonical definition. The concentration of distinct, decision-bearing meaning in context. Useful context combines Semantic Density, Correctness, and Relevance rather than maximizing volume.

Why it matters. Dense context can reduce noise only when the retained meaning can change the current decision. Example. A short packet with the governing contract, failing case, direct dependency, and relevant check is denser than a repository dump. Boundary. Density alone is unsafe: concise falsehood is dangerous, correct but irrelevant material is noise, and tacit organizational judgment cannot be assumed to survive encoding.

Back to the concept index

4. Producing, checking, and refining work

Probabilistic generation becomes governable when run-invariant boundaries control its inputs, measure its outputs, restrict its transitions, and stop refinement when another attempt is no longer justified.

Sensor

Canonical definition. A read-only measurement of Terrain or retained evidence that emits structured observations with provenance.

Why it matters. Sensors turn Terrain and retained evidence into observations the workflow can identify and check. Example. A protected Sensor extracts exported signatures or computes the complete diff from a pinned base. Boundary. Read-only measurement does not make the Sensor’s output universally authoritative; policy still declares which property the observation may settle.

Related. Terrain, Oracle, Map-Updater. Deep dive. Chapter 8: Sense, Normalize, Compare, Propose.

Effector

Canonical definition. A transformation with a finite, declared effect envelope that proposes a change to Terrain or a Map surface. It does not admit or adopt its own output.

Why it matters. An Effector gives candidate production an explicit effect envelope and output contract. Example. It may propose a diff in an isolated workspace or rewrite one generated documentation block. Boundary. An Effector proposes; it cannot grade broadly, expand its own write authority, or admit or adopt the result it produced.

Related. Candidate, Scope Guard, Stochastic Generator. Deep dive. Chapter 2: The Model Step.

Stochastic Generator

Canonical definition. A probabilistic model invocation that proposes a candidate within declared scope and output limits. It is one component of the system, not the system itself.

Why it matters. This term isolates the variable proposal mechanism from the governed system around it. Example. One model invocation produces a strict JSON or unified-diff Candidate from its Mission-bound Context Packet. Boundary. Better model capability can improve proposals, but it does not confer authority over scope, checks, routing, Admission, or Adoption.

Validator

Canonical definition. A declared check of one property that emits a structured report. A Validator supplies evidence; it cannot widen its own authority, admit a candidate, or adopt a Map or policy.

Why it matters. Validators replace a reassuring summary with property-specific, structured evidence. Example. A compatibility Validator compares a Candidate API response with a released contract and reports the exact mismatch. Boundary. A deterministic Validator can consistently check the wrong rule, and a passing check establishes only the property and cases it actually evaluated.

Related. Oracle, Judge, Physics. Deep dive. Chapter 3: What a Check Relies On.

Oracle

Canonical definition. The source or decision procedure allowed to settle a declared property.

Why it matters. Naming the Oracle makes explicit what may settle one contested property. Example. A parser can settle schema validity, a released contract can settle compatibility, and an authorized human may settle a judgment that cannot be encoded safely. Boundary. Relevance, retrieval rank, model confidence, or read access does not grant oracle authority.

Related. Validator, Map, blocked. Deep dive. Chapter 3: Checks as Workflow Evidence.

Judge

Canonical definition. A policy-bound decision role used when evidence can support more than one allowed transition. Its implementation may vary; runtime enforcement still limits transitions and keeps Admission and Adoption separate.

Why it matters. A Judge makes ambiguous routing a declared policy decision instead of hidden agent discretion. Example. All required findings might support retrying within budget, sealing failure, or escalating a named authority conflict. Boundary. A narrow loop whose results each have one declared destination needs no Judge; a Judge cannot invent findings, widen scope, alter budgets, or authorize Admission or Adoption.

Related. Validator, Bounded Refinement Loop, Mission Object. Deep dive. Chapter 5: The Judge Is a Role.

Software Development as Code (SDaC) Engine

Canonical definition. The complete runtime that executes governed workflows, keeps probabilistic steps inside activated authority, declared evidence requirements, and stopping rules, and prevents them from authorizing Activation, Admission, or Adoption.

Why it matters. The engine is the complete runtime boundary, not a synonym for its model or agent harness. Example. It activates Missions, prepares context, invokes steps within named effect limits, enforces effects and transitions, runs checks, seals Run Records with retained evidence, and presents supported proposals for Admission or Adoption. Boundary. A capable agent can be one component inside the engine; it does not own the policies and gates that contain it.

Deterministic Sandwich

Canonical definition. Deterministic preparation and validation around one probabilistic invocation with declared input and output bounds.

Why it matters. The pattern bounds one probabilistic invocation with reproducible input preparation and strict output validation. Example. Prep extracts exact signatures and the only editable block; a model proposes prose; Validation rejects invented signatures and out-of-region edits. Boundary. The pattern does not require every larger Workflow to contain only one probabilistic step, and deterministic checks are not complete truth.

Related. Context Packet, Stochastic Generator, Validator. Deep dive. Chapter 2: Prep, Model, Validation.

Canonical definition. The governed Propose -> Check -> Decide -> Refine cycle. An Effector proposes, Validators produce findings, and a Judge is used when evidence can support more than one permitted transition. Authority, scope, budgets, and stopping rules remain fixed for the run.

Why it matters. Structured findings can improve the next proposal without changing the target or allowing unbounded retries. Example. An exact signature mismatch informs a second Candidate while the Mission, scope, checks, and budgets remain invariant for the run. Boundary. Finite execution is not convergence; oscillation, unreachable acceptance conditions, or exhausted progress limits should end in a declared terminal result with retained evidence.

Related. Judge, failed, Run Record. Deep dive. Chapter 5: From One Attempt to Refinement.

Back to the concept index

5. Governance and composition

Recurring automation remains delegated only when the system separates observation, proposal, policy change, and admission—and enforces those separations outside the worker’s control.

Map-Updater

Canonical definition. A governed Terrain-to-Map workflow that proposes a change to a Map surface within its Mission’s authority and permitted by adopted policy, without changing Terrain. A protected Map, policy, authority, workflow, or control surface requires a Governance Mission.

Why it matters. A Map-Updater makes selected drift visible and proposes a correction to one Map surface permitted by its Mission and adopted policy without silently changing the system it observes. Example. It extracts current service routes from the source revision bound into its Mission, compares them with one generated inventory block, and proposes one Map patch. Boundary. The updater cannot recover intent from implementation, change Terrain, or adopt its own description. A protected Map, policy, authority, workflow, or control surface requires a Governance Mission.

Related. Map, Terrain, Adoption. Deep dive. Chapter 8: Sense, Normalize, Compare, Propose.

Maintenance Controller

Canonical definition. A recurring selector that senses, qualifies, and ranks eligible maintenance work without inheriting authority to perform it.

Why it matters. The controller can surface recurring maintenance pressure without acquiring authority to perform every task it finds. Example. A read-only scan applies eligibility rules, ranks a dead-import cleanup, and emits a checked report that may seed a separate Mission draft. Its material references must be bound and reviewed before policy may activate it. Boundary. Trigger frequency is not autonomy depth: a nightly schedule does not grant permission to edit, merge, deploy, admit, or adopt.

Related. Sensor, Mission Object, Governed Loop Network. Deep dive. Chapter 9: Selection Before Action.

Governance Mission

Canonical definition. A separately activated workflow for proposing a change to a named protected Map, policy, authority, workflow, or control surface. It cannot adopt its own proposal.

Why it matters. Protected rules need a change path that does not give ordinary work a privileged mode. Example. A separately activated Mission produces a supported, content-addressed proposal for one policy bundle under stronger checks and approvals. Boundary. A supported proposal cannot approve or adopt itself. Before Adoption, a separate mechanism may materialize it only as explicitly authorized, isolated, non-authoritative staging.

Scope Guard

Canonical definition. Runtime enforcement of the declared effect boundary, including attempted filesystem, process, network, credential, platform, data, and deployment effects.

Why it matters. Runtime mediation catches undeclared effects that a final diff cannot reveal. Example. A Candidate stays inside one service directory but attempts an unauthorized network call; the guard denies and records the call. Boundary. Path checks alone are incomplete because effects also include processes, credentials, APIs, databases, deployments, and concealed external changes.

Mission Gate

Canonical definition. The candidate-independent admission check that revalidates a supported proposal against current base, policy, effects, evidence, and approvals.

Why it matters. The gate prevents a previously supported proposal from bypassing changed state or incomplete evidence at admission time. Example. It recomputes the diff, rechecks the current base and policy, and denies an otherwise complete Candidate after base drift. Boundary. It runs outside model and candidate authority and cannot repair a stale proposal by rewriting the sealed Run Record.

Related. Admission, complete, Scope Guard. Deep dive. Chapter 10: The Mission Gate.

Ratchet

Canonical definition. A protected non-regression rule measured by one protocol pinned for the comparison. For ratcheted Admission, the candidate and next floor commit in one transaction; if either write fails, neither commits.

Why it matters. A Ratchet preserves a selected measured floor across admitted changes. Example. A protected protocol records the baseline duplication metric, rejects a regression, then Admission commits the supported refactor and next floor in one transaction. Boundary. If either write fails, neither commits; the candidate remains unadmitted and the prior floor remains authoritative. The Ratchet protects only the declared property under the protocol pinned for that comparison.

Related. Validator, Admission, Physics. Deep dive. Chapter 11: Protected Non-Regression.

Physics

Canonical definition. The protected constraints that shape execution: schemas, Validators, effect boundaries, budgets, gates, and stopping conditions. The name is a control-model metaphor, not a claim that the checks are complete truth.

Why it matters. Physics names the control surface held invariant for the run; it shapes probabilistic work without pretending the generator will behave deterministically. Example. Schemas constrain output, Validators check selected properties, effect boundaries restrict writes, and circuit breakers stop execution. Boundary. The metaphor does not imply that the checks encode complete truth, good judgment, or every property that matters.

Protected Control Plane

Canonical definition. The authority boundary around policy, trusted Validators, credentials, execution limits, evidence sinks, and Activation, Admission, and Adoption mechanisms that ordinary work cannot rewrite.

Why it matters. The control plane keeps autonomy delegated by placing authority, checks, credentials, limits, evidence sinks, Activation, Admission, and Adoption outside ordinary write authority. Example. Ordinary work may report a defective policy, but only a separate Governance Mission can propose a replacement for that named policy surface. Boundary. It is not a universal source of truth, and its guarantees fail if privileged actors can rewrite the enforcement path or protected history.

Related. Governance Mission, Ledger, Scope Guard. Deep dive. Chapter 10: Close the Trust Root.

Governed Loop Network

Canonical definition. A composed system of finite governed workflows whose declared contracts, effects, evidence, terminal outcomes, and failure semantics let them operate as reusable capabilities without inheriting undeclared authority. It supports work across property-specific surfaces but supplies neither global coherence nor coordination at an undeclared boundary.

Why it matters. Stable contracts let finite governed capabilities compose into larger operating systems without erasing their failure semantics. Example. A maintenance scan seeds a cleanup Mission draft whose material references are bound and reviewed before Activation; its terminal result and sealed Run Record then enter an admission workflow, while evidence may support a separate policy proposal. Boundary. Nesting does not propagate authority. Composition guarantees neither correctness nor global coherence, and it supplies no coordination at an undeclared boundary.

Back to the concept index

6. Architectural frames

These frames connect mechanisms across multiple stages. They clarify causal structure but add no runtime component, authority, or guarantee of correctness.

Intent Compilation

Canonical definition. The proposal-producing translation from ordinary-language intent and adopted sources into a structured Mission Object draft for binding and review. It ends with the draft and does not authorize execution; separate Activation later authorizes the exact Mission identity produced by binding and review.

Why it matters. It makes the translation before Activation reviewable instead of treating a prompt as authority. Example. A model drafts a pagination Mission. Intent Compilation ends with that structured draft. Structural parsing checks it; binding resolves its material references; semantic and policy review evaluate the fully bound proposal; and separate Activation authorizes its exact identity. Boundary. Compilation only proposes. It cannot bind authority by assertion, activate a Mission, admit a Terrain change, or adopt a Map or policy.

Related. Mission Object, Activation, Context Packet. Deep dive. Chapter 7: Intent Compilation.

Admission Horizon

Canonical definition. The property-specific boundary at which an exact candidate becomes effective in Terrain through Admission. Recursive composition can push that boundary outward for a selected Terrain property by keeping supported child outputs provisional as parent inputs, potentially until an outer workflow produces a replacement-system candidate. This can concentrate human attention on policy-level delegation and a later, higher-consequence Admission. A staging deployment, publication, resource use, data access, network call, notification, shared-state write, or other external action remains an effect governed at its declared effect boundary; a later Admission cannot make an earlier effect provisional. A Map or policy proposal remains non-authoritative until Adoption.

Why it matters. The Admission Horizon marks the property-specific boundary where an exact Candidate becomes effective in Terrain. Recursive composition can move that Admission outward while checked child results remain provisional inputs to enclosing Workflows. Example. Small Workflows produce supported component results; an isolated parent composes them into a replacement-system Candidate for final validation and Admission. Boundary. Staging, publication, network traffic, resource use, and other consequential actions remain governed by their declared effect boundaries even while the Terrain Candidate stays provisional. Composition does not propagate authority, adopted policy may automate Admission without erasing it, and Map or policy changes require Adoption.

Related. Workflow, Admission, Adoption. Deep dive. Chapter 2: Beyond One Model Call.

Torus

Canonical definition. The geometric frame for the destination ambition: a Governed Loop Network recurring across separately governed, property-specific surfaces of shared Terrain. Finite circuits run at different cadences. Admission changes Terrain; Adoption changes authoritative Maps or policy. Declared interfaces define cross-surface semantics, while later reads, events, and Sensors provide eventual visibility under declared delivery and freshness assumptions. This is a limited analogy to eventual consistency, not a replicated-state guarantee. The frame depicts recurrence at workflow and organization scales, not circular event time or a literal runtime topology. It adds no authority and guarantees neither global coherence nor an optimum. An invalidated bound observation, non-commuting effects, limited shared capacity, or a cross-surface invariant requires explicit coordination.

Why it matters. The Torus gives geometric form to the ambition of a Governed Loop Network recurring across separately governed surfaces of shared Terrain. It distinguishes that organization-scale destination from the architecture used to approach it. Example. Service, operations, documentation, and policy circuits run finite Missions at different cadences. Admission changes Terrain; Adoption changes authoritative Maps or policy. Declared interfaces define cross-surface semantics, while later reads, events, and Sensors provide eventual visibility under declared delivery and freshness assumptions. Boundary. A surface is independent only for the declared property. Eventual visibility is a limited analogy to eventual consistency, not a replicated-state guarantee. An invalidated bound observation, non-commuting effects, limited shared capacity, or a cross-surface invariant requires explicit coordination. The frame adds no authority and guarantees neither global coherence nor an optimum; its recurrence is not circular event time or a literal runtime topology.

Engineering Trust Spine

Canonical definition. The causal frame is intent → compilation → binding → review → Activation → preflight → bounded execution → validation → recorded findings/evidence → policy-bound decision → terminal result/proposal closure → Admission or Adoption. Accountability remains assigned and the evidence remains reconstructable throughout. Preflight only verifies that the already-authorized Mission identity and its bound dependencies remain present, intact, and executable; it does not select, replace, change, or rebind them.

Why it matters. It provides an end-to-end causal view without conflating validation, evidence, decision, authority, and accountability. Example. Intent becomes a Mission proposal through compilation; binding resolves its material references; review evaluates the exact contract; Activation authorizes it; and preflight verifies its identity and dependencies. Bounded execution produces a Candidate, validation records findings and evidence, a policy-bound decision selects a declared route, and the run reaches a terminal result, with proposal closure where applicable, before separate Admission or Adoption. Boundary. Accountable principals and their organization retain responsibility. Reconstructable evidence can show what was authorized and observed, but does not prove that the original intent or every check was correct.

Back to the concept index

A practical starting point

Do not begin by implementing every concept. Choose one recurring change with bounded effects and a meaningful acceptance signal.

Declare the property that must hold. Fix the authority that defines it. Bound the allowed effects. Protect one acceptance rule from candidate rewrite, run its check, and record the result with provenance. Keep run completion separate from Admission or Adoption.

Once that small Workflow produces comparable evidence and finite failure, it can earn a place inside something larger.