Three Surfaces You Can Trust (Map · Terrain · Ledger)

This loop gets practical when three things are explicit: what should be true, what actually runs, and what changed last time.

MAP

Versioned description

The README, spec, or contract you want to keep honest.

TERRAIN

What actually runs

The code and config your system actually runs.

LEDGER

Change record

The diff and check output from the last run.

Example project tree

File

—

read write execute Toggle trace to see what the loop reads, writes, and runs.

Mission Objects (Intent As Code)

A Mission Object is the versioned contract for a unit of work: goal, scope, constraints, budgets, and gates. It turns a vague request into something the loop can compile, run, and audit.

Why it matters

The tighter the mission boundary, the smaller the search space. That is how you get faster convergence without turning a prompt into pseudo-authority.

Constraint tightness 55%

mission.yaml

—

Constraint → Deterministic Gate

Derived interface

Expected retries —x

Convergence rate —/100

Drift risk —/100

Budgets (bounded exits)

Max calls —

Max latency —

If the budget is exceeded, the loop exits with a deterministic failure you can reason about.

Mission State of Record

Status —

Attempt —

Last run —

—

Trade-off

Flexibility —%

Constraint strength —%

Validation Pipeline

Schema compile —

Scope gate —

Quality gate —

—

The Deterministic Sandwich (Keep the model in the middle)

Put the model in the middle. Wrap it with deterministic setup on one side and deterministic checks on the other. The goal is not “trust the model.” It is “trust the loop.”

Interactive model

Increase model variability and you get more retries. Strengthen the gate and you trade acceptance for quality. Either way, the sandwich keeps the result bounded.

Pipeline

Prep

Build request

↓

→

Model

One model call

↓

→

Validation

Parse + gate

Model variability 60/100

Validator strength 70/100

Retries

—x

Quality

—/100

Expected cost

—

Index (calls + evals)

Final result

PASS

Deterministic gate decides.

Candidate attempts

Red = rejected attempt. Cyan = accepted output after the gate.

Skeleton-First Rule (Prevent Map Contamination)

Extract the skeleton from Terrain first, then let the model fill prose around it. If the skeleton changes, fail the update and write a receipt.

Interactive updater

Toggle extraction and run bounded attempts. You should see either a clean PASS or a deterministic ESCALATE when the budget runs out.

Map-Updater loop

Sense/Normalize

Extract skeleton

Propose

Generate prose patch

Validate

Hard skeleton gate

Ledger

State of record

Contamination pressure 40/100

Retry budget 5x

Extractor

Step attempt

Bounded loop

Reset

Canonical skeleton (Sensor)

Proposed skeleton (Map)

Mismatch count

Contamination risk

0/100

Skeleton gate

PASS

Budget remaining

Constraint → deterministic gate

Skeleton must match exactly PASS

No invented structure PASS

Retry budget not exceeded PASS

Receipt written to Ledger PENDING

Updater state of record

Status READY

Attempt 0/5

Last run --

ledger/map-updaters/skeleton-first/attempt-00.json

Mismatch trend (W=4)

Collecting baseline.

Ready to run one bounded attempt.

Loop attempts

Cyan = PASS, red = FAIL, violet = ESCALATE

Validator Bundles (Make “good” explicit)

Validators are the hard checks. Budgets stop the loop from grinding forever. Together they turn open-ended iteration into a bounded system.

Interactive model

Turn checks on and off, adjust the retry budget, then run the bundle and watch what becomes provable.

Checks in the bundle

Retry budget 4 attempts

Results

Sample diff (incoming patch)

Run record

run_000

Ouroboros Protocol (Write → Judge → Refine)

This is the retry loop behind reliable agent work: produce one bounded candidate, run deterministic checks, then retry only against the exact failure signal. Repeat until the checks pass or the circuit breaker stops the run.

Clear stop conditions

Write → Judge → Refine Stop on PASS (checks pass) or when the loop budget runs out (escalate). The Judge can send the next step to refine, rewrite, or re-scope.

Interactive loop model

Target quality 86/100

Circuit breaker 8 loops

Refinement strength 55/100

Stochasticity 45/100

Scenario presets

Manual controls. Choose a preset to model a specific loop regime.

WRITE

JUDGE

REFINE

Loop count

Current quality

52/100

Open errors

Status

READY

Minimum progress window (W=4)

Collecting baseline.

Run the loop to inspect error signatures.

Structured error object

Ready. Run one bounded cycle.

Loop outcomes

Cyan = PASS, red = refine, violet = escalate

Ratchets (Quality Floors That Only Move Up)

Ratchets turn quality expectations into executable law. A candidate may fail, but the floor does not move down. If a candidate passes deterministic guards, the floor moves up and future loops start from a stronger baseline.

Admission loop

1) Measure baseline metrics. 2) Mutate one bounded candidate. 3) Validate ratchets + policy gates. 4) Decide raise the floor, reject, or route to human review.

Deterministic guard rules

test_count_new >= test_count_old coverage_new >= coverage_old lint_new <= lint_old security_new <= security_old If all ratchets pass, policy decides: allowlisted auto-merge or explicit human approval.

Scenario runner (deterministic)

Small bounded mutation that should raise quality and pass ratchets.

1 Measure

2 Mutate

3 Validate

4 Decide

Test count

480 -> 481

Coverage

88.0% -> 88.0%

Lint violations

6 -> 4

Security findings

2 -> 2

Current floor

72/100

Candidate quality

75/100

Ratchet gate

READY

Decision

Run scenario

Gate trace

test_count: READY

coverage: READY

lint: READY

security: READY

quality floor: READY

policy gate: READY

Floor vs candidate

Floor

Candidate

Ready. Run a candidate through deterministic guards.

Attempts

Cyan = floor raised, red = rejected, violet = human gate

Always-On Loops (Maintenance That Compounds)

A Dream Daemon is not a cron job. It is a bounded control loop that senses entropy, picks one target, and exits with a deterministic decision: PASS, DEFER, or ESCALATE.

Timeline Week 8/26

Active loops

Cycle budget 6x

Entropy debt

—/100

Incidents

—/wk

P95 cost/outcome

—

Budget remaining

Selected target

—

Expected gain: —

The chart shows the long-horizon trend. The controls below model the bounded loop: one target per cycle, a hard budget, and deterministic admission gates.

Debt (left axis) vs P95 cost/outcome (right axis). The dashed marker tracks the selected week.

Constraint → deterministic gate

Signal ranker improves debt trajectory PENDING

Guardrails active (map + governance) PASS

Cycle budget not exhausted PASS

Receipt written to Ledger PENDING

Daemon state of record

Status READY

Cycle 0/6

Last run --

ledger/dream-daemon/week-08/cycle-00.json

Minimum progress window (W=4)

Collecting baseline.

Ready to run one bounded cycle.

Cycle outcomes

Cyan = PASS, amber = DEFER, violet = ESCALATE

Sensor Hierarchy (UML-Style)

Treat Sensor as a base interface, then specialize by terrain surface. Different sensors emit different signal shapes, cadences, and confidence profiles.

Base contract

class Sensor + read(): Signal + descriptor(): SensorDescriptor + mode: READ_ONLY Judge consumes the emitted signal; Effectors own mutation.

Interactive model

Base Class

Sensor

read() | descriptor() | mode=READ_ONLY

Environment volatility 34/100

Sensor bundle

AST Contract Runtime Economic

Active sensors

Coverage

Blind spots

Signal confidence

0/100

Selected sensor descriptor

Emitted bundle signal

Select a class and emit a bundle signal.

Event stream

Blue = emit, red = blocked write

Governance Envelope (Policy + Evidence)

Governance at machine speed is not just a verdict path. The model proposes, policy decides, the ledger records why, and runtime evidence hardens later Maps, policies, and Missions.

Execution path

Mission -> Policy Validators -> Decision -> Ledger Event -> Hardening Feedback Outcomes are explicit: allow, block, escalate, or warn (time-bounded exception). Policy precedence resolves conflicts: security > scope > architecture > style.

Core deterministic checks

scope_guard(paths) = PASS|FAIL secrets_scan(diff) = PASS|FAIL dynamic_exec_scan(diff) = PASS|FAIL architecture_guard(diff) = PASS|ESCALATE

Feed-forward assurance

Incidents, audit findings, Dream outputs, and Map-Updaters produce evidence. That evidence feeds into tighter policies, budgets, and future Missions. Runtime assurance strengthens later deterministic gates; it does not replace them.

Deterministic scenario runner

Low-risk refactor inside allowlisted scope.

1 Compile

2 Evaluate

3 Decide

4 Record

Exception TTL 7 days

Exception state: none

Selected case

Allowlisted Refactor

Verdict

READY

Policy action

Predicted: execute

Ledger run

Gate decisions

precedence hit: none

scope_guard: -

secrets_scan: -

dynamic_exec: -

architecture_guard: -

Ledger event

Select a case and evaluate policy outcomes.

Next hardening: current policy envelope was sufficient.

History

Cyan = allow, red = block, violet = escalate, amber = warn

Presentation Notes: Practical Programming

Architects of Intent

Three Surfaces You Can Trust (Map · Terrain · Ledger)

Mission Objects (Intent As Code)

The Deterministic Sandwich (Keep the model in the middle)

Skeleton-First Rule (Prevent Map Contamination)

Validator Bundles (Make “good” explicit)

Ouroboros Protocol (Write → Judge → Refine)

Ratchets (Quality Floors That Only Move Up)

Always-On Loops (Maintenance That Compounds)

Sensor Hierarchy (UML-Style)

Governance Envelope (Policy + Evidence)