Bounded execution examples

Read this after the two reference pages: this page shows how the rules behave in practice, not new policy.

The loop you are watching

Each example is one pass (or one campaign item) through the same sequential, human-gated loop:

The loop spends the abundant (time, deterministic checks, local calls) before the scarce (tokens, review). Verify failures trigger bounded repair; ambiguity or budget exhaustion escalates to a human — who still approves the branch or merge.

Sub-level claims add distinct assay evidence on top of the level's core gates:

The driver produces machine records; the assay gate enforces _check_sublevel rules; Wiki M is canonical and Wiki H is derived with a freeze gate.

Two ideas make the examples readable:

• Routing tier is the engine the router selected (deterministic, local, escalate).
• Worker ladder is what actually ran inside the draft step: local (Granite) → cursor → deterministic → fake. Stepping from Granite to Cursor is a within-loop move — it is not the same as loop escalation to a human.

How to read each example

---

Example 1 — L1 offline, zero tokens (deterministic fixture)

The cheapest possible run: a deterministic fake worker fixes a failing multiply test with no model and no network. This is the offline CI baseline.

Phase trace (from the generated report):

context - ok        3 items
plan - ok           pu-target-0; allowed=1
draft-unit - ok     fake; 1 file(s); fixture=.../multiply_fix.json
apply+verify - ok   changed=['calculator.py']
assay - ok          all core evidence present

Teaching point: when a deterministic fixture (or rule, script, or CI check) can settle the task, no LLM is invoked at all. Winner backend: fake.

Evidence: runs/campaigns/poc-boundary/poc-sandbox-offline/run-*/{machine,human}/

---

Example 2 — L1 on a real target, with a worker-ladder step

Same L1 shape, but on a real docs fixture and with a live model. The router picks local, Granite stalls, and the worker ladder steps to Cursor — all without escalating the loop to a human.

Phase trace:

context - ok        4 items
plan - ok           pu-target-0; allowed=2
draft-unit - ok     cursor; 1 file(s); model=composer-2.5
apply+verify - ok   changed=['README.md']
assay - ok          all core evidence present
promote - fail      live repo missing (promotion safely skipped)

Teaching point: the worker ladder (local → cursor) is how the loop spends time before tokens and recovers from a weak local draft without a human. escalated: false because no ambiguity/exhaustion forced a human decision. Promotion is a separate, guarded step — it failed closed because there was no clean live tree to write into.

Evidence: runs/campaigns/lenses-production/L1-a-broken-link/run-*/{machine,human}/

---

Example 3 — L2 change-set across two files

L2 raises the unit of delivery to a multi-file change-set with no rearchitecture. The plan produces two patch units, applied and verified in sequence.

Phase trace:

plan - ok             2 patch units (L2)
draft-unit-0 - ok     cursor; 1 file(s); model=composer-2.5
apply+verify - ok     changed=['README.md']
draft-unit-1 - ok     cursor; 1 file(s); model=composer-2.5
apply+verify - ok     changed=['docs/guide/nested.md']
assay - ok            all core evidence present

L1 vs L2 at a glance

Teaching point: L2 is not "a bigger L1." The Assay gate for L2 verifies the proof union contains two or more distinct files — a single-file patch cannot masquerade as a change-set. Only the final patch unit runs the item's verification_argv.

Evidence: runs/campaigns/lenses-production-l2/L2-broken-link-and-nested/run-*/{machine,human}/

---

Example 4 — What "done" means (PDCA Check gates)

Autonomy without gates is just fast breakage. Campaigns wrap the loop in Plan → Do → Check → Act, and "done" is defined by the Check gates.

One item at a time, worktree-isolated. On a Check failure, Act steps to the next worker tier once; promotion needs a clean live tree and is never auto-committed.

Check gates (all must pass):

1. Dual-wiki freeze gate — the human report matches the machine record (see Example 5).
2. Assay gate — forge/forge.config.yaml core evidence: tests_pass, acceptance_criteria_met, risks_reviewed.
3. Driver final_status == pass.
4. Optional verification_argv — pytest, a link checker, or inline asserts on the final unit.

Promotion policy: even when every gate is green, changes are copied worktree → live only if git status --porcelain is clean, and there is no auto-commit — the operator commits manually. If the tree is dirty, promotion is skipped and recorded in promote.json (this is exactly what "promote - fail" meant in Example 2).

Teaching point: the human gate does not disappear at higher throughput — it moves to a clear, evidenced decision point.

---

Example 5 — Auditability without drift (dual-wiki trace)

Every run documents itself on two synchronized surfaces so a human can back-trace decisions.

Machine records are the source of truth; the human report is generated from them. A freeze gate re-derives the narrative and fails on any mismatch.

Teaching point: the reports you read in Examples 1–3 are generated, never hand-written. The freeze gate guarantees the story can never silently drift from what actually happened. The rule is blunt: never hand-edit report.md — change the machine records or the generator, then regenerate.

---

Example 6 — When the loop should stop (escalation and honesty)

Escalation is a feature, not a failure. The router is deterministic about when to spend scarce resources instead of pretending a small local model can do everything.

Default when local quality is marginal: decompose (spend free time), not escalate (spend scarce tokens).

Cloud escalation is gated: it requires value == must_have and local_stalled and decomposition_exhausted. Track escalation rate over time — a rising rate signals weak scaffolds or mis-sized autonomy, not "smarter" automation.

Teaching point: the honest local-first posture is local-first with ROI-gated escalation. Fully cloud-free autonomy above L1 is not realistic on a ~4GB profile — planning, architecture, and ambiguity exceed small-model capability. See resource honesty.

---

Example 7 — L3 use-case slice across logic, docs, and UI

L3 raises the unit of delivery to an end-to-end user-visible flow inside one existing app. The plan produces three patch units across distinct layers, and Assay requires cross-layer and E2E evidence.

Phase trace:

plan - ok             3 patch units (L3)
draft-unit-0 - ok     deterministic; app/scanner.py (logic)
draft-unit-1 - ok     deterministic; README.md (docs)
draft-unit-2 - ok     deterministic; ui/index.html (ui)
assay - ok            all core evidence present

Like Examples 1–3, the human report.md is generated from machine records under runs/.../machine/ — see Example 5 — dual-wiki trace. Do not hand-edit the narrative; regenerate from machine JSON if the story drifts.

L2 vs L3 at a glance

Teaching point: L3 Assay verifies ≥2 distinct layers, both .py and non-.py files in the proof union, and E2E pass in tests_run — a multi-file docs-only patch cannot masquerade as a use-case slice.

Evidence: runs/campaigns/lenses-production-l3-ci/L3-ui-smoke/run-*/{machine,human}/

---

Example 8 — L2.1 mechanical multi-file (hypothetical, worked-through)

Hypothetical case — no matching campaign run exists today; this narrative shows what an L2.1 pass would look like and how _check_sublevel would enforce it.

A codemod-style rename across two Python modules: the plan applies the same-shaped hunk (one added line, one removed line per file) to utils/helpers.py and utils/compat.py without touching any test files.

Teaching point: L2.1 is for mechanical, same-shaped edits across files — not defect fixes (L2.2) and not behavior changes with new tests (L2.3). A rename that accidentally edits a test file fails the L2.1 sub-level check even if L2 core evidence (≥2 files) passes.

Evidence pattern (if run): runs/campaigns/<campaign>/<item>/run-*/{machine,human}/ with machine/assay.json recording sublevel: L2.1 and hunk_shapes.

---

Example 9 — L3.2 production-repo slice (hypothetical, worked-through)

Hypothetical case — no matching campaign run exists today; this narrative extends Example 7's L3.1 sandbox slice to a production repo on a branch.

The same three-layer slice (logic + docs + UI) runs against forge-lenses on a feature branch instead of the sandbox app. All L3.1 evidence holds, but target_repo is outside the sandbox allowlist.

Teaching point: L3.2 inherits all L3.1 checks and adds the production-repo boundary. A sandbox slice cannot claim L3.2 even with identical file patterns — the assay reads target_repo against the sandbox allowlist.

Evidence pattern (if run): runs/campaigns/<campaign>/<item>/run-*/{machine,human}/ with machine/run.json declaring target_repo: forge-lenses and sublevel: L3.2.

---

What these examples do not show

• Unsupervised push/deploy — every example stops at a human-gated branch/merge or a guarded promotion; nothing ships without a person.
• L4+ autonomy — feature, subsystem, product, and multi-platform levels remain vision requiring ADRs, go/no-go, and strategic checkpoints.

Related

• Autonomy levels — L0–L8 ladder, Assay enforcement, 4GB honesty
• Forge Platform autonomy levels — per-level reference architecture and readiness matrix
• Respecting resources — scarce vs abundant, decompose-before-escalate
• Cost-aware planning and model tiering — the interactive Cursor counterpart
• Agentic SDLC — humans own intent; agents amplify execution

Related pages

• Forge — artifact and decision model
• Autonomy levels
• Autonomy maturity framework
• ForgeSDLC — concept map and term-collision…
• Cost-aware planning and model tiering