---
kind: project
name: control-loop / reconciler
proves: A loop can close on a small repository repair task with a held-out corpus, satisfying all four conditions of the closure test.
summary: Reference instantiation of the two-plane loop on a single repository. Repository repair per blueprint §6, blast radius L1 (Gated).
maturity: exploratory
status: working-proof
areas:
  - evaluation
  - repository-repair
  - control-loop
owner: tim
started: 2026-07-15
updated: 2026-08-01
current_question: What additional evidence would justify moving this bounded proof beyond L1 gated operation?
next: Define the separate review and deployment path required before any unattended rollout.
featured: false
on_bench: true
artifacts: []
claims:
  - claim: The bounded repository-repair loop satisfies the four closure-test conditions at L1.
    evidence: Existing project record describes a 40-case held-out corpus, recorded verdicts, and the documented human-sampling exception; this was not independently verified in this turn.
    limitation: This does not prove unattended or self-modifying operation.
open_questions:
  - What evidence is sufficient for an L2 deployment decision?
  - How should the proof be maintained as the corpus and subject repository change?
build_log:
  - date: 2026-08-01
    change: Project record reports all four closure-test conditions at L1 gated operation.
    evidence: Existing project record reports a 40-case corpus and recorded verdict path; this was not independently verified in this turn.
domains:
  - autonomic-swe
  - agent-systems
  - runtime-infra
runtimes:
  - python
  - claude-code
verifiedAgainst:
  - model: claude-sonnet
    version: "4.6"
    date: 2026-07-28
period:
  start: 2026-07-15
  end: 2026-08-01
maintainer: tim
---

A reference instantiation of the [two-plane loop](/reference/two-plane-loop) on a
single repository, demonstrating the Repository Repair pattern from the
blueprint. The reconciler is the smallest system that satisfies all four
conditions of the [closure test](/reference/closure-test).

## What it does

The reconciler takes a small repository and a held-out corpus of historical
issues that were each closed by a passing test. For each issue:

1. The **Applier** creates a scratch branch from the pre-fix state.
2. The **Proposer** (a no-op stub in v0; will be replaced in v1) reads the
   issue text and emits a patch.
3. The **Scorer** runs the historical tests against the patch and produces a
   Verdict (`PASS`, `HARDEN`, `STALL`, `PIVOT`, or `KILL`).
4. The **Ledger** appends the run.
5. On `PASS`, the patch is offered as a change request for human review
   (blast radius L1 — Gated). The human samples; they do not review every
   one.

## What it proves

- Condition 1 (closed loop) is satisfied. The Scorer observes the consequence
  of the patch; the Ledger records both.
- Condition 2 (declarative target) is satisfied. The patch is the intent;
  `git diff` shows it.
- Condition 3 (unattended) is satisfied at L1 with the named exception
  "the human samples". Not unattended in the strict sense; the human is
  named.
- Condition 4 (ground truth) is satisfied. The Verdict plane is the Scorer,
  not the Proposer. The corpus is monotone: 40 historical issues, no
  removals. KILL outranks aggregate — the reconciler does not promote a
  patch that breaks a previously-passing case, even if the aggregate
  improves.

## What it does not prove

- L2 (Unattended). The reconciler still requires a human in the loop; this
  is by design for the reference instantiation.
- L3 (Self-modifying). The Verdict plane and the Subject (the repository)
  are distinct; the reconciler does not modify itself.
- A real Proposer. The current Proposer is a stub (intentional, per
  blueprint §9 — Proposer is built last).

## Status

The reconciler reached "all four conditions satisfied at L1" on 2026-08-01
with a 40-case corpus. The blast radius is L1 (Gated); L2 deployment
requires a separate path and a separate reviewer, per the blueprint.

## Provenance note

The source narrative above is retained as the legacy project record. Its
verification metadata describes what that record reports; it is not a claim
that the underlying executable proof was rerun in this turn.