Appendix D: Glossary & Translation Guide
Developing and operating reliable autonomous systems demands a precise, shared vocabulary. This appendix defines the canonical terms used throughout this book and provides a small translation layer to familiar industry language.
Software Development as Code (SDaC)
Software Development as Code (SDaC) is the discipline of turning stochastic generation into a reliable engineering process: deterministic context selection, hard gates, and verifiable loops that produce diffs you can review.
This glossary is tiered the same way the book is: start with Tier 1 and you’ll have enough vocabulary to build a working loop.
Tier 1 (Substrate: use everywhere)
Map: Structured, version-controlled intent and memory (docs, contracts, inventories, derived views, and higher-level operating memory).
Terrain: Reality-as-code (source, configs, schemas, runtime behavior).
Ledger: Append-only evidence (diffs, validator output, decision traces, run metadata).
Physics: Deterministic constraints that shape a stochastic process (schemas, linters, tests, architectural rules, budgets, stopping conditions).
Mechanism: A specific, runnable detail (a validator, a parser, a build target, a CI gate) — not a metaphor.
Deterministic Sandwich: The unit pattern for safe
autonomy: Prep → Model → Validation.
Validator: One deterministic gate (lint, types, schema, contract, policy).
Immune System: The suite of Validators that defines “good enough” for a surface.
Immune System case: One concrete PASS/FAIL case inside the Immune System suite.
Effector: A bounded transformation that proposes a patch/diff to the Terrain (or a Map surface) under constraints.
Sensor: A read-only measurement of the Terrain that emits structured signals (diffs, counts, failing invariants, hotspots).
Agent: A model running inside a constrained environment with explicit Tools, Physics, and a Ledger. It does not “want” anything; it executes a loop.
Engine: The full system: substrate + Sensors + Effectors + Immune System + Judge + Ledger. The model is a component, not the system.
Mission Object: Typed intent and state. A persistent
artifact (YAML/JSON) that acts as an executable pull request: it defines
goal, scope, budgets, and gates, and it records lifecycle status (for
example status and completed_at).
Judge: Consumes validator signals + evidence and decides the next move.
Adaptation State Machine (ASM): The allowed moves after Judgement: Revert, Iterate, Update Environment (and optionally escalate to a Human).
Tier 1 examples (one repo)
- Map:
openapi.json,docs/architecture.md,docs/policy.md - Terrain:
src/,schemas/,infra/ - Ledger: Git history +
build/ledger/<run_id>/(diff + validator output) - Immune System:
make test,make lint,make validate
Tier 2 (Loop: once the loop runs)
The Three-Tier Frame (Substrate → Loop → Governance): A completeness frame: Substrate (Map/Terrain/Ledger + Physics + Context Graph), Loop (Sandwich + feedback), Governance (blast-radius limits + protected graders).
Stochastic Drift: Variance in output and behavior under the same Mission Object and context slice.
Ouroboros Protocol: The iterative loop:
Write → Judge → Refine until convergence or a circuit
breaker. It is named for a loop that feeds itself back into the next
turn and evolves through that feedback, not for a static circle. Refine
is the constrained mutation step in response to a specific failure
signal, producing a smaller, cleaner diff.
Circuit Breakers: Hard stop conditions that keep loops finite (max iterations, max wall-clock, max diff size, min progress).
Review Budget: A cap on how much human review throughput autonomy is allowed to consume (for example max open agent PRs, max PRs per day, diff budgets, and staleness windows).
Structured Error Objects: Machine-readable failures (file, line, error code, failing validator, suggested fix) instead of vague prose.
Feedback Injection: Feed the exact failing signal back into the next iteration (stderr, linter lines, failing test output).
Salvage Protocol: A loss-aversion mechanism.
Failed/reverted candidates are moved into a Quarantine directory (diffs
+ logs + artifacts) rather than deleted (for example
.sdac/workflow-quarantine/) so useful fragments are
recoverable.
Context Architecture: Engineering how context is selected, structured, and bounded so the model can act deterministically.
Operating Map: The higher-level Map of an organization: strategy, architecture decisions, policy, incident learnings, onboarding guidance, brand voice, tone, culture, and other durable constraints that say what the system is trying to preserve.
Directives: Human-authored behavioral laws for the
Agent (for example agent_directives.md). Unlike Physics
(enforced by code), Directives are enforced by the agent instruction
layer and review policy. They define “who you are” and “how you
act.”
Context Graph: A queryable topology of the codebase. Nodes (apps, packages, modules) carry identity (language, framework, build tooling). Edges encode dependencies and contracts. The graph is what lets Drivers select the correct mechanism without guessing.
Hollow Map (Flashlight): A brownfield slicing pattern: build an ephemeral, anchor-based Context Graph for one Mission (reachable imports only, strict budget), then discard it.
Driver Pattern: Decouple intent from mechanism
(Mission says “run tests,” driver selects pytest vs
vitest vs mvn test).
Map-Updater: Sense → Normalize → Compare → Propose patches to keep Map surfaces synchronized with the Terrain.
CI Gate (Map–Terrain Sync): Divergence between Map and Terrain becomes a build failure.
Mission Gate: Run a Mission’s acceptance criteria (Physics) without running the model.
Dry Run (Plan Mode): Run Prep and print
the slice, budgets, and planned gates without calling the model. Catch
“wrong files, wrong scope, wrong cost” before you spend tokens.
Meta-Patterns
Meta-Pattern: Don’t Chat, Compile: Use chat for ideation, but ship work through versioned Missions and deterministic runners (diffs + logs).
Meta-Pattern: Physics is Law: If a change fails Physics, it does not exist. No warnings. No loopholes.
Tier 3 (Governance: maintenance and safety)
Immutable Infrastructure: Protected paths and pipelines that grade and govern the system (validators, CI, policy).
Scope Guard: Blast-radius control via explicit path allowlists (the Mission scope).
Instruction Injection: Untrusted Terrain text that
contains instruction-shaped content designed to override constraints
(often called prompt injection). Defense is channel
separation: compile intent from allowlisted templates, carry untrusted
text only as tagged evidence with provenance, and default to safe
outcomes (defer, file_ticket) when policy
validators trigger.
Ratchet: Monotonic quality metrics: mnew ≥ mold for chosen guardrail metrics.
Neuroplasticity: Safe self-modification capability: the system can accept refactorings and other changes without collapsing into regressions (because it is bounded by Immutable Infrastructure, budgets, and hard gates).
Dream Manifest: Measurable maintenance targets: an entropy backlog expressed as concrete work selectors and memory updates.
Dream Daemon: Scheduled background maintenance (many teams start with the human-approved 90% solution).
Automated Refactoring Under Guards: Measure → Mutate → Measure → Commit/Revert under strict validators, budgets, and protected graders.
Hofstadter Bridge: The boundary where documentation becomes executable constraints: the Map is no longer advisory; it is enforced.
Mirror: An optional advanced case: a system can treat its own operating Map, or a formal derivative of it, as an input to its maintenance and governance loops.
Torus: Bounded autonomy under governance. The governed path by which declared intent meets changing reality and, through memory, validation, and adaptation, converges on the best state that can actually be reached and proved. At organizational scale, it is many bounded loops running in parallel across different levels, from code to strategy, under the same governing pattern.
Meta-Patterns
Meta-Pattern: Recursion: The same toolchain used by humans is used by maintenance loops (Dream Daemon emits Missions; the loop validates changes under Immutable Infrastructure boundaries).
Translation guide (one-time bridge, then use canon)
In enterprise-stack terms, some teams may realize these patterns with graph-based runtimes, BPMN-style orchestration, TRiSM-style governance, and runtime validators. This book remains implementation-agnostic on purpose. Treat those labels as translation metadata, not as replacements for the canon. The primary canon remains Map, Terrain, Mission Object, Validators, Physics, Judge, and Governance.
- Immune System → tests + validator gates
- Effector → transformation pipeline / mutation operator
- Map/Terrain → specification/implementation
- Mission Object → executable change request
- Neuroplasticity → safe self-modification capability
- Graph-based runtime → loop runtime / orchestration of bounded Effectors
- BPMN-style orchestration → explicit process orchestration
- TRiSM-style governance → governance, trust, risk, and security controls
- Runtime validators / guardrails → Physics + Validators + Judge + Mission Gates
Actionable: What you can do this week
Pick one system you operate today and map the Tier 1 terms onto it: what is the Map, what is the Terrain, what is your Ledger, and what is your Immune System? Once you can point to those artifacts, you can start building reliable loops.