The Deterministic Spine

Published 2026-09-14 · Revised 2026-09-29 · Revision history

Technical verification is documented with the individual claims.

By Yianna Kokalas & Claude

Position: models should own judgment; executable code should own control. In the agent system described here, every repeatable lifecycle operation should move into a tested state machine that stops when the evidence needed to proceed is missing. Models remain workers at the places where the answer must be synthesized: planning, implementation, diagnosis, review, and repair.

The setting is software built for the Magic: The Gathering community, with real users. The drain is the program that takes approved tickets through implementation, review, and deployment checks. Its /implement workflow runs a supervisor session that calls separate implementation and review agents. The question in this paper is which parts of that workflow still need a model to decide what happens next.

This paper presents an architectural decision and a partly completed migration. The September 29 measurement now shows lower costs and fewer model-issued commands after an initially more expensive rollout. The gains followed several changes together: script cleanup, revised review instructions, a different reviewer model, and a rule that opens a repair cycle only when a reviewer returns FAIL. Section 8 separates what improved from what we can attribute. Review quality remains unmeasured.

bin/drain remains the durable outer state machine. The target is for deterministic scripts under /implement to decide when a worker may run, what evidence it receives, what contract it must return, and which verified state transition may follow. The worker decides the part code cannot: what should be built, what is wrong, and how to fix it.

The September 4, 2026 audit found that 49 of 52 skill entry points required model interpretation. A skill is a reusable set of instructions for an agent. This counts entry points, not the proportion of work that needs judgment. The drain already enforced important decisions in code, including queue admission, timeouts, and deployment checks. Inside /implement, however, the model still interpreted instructions for setting up worktrees, running checks, and handling commits and pull requests.

The frozen baseline recorded on September 6 contains 165 dispatches, of which 151 have a terminal result. Backend dispatches had a median of 151 Bash calls and 20.7 million billed cache-read tokens (previously cached input reused by the model); frontend dispatches had 140 calls and 17.4 million cache-read tokens. A rough command classifier labeled just over half the Bash calls mechanical. Some of those commands read code, so the classification is not a count of work we can safely remove.

A script can combine several repeatable operations into one invocation and return a compact result. That may reduce model requests and the context carried into later requests. We cannot infer an exact saving per Bash call: calls can share a message, and streaming records are not identical to billable requests. Lower measured usage still needs to be assessed alongside reliability and review quality.

1. The boundary

The target boundary is a rule:

If the same validated observed state should always produce the same next action, that action belongs in the deterministic runner. If the action requires interpretation, synthesis, or adversarial judgment, it belongs to a model behind a typed contract.

A typed contract specifies the fields and values a result must contain before code can use it. The contract checks the response’s structure; it cannot establish that the reviewer found every defect.

---REVIEW RESULT---
reviewer: correctness
verdict: PASS
finding_count: 0
findings: []
---END---

Examples that belong in code:

• Resolve a ticket and repository.
• Claim a ticket, acquire a lock, and create or recover a worktree.
• Select an approved test profile and invoke its argv without a shell re-interpretation.
• Parse exit codes, test reports, GitHub state, and deploy probes.
• Enforce file scope, budgets, fix-cycle limits, and tree identity.
• Create a commit and PR, compute merge eligibility, merge, tear down, and transition ticket state.

Examples that belong to a model:

• Decide the implementation shape inside an approved ticket boundary.
• Write or change product code.
• Judge whether code satisfies the acceptance criteria.
• Find security and correctness defects not reducible to a fixed predicate.
• Diagnose an unknown failure and propose a repair.

The distinction is semantic, not tool-based. A model invoking git, gh, and test commands is still model-mediated control. A runner invoking a model to produce code is still deterministic control around nondeterministic work.

2. The starting point and target shape

At the September 4 audit, the drain owned the durable lifecycle, but /implement still contained both the semantic work and much of the mechanical workflow:

ticket -> drain: claim / timeout / recovery / terminal state
             |
             +-> one /implement supervisor session
                    -> reads 1,426 lines of pipeline prose
                    -> creates worktree / carries lock tokens
                    -> invokes implementation agent
                    -> chooses and parses tests
                    -> keeps pre-merge review/fix loop in-session
                    -> commits / creates PR / computes merge branch
             |
             +-> drain: deploy and smoke verification / post-deploy recovery

The target makes the deterministic spine continuous without creating a second outer runner or forcing the healthy fix loop out of its supervisor session:

                              BIN/DRAIN
                     durable claim / recovery / truth
                                  |
                                  v
                      ONE /IMPLEMENT SUPERVISOR SESSION
                                  |
              +-------------------+-------------------+
              |                                       |
     deterministic scripts                    semantic agents
     setup / validate / git / PR          IMPLEMENT -> REVIEW -> FIX
     manifests / checkpoints                   ^             |
              |                                +-------------+
              +-------------------+-------------------+
                                  |
                                  v
                              BIN/DRAIN
                       deploy / smoke / terminal state

 resume is a recovery edge back into the same supervisor session,
 after drain reconciles durable state; it is not the normal loop

The existing phase prose is not discarded. It is a requirements corpus: each scar, invariant, fail-closed rule, and recovery condition becomes a runner branch plus a regression test. The migration succeeds only if the code preserves those earned rules.

Here, a manifest means a saved record of the run’s identity, worktree, and completed phases. Idempotent commands check that record and the observed state before acting, so repeating a completed command should recover its result without repeating its effect. Section 6 separates the implemented pieces from the remaining target.

3. The first move: compile /implement mechanics into scripts

The first draft of this paper proposed a deterministic “implementation runner.” That name hid an unnecessary duplication: the drain already is the durable outer runner. The highest-return change is narrower. Compile the mechanical phases into deterministic, idempotent commands that /implement invokes while its existing supervisor session owns the semantic implementation/review/fix loop. Reuse the manifest and contract ideas from bin/lib/pipeline_runner.rb, not its position as another top-level orchestrator.

Intended script responsibilities

1. Resolve and claim
   • Resolve slug, ticket-store row, repository, dependency state, and auto-merge policy.
   • Acquire the ticket claim and implementation lock atomically where possible.
   • Emit a run ID used by every later artifact and transition; the drain remains the authority that created the claim.
2. Prepare
   • Verify clean main, fetch/fast-forward, create or recover the worktree, and record branch/worktree identity.
   • Replace prose-carried lock owner, nonce, paths, and digests with manifest fields.
3. Invoke implementation
   • Give the implementation node the ticket, repository path, worktree, allowed paths, budget, and output-schema location.
   • Permit code judgment; make lifecycle mutations such as merge and ticket transition depend on executable gates. Complete enforcement across every invocation path remains a target, not a property established by this audit.
4. Validate
   • Select an argv-array test profile from a checked-in repository manifest. The /implement supervisor calls this deterministic command and consumes its artifact.
   • Run formatter, tests, lint, build, budget, scope, and tree-integrity checks with explicit timeouts and captured results.
   • Produce one canonical validation artifact. A missing result is failure, never PASS.
5. Review and repair
   • The /implement supervisor invokes correctness and security review independently.
   • Validate each result against a schema and preserve finding IDs across repair and re-review.
   • Keep the bounded pre-merge back-edge inside that live supervisor session. Scripts persist the current cycle and artifacts; they do not replace the semantic loop.
6. Land and verify
   • Verify the committed tree equals the validated tree.
   • Push, create or recover exactly one PR, probe GitHub independently, and calculate merge eligibility from validated artifacts and store policy.
   • Merge and clean up through idempotent commands. The drain continues to own deploy, smoke-test, recovery routing, and terminal state transitions.

Why the pre-merge fix loop stays in-session

The current /implement dispatch already has the right continuity during a healthy run: one top-level print-mode supervisor invokes the implementation worker, two reviewers, and each fix worker synchronously. Findings and the evolving verdict remain in the supervisor’s context. Fresh worker and reviewer contexts are a feature: fix workers get the complete finding set explicitly, and re-reviewers do not inherit the implementer’s framing.

Keeping this loop in the existing supervisor session preserves its findings and evolving verdict without requiring another context handoff. Deterministic scripts can be called from inside the skill. This is the chosen design; the audit did not compare its cost or reliability with a separate loop controller.

Semantic-node contract

The target is for each implementation, review, and fix worker to return a versioned structured result that code validates before relying on it. A schema checks required fields and allowed values. It cannot establish that a reviewer found every defect. The intended contracts cover:

• Implementation: status, changed paths, claimed acceptance-criteria IDs, summary, and blockers. Test truth does not come from this artifact; a deterministic command measures it.
• Review: reviewer role, verdict, finding IDs, severity, path/line evidence, acceptance-criteria linkage, and whether the finding is blocking.
• Fix: finding IDs attempted, disposition per finding, changed paths, and blockers. Test truth again comes from a deterministic command.

Free-form prose may accompany a structured result. In the inspected implementation, workers return fenced result blocks that are parsed and validated against JSON schemas; they do not all write JSON files directly.

4. Repository profiles, not prompt branches

Repository profiles describe how to validate each supported codebase, including the backend, frontend, extensions, and internal tooling. The checked-in profiles supply:

• Repository resolution rules
• Safe formatter argv
• Targeted and full-suite argv
• Lint/build argv
• Required environment and toolchain pins
• Default timeouts

Deployment verification remains the drain’s responsibility; these profiles describe the validation commands run within an implementation worktree.

Profile commands are argument arrays. The validation command checks any selected test paths before running the approved command. This moves command construction and result parsing into code, although the supervising model still invokes it.

schema_version: repo_profiles/v1
profiles:
  BE:
    env:
      ASDF_RUBY_VERSION: "3.4.7"
    test_targeted:
      - env
      - RAILS_ENV=test
      - bin/rails
      - test
      - "{files}"
    targeted_end_of_options: true
    targeted_path_patterns:
      - "test/**/*_test.rb"
    timeouts:
      test_targeted: 60

The historical audit also recorded repeated environment and toolchain probes. Profiles make those settings explicit and reusable, but the existence of a profile does not show that every redundant probe disappeared. Section 8 reports the later measurements and the work that remained duplicated.

5. Session continuity and recovery

At the September 4 audit, the drain did not retain a resumable session identity:

• implement_cmd and every post-deploy fixer attempt passed --no-session-persistence.
• Stream JSON included session_id, but the drain kept it only in the forensic log; it was not part of the parsed outcome, ticket store, telemetry, or a run manifest.
• The post-deploy self-heal loop persisted its attempt number, branch, and worktree, but each attempt started a fresh Claude session.

The adopted design gives the drain responsibility for session continuity:

1. Generate a UUID in the drain before spawning /implement and pass it through --session-id; do not pass --no-session-persistence on resumable lanes.
2. Persist {run_id, slug, dispatch_token, session_id, phase, attempt, forensic_log} before the child starts. Do not hide session identity only in a best-effort log.
3. On API interruption, missing terminal result, or drain restart, reconcile store, worktree, commit, PR, and deploy facts before deciding whether continuation is safe.
4. Resume with claude -p <recovery prompt> --resume <session_id> under a separate, bounded continuation budget. A hard timeout is not automatically resumable: a looped session may simply repeat its loop.
5. Make every deterministic phase command idempotent against its manifest checkpoint so a resumed model cannot create a second worktree, commit, PR, merge, or state change.
6. For post-deploy self-heal, allocate one fixer-session UUID for the whole <=3-attempt sequence and resume it between attempts. The reviewer subagents inside an attempt may remain fresh.

Session persistence preserves reasoning context. Durable manifests and idempotent scripts preserve correctness. Neither substitutes for the other.

The September 14 source check confirms that normal dispatches now receive a saved session identifier and omit --no-session-persistence. The continuation path checks the recorded state against the repository and ticket state, validates the identifier, and records that its single continuation allowance has been consumed before spawning. Hard timeouts remain ineligible for this continuation path. Source and fixture checks establish these mechanisms; production recovery effectiveness remains unmeasured here.

6. Migration sequence

One phase concerns which browser tests to run for a change. A scenario is a repeatable user workflow described as actions and expected results. We write its steps in YAML, and our compiler turns them into Playwright tests. Playwright automates the browser and can run headlessly, without a visible browser window. Scenario selection means choosing the workflows that exercise the behavior a ticket changes.

Recorded migration status

The internal status record through September 11 reports five phases landed and one planned. “Landed” means that the phase’s implementation work was recorded as merged; it does not establish that all target invariants hold or that its benefits were measured. The September 14 audit checked selected mechanisms in the current source. It did not verify deployment of every phase or query the live ticket queue.

The phase descriptions below preserve the adopted plan. The table above records implementation progress and departures from it as inspected in September 14’s audit; it is not a current inventory. Section 8 adds the September 29 outcome measurement.

One rollout lesson is already concrete. A budget-stopped run left a clean worktree and an open pull request. Redispatch then tried to choose a different branch and refused the surviving worktree. The operator finished the work, and an improvement was proposed to recognize and adopt a matching existing worktree. This is why recovery needs to check the effects of a previous attempt before starting another: a clean restart can still disagree with valid work already on disk. The incident supports that design requirement; it does not measure the reliability of the migration.

Phase A: Observability and contracts

• Add one run manifest spanning drain dispatch through deploy verification.
• Persist the drain-created Claude session ID and expose it in forensic metadata.
• Measure phase duration, model turns, tool calls, retries, and terminal reason.
• Measure billed tokens per dispatch and distinguish supervisor and worker activity. Per-phase token attribution remains a desired extension; stream usage is not a substitute for reconciled billing totals.
• Define and validate implementation/review/fix artifact schemas while the existing prompt pipeline still runs.
• Reject malformed contracts for consequential transitions, initially in shadow/report mode and then as a hard gate.

Phase B: Deterministic /implement primitives

• Implement idempotent phase commands and repository profiles under the existing drain.
• Port phase 0 setup, phase 3 validation, phase 4 commit, phase 5 PR handling, phase 6 teardown, and merge eligibility. Keep the healthy pre-merge fix loop in the supervisor session, with its cycle/artifact checkpoint persisted by the commands.
• Turn each incident comment in the current skill into a regression fixture before removing the corresponding prose branch.
• The plan called for rollout by repository profile, beginning with the backend and frontend. The implementation record says all profiles shipped together, so the planned staged rollout should not be presented as the rollout that occurred.

Phase C: Bounded session resume

• Enable persisted, drain-assigned UUIDs for /implement.
• Add reconcile-before-resume and one bounded continuation lane for recoverable interruptions.
• Reuse one persisted parent fixer session across post-deploy attempts.
• Measure resume success and duplicate-effect prevention before enabling timeout resume.

Phase D: Deterministic scenario dependency selection

• Require user-facing tickets to declare scenario names at promotion, or resolve them through a checked-in path/capability-to-scenario map.
• Validate that every referenced scenario exists.
• Use a semantic scenario-exploration node only when the manifest proves coverage is absent, not as the ordinary selection mechanism.

Phase E: Signature-first failure classification

• Extract timeout, budget, upstream API, test-no-result, toolchain, collision, and state divergence from structured envelopes and known signatures.
• Keep the RECOVERY table authoritative.
• Ask the local classifier only about unknown free-text tails. Its output may suggest an escalation label, but cannot independently authorize retry or mutation.

Phase F: Thin command surfaces

• Move /promote, /land, /post-merge, and /scenario-run to direct command wrappers wherever inputs and outputs are structured. The pattern extends the existing command wrappers used for document and ticket checks.
• Retain a model layer only for the genuinely semantic fallback: ambiguous ticket resolution, missing scenario design, or synthesis of a new follow-up.

7. Rollout and reversibility

The adopted rollout plan asked each command to earn authority in stages:

1. Fixture mode: replay captured manifests and failure artifacts with no external mutation.
2. Shadow mode: deterministic commands compute planned actions beside the live prompt phases, but do not perform them. Compare next-state decisions and surface divergence.
3. Profile canary: the commands own one repository profile and a bounded ticket class.
4. Default with escape hatch: expand only after the canary window; retain a deliberate operator-only legacy path during the initial rollout.
5. Retire prose execution: after parity, keep the old prose as history or concise model-role guidance, not as a second live state machine.

Shadow mode must never double-execute mutations. It compares plans and observations; the drain remains the durable outer authority and there is still exactly one writer.

This sequence is a design prescription. The records inspected here do not establish that every command passed through every stage, and the all-profile rollout in phase B departed from it. A migration account must retain that difference.

8. Success measures

The engineering targets are:

• 100% of consequential git and PR effects are emitted by idempotent commands, and 100% of deploy and terminal ticket transitions remain drain-owned.
• 100% of semantic nodes produce schema-valid artifacts; missing means fail-closed.
• The scripts can replay every known worktree, lock, wrong-PR, backgrounded-suite, tree-integrity, timeout, and state-divergence incident as a deterministic fixture.
• Median model-issued Bash calls fall by at least 50% within each repository cohort.
• Median billed cache-read tokens fall by at least 30% within each repository cohort, while the review and deployment checks retain their quality. This is a cache-read target; total token use and monetary cost must also be reported separately.
• Wrong-worktree, wrong-PR, stale-lock deletion, and “claimed green without a result” incidents remain at zero across 100 consecutive script-backed dispatches.
• Reviewer catch rate and post-deploy verification quality do not regress.
• A recoverable session interruption resumes the same drain-recorded session without a duplicate worktree, commit, PR, merge, or ticket transition.
• Cost and elapsed time fall, but never by weakening semantic review or fail-closed gates.

The targets cover both efficiency and quality; the measurements below assess which parts we can establish. The frozen September 6 baseline supplies the following comparison values. A dispatch is one invocation of the implementation workflow. A terminal result can report an error; it does not mean the ticket succeeded.

The repository comparison, measured September 29

The comparison protocol selects September 6 at 19:53:03 Eastern time as its after cutoff, the first dispatch recorded as entering all four compiled phase groups. The September 14 audit had only one backend dispatch and no frontend dispatches after that cutoff. The frozen September 29 snapshot now contains 58 backend and 36 frontend dispatches after it, enough to meet the comparison command’s minimum of 15 on each side of each repository comparison.

Backend median Bash calls fell 70% and cache-read tokens fell 69%; frontend fell 68% and 64%, respectively. Both clear the numerical 50% and 30% thresholds. Median cost fell from $13.34 to $3.37 for backend dispatches and from $10.91 to $3.33 for frontend dispatches. Median output tokens fell from 121,900 to 42,127 and from 109,214 to 37,785. These are observed reductions across the whole later workflow, not an estimate of what the compiled commands alone saved.

The cohorts still differ in ticket size and class; the after groups include 15 backend and three frontend dependency-update dispatches. Modified-file counts are not in this snapshot. Internal tooling is kept separate: across its entire after window, median cache reads rose from 11.8 to 20.0 million and median cost rose from $8.81 to $10.07. Its early expensive runs remain part of that comparison.

The written protocol says “15 dispatches per repo cohort, or 30 across BE and FE combined”; the command requires 15 on each side of each repository comparison. Both repositories now satisfy the stricter count, so that ambiguity no longer decides sample eligibility. The baseline note also calls the protocol preregistered, but its first preserved commit is September 6 at 21:46:24 Eastern time, after the selected cutoff. That history still does not establish that the protocol was recorded before any after results existed.

The cost of getting there

The aggregate before-and-after comparison hides an expensive first stage. To see when costs changed, the next table includes only dispatches whose result footer says SUCCESS, pooled across repositories. That avoids making short blocked attempts look like cheap completed work. It also excludes failed attempts and successful work without a footer, so it is not a cost per landed ticket.

The baseline ends September 5 at 14:18:40. The early-rollout row includes five successful dispatches in the transition before the September 6 after cutoff; 43 successes lie after that cutoff and before September 24 at 22:00. The next boundary is September 26 at 08:37, when the repair-policy change landed. All times are Eastern, and the final period ends at the September 29 snapshot. The table uses arithmetic means where labeled and the original tool’s observed-rank cost median throughout; these differ slightly from the averaged-middle medians in the September 29 write-up.

Early rollout increased both usage and cost. The September 17 investigation, described in Field Note 001, found why the existence of scripts was insufficient: cleanup removed a worktree before the merge gate checked it, and agents repeated mechanical procedures that the scripts were meant to replace. The September 22–24 changes removed fallback instructions, moved cleanup after the merge check, and gave reviewers a shared command to obtain the change set. Those changes repaired concrete conflicts in the workflow; their independent effects were not measured.

In the short period after that cleanup and before the repair-policy change, pooled successful-dispatch means were about 30% lower for Bash calls but only 4% lower for cache reads than the baseline. After the policy change, they were 66% and 59% lower. The earlier period contains only 30 successes and a different repository mix. These means explain the chronology; they do not replace the per-repository median targets above.

What we can attribute

On September 26, the supervisor instructions changed to open a repair cycle only when a reviewer returns FAIL. A PASS with warning findings now carries those warnings into the report without starting another repair and review round. The same change tells the supervisor to verify a fix agent’s claim that it changed nothing, then stop without another review of the unchanged tree.

This is a workflow-policy change interpreted by the supervising model. It is not a new compiled gate. Across successful dispatches on either side of its boundary, the share with no fix cycle rose from 1 of 30 (3%) to 73 of 91 (80%); mean fix cycles fell from 1.53 to 0.22. The logs show a large reduction in repair work consistent with the rule. They do not measure how much of the total saving it caused, or whether every skipped warning deserved only a follow-up.

The reviewer change cannot be separated from the cleanup. Reviewer instructions adopted bin/impl-diff on September 24, about two hours before the model behind their opus alias changed. No dispatch ran between the two changes. The next observed reviewer model was claude-opus-5-5, replacing claude-opus-5. Fewer calls and lower bills therefore do not identify how much came from the command, the rewritten instructions, or the model.

A narrower comparison holds the implementer model at claude-sonnet-5 and selects successful dispatches with exactly one fix cycle. Median Sonnet-billed cost fell from $5.87 in 23 baseline dispatches to $4.46 in 15 dispatches after the policy change, about 24%. This supports a smaller improvement even when the number of repair cycles is held fixed. It is not a determinism-only estimate: ticket mix, reviewer behavior, and selection into the one-cycle group still differ. Billing is allocated by model, not cleanly by workflow phase.

The implementer’s later move to claude-sonnet-5-5 has only 12 successful dispatches in the snapshot, five of them dependency updates. That sample does not establish a separate saving from the newer implementer model. Resolved model IDs in the logs matter here: unchanged aliases did not mean unchanged models.

Quality and reliability remain open

The numerical efficiency thresholds are met in the observed repository cohorts. The full success criteria are not. We have not measured reviewer catch rate or established unchanged post-deploy quality. The lower repair count is a change in work performed, not a measurement of defects caught.

The original rough 30–45% estimate was not a physical ceiling, as the September 14 public edition already explained. A larger saving does not prove that useful work was lost. Here, however, we know that fewer repair and re-review rounds ran. That needs a quality check before the saving can support the full efficiency claim.

Reliability counts need their own denominators. The snapshot’s timeout_or_killed category fell from 14 of 165 baseline dispatches to three of 176 after September 24. The timeout allowance also changed during the migration, and this category means no terminal billing result was found; a recent dispatch may still have been running when the snapshot was taken. It is not a pure measure of pipeline-caused timeouts. Of those 176 later dispatches, another 29 have billing results but no dispatch footer. Neither group can simply be counted as failed or landed work without checking repository and ticket state.

The September 29 store report’s 257 “completed” events include 125 skipped_done events and 132 done events. Its 78% completion figure must not be presented as a landed-work rate. The September 28 intake export also contains 48 test-fixture rows among 368 dispatch-class rows. Weekly scoreboard medians need filtering before they can serve as evidence; the tables above use the frozen forensic-log snapshot instead.

Follow-ups recorded on September 29 cover excluding non-dispatch rows, recording resolved model IDs, and adding weekly post-merge failure counts per 100 merges. The last measure can expose a worsening trend, but it will not by itself measure reviewer catch rate: stale scenarios, delayed failures, and undetected defects still need separate treatment. These are follow-ups, not completed validation.

The remaining architectural targets also stay open: this cost measurement does not certify every worker contract, a 100-dispatch incident-free run, or recovery without duplicate effects. The source decision’s revisit condition—less than a 20% cache-read reduction with quality held flat—cannot be used as a causal verdict on the scripts while quality and attribution remain unresolved.

9. What this deliberately does not automate away

The goal is not to turn product work into a compiler problem. The following remain judgment problems:

• Roadmap priority and product tradeoffs
• Ticket and acceptance-criteria substance
• Implementation design and code generation
• Root-cause synthesis for unknown failures
• Correctness and security review
• Copy, support responses, and scenario authoring

We improve those nodes through better evidence, isolation, role choice, and evaluation. We do not pretend their output can be made deterministic by wrapping it in JSON.

10. The architectural claim

The earlier papers describe how the drain checks claimed outcomes against observed state and how a transactional ticket store can own state while prose remains the human interface. This paper extends those design choices into the implementation workflow:

Files remain the specification. Agents remain the source of judgment. The drain remains the durable owner of motion, and deterministic scripts become the only way its live implementation session performs repeatable effects.

This is the architecture we are working toward. Tested commands give repeatable operations an explicit place to enforce their rules, while agents continue to design, implement, and review code. The remaining gaps in worker-contract enforcement show where that boundary is incomplete. September’s results add a practical lesson: moving an operation into code helps only if the surrounding instructions use it without repeating the work or making the commands fight each other. Clarifying when to repair also reduced work, but that decision changes how much review and repair a ticket receives. The measured system is cheaper. Establishing that it preserves review quality is the next test of the efficiency claim.

Revision history

2026-09-29 · New evidence, System update

Added the September 29 dispatch measurements: the initial cost regression, later reductions, and the repository-level efficiency thresholds now crossed. Distinguished script changes, model changes, and repair policy while retaining the unresolved review-quality and attribution limits.

• New evidence · Important: The September 29 snapshot now supplies enough backend and frontend dispatches for the stated comparisons, and both cross the numerical efficiency thresholds. Changes in ticket mix, models, and repair policy prevent attributing the savings to compiled commands alone; unchanged review quality has not been established. Affected claim

• System update · Important: The September 22 change removed the validation, commit, and pull-request fallback procedures found in the September 14 audit. The instructions now stop on command failure; this is not proof that every alternative execution path is prevented. Affected claim

• System update · Important: The September 26 supervisor instructions open repair cycles only for FAIL verdicts and stop after verifying an unchanged tree. This changes when repair and re-review run; it is a model-interpreted policy, and its effect on review quality remains unmeasured. Affected claim