Appendix B: Core Vocabulary

Direction and State

• Map: 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.
• Terrain: 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.
• Candidate: A proposed state: neither admitted Terrain nor an adopted Map or policy.

Work and Evidence

• Evidence: 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.
• Workflow: 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.
• Loop: 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.
• Mission Object: 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.
• Run Record: 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.
• Context Graph: 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.
• Context Packet: The scope- and size-bounded, ordered, provenance-bearing input assembled for one Mission from its authority and evidence.
• Ledger: 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.
• Oracle: The source or decision procedure allowed to settle a declared property.
• Software Development as Code (SDaC) Engine: 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.
• Governed Loop Network: 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.
• Semantic Density: The concentration of distinct, decision-bearing meaning in context. Useful context combines Semantic Density, Correctness, and Relevance rather than maximizing volume.

Roles and Controls

• Sensor: A read-only measurement of Terrain or retained evidence that emits structured observations with provenance.
• Effector: 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.
• Stochastic Generator: 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.
• Validator: 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.
• Judge: 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.
• Map-Updater: 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.
• Maintenance Controller: A recurring selector that senses, qualifies, and ranks eligible maintenance work without inheriting authority to perform it.
• Governance Mission: 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.
• Scope Guard: Runtime enforcement of the declared effect boundary, including attempted filesystem, process, network, credential, platform, data, and deployment effects.
• Mission Gate: The candidate-independent admission check that revalidates a supported proposal against current base, policy, effects, evidence, and approvals.
• Ratchet: 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.
• Physics: 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.
• Protected Control Plane: The authority boundary around policy, trusted Validators, credentials, execution limits, evidence sinks, and Activation, Admission, and Adoption mechanisms that ordinary work cannot rewrite.
• Deterministic Sandwich: Deterministic preparation and validation around one probabilistic invocation with declared input and output bounds.
• Bounded Refinement Loop: 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.

Outcomes

• complete: 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.
• no_change: A terminal result indicating that the required property already held and no candidate effect exists. The Run Record is sealed.
• blocked: A terminal result that names the external repair or decision required before a new linked run can proceed. The Run Record is sealed.
• failed: 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.

Authority Events

• Activation: The separately authorized event that permits one exact Mission identity to run.
• Admission: 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.
• Adoption: 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.

Architectural Frames

These frames organize existing mechanisms across the system. They are not additional runtime components or authority events.

• Intent Compilation: 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.
• Admission Horizon: 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.
• Torus: 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.
• Engineering Trust Spine: 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.

Precision Modifiers

These modifiers qualify a mechanism; they are not additional architectural concepts. Keep one only when its contrast matters.