Verification and recovery

FlowCopy Anchor Link

Verification and repair

When a check fails, what exactly can happen next, and what can never happen?

○Illustrative · simulated

ScenarioPassFails once, then fixedNever fixedReviewer rejectsCanary regresses

max_repair_attempts012 (default)3

BackStepReset

1. 1● current

   Author

   author-agent

2. 2pending

   Deterministic checks

   tests, lint, typecheck

3. 3pending

   Independent review

   reviewer-agent

4. 4pending

   Rehearsal

   disposable environment

5. 5pending

   Canary

   release-pipeline

6. 6pending

   Release

   release-pipeline only

Step 1 of 8state: In progress

Author implements the change

Who acts

author-agent

Evidence recorded

candidate and diff recorded by the runner

Repair attempts

attempt 0/2

What can happen next

• ↻Check fails: bounded repair, then re-check
• ‖Attempts or budget used up: pause and escalate; never widen the grant
• ◆Reviewer disagrees: escalate to a human
• ↶Canary regresses: rollback under the release identity

◆ Never, at any step

Repair cannot widen the grant, change protected paths, or approve itself. The author never reviews or deploys its own change; a human or policy accepts, not the model.

Step 1 of 8. Author implements the change. Acting identity: author-agent. Repair attempts 0 of 2.

● current stage✓ passed✕ failed or escalated◆ fixed rule

Text description

Illustrative and simulated: no change is running. The generated Playbook sets max_repair_attempts: 2; the field accepts 0 to 10 and the control here shows 0 to 3.

1. The author-agent implements. Deterministic checks (tests, lint, typecheck) run next.
2. A reviewer-agent, a separate identity from the author, reviews independently and returns findings.
3. The change is rehearsed in a disposable environment, then canaried and released by the release-pipeline, the only identity that deploys.
4. If a check fails, the change goes back to the author for a bounded repair, with the findings reference as the only new input. After max_repair_attempts it is escalated to a human.
5. If a budget is used up, the change pauses and escalates; it never gets a wider grant. If the reviewer disagrees, it escalates. If the canary regresses, it rolls back.

Invariant in every case: repair cannot widen the grant, change protected paths, or approve itself.

LayersCopy Anchor Link

Checks run in order and each layer short-circuits on failure into the repair loop: compile and type check; lint and format; existing tests; tests the agent wrote; mutation or property tests where the playbook asks; security scanning; architecture checks; compatibility checks; migration and deployment rehearsal; secondary AI review; the policy gate; and a canary after release. Verifiers are capability providers behind the verifier port with a Run RPC. They run under the reviewer identity in their own sandbox with read-only access to the candidate, and findings are stored as artifacts referenced by digest.

Independent reviewerCopy Anchor Link

The reviewer runs on a different model vendor with read-only tools and checks intent-to-implementation fit, test adequacy and risk. It returns findings with confidence and references, not a verdict. Its false-accept and false-reject rates are tracked per playbook. Deterministic checks come first so that correlated model error cannot be the only barrier.

Bounded repairCopy Anchor Link

On failure the change re-enters implementation with the findings reference as its only new input. The number of attempts is max_repair_attempts on the Playbook: finite, 0 to 10, defaulting to 2. After that the change is escalated. This is bounded repair, not unlimited retry.

Rehearsal, canary and rollbackCopy Anchor Link

A disposable environment applies migrations and infrastructure changes in dry-run or plan mode and then for real, recording timings and plan digests, and is destroyed at its time to live. After release, a canary window evaluates service level objectives and declared business invariants. A regression triggers rollback under the release identity and opens a corrective change.

EscalationCopy Anchor Link

Escalation hands a change to a human with the findings, the evidence so far and the state. A human signal can resume implementation or abandon. Escalation never raises the autonomy level.

Boundary tableCopy Anchor Link

Failure casesCopy Anchor Link

• Verifier unavailable (for example a sandboxed test runner that is not ready): the layer is reported unavailable, not passed.
• Repair attempts exhausted: escalate.
• Canary regression: rollback and a corrective change.
• Seeded defects not caught in replay: the playbook is not eligible for promotion.