finish is a request. The ledger decides.

01 · StateThe goal ledger

A GoalLedger is created once per run and outlives every step. It holds the run id, the goal text, the active profile, a status, a seeded plan, the acceptance checks, decisions, open questions, and an evidence log. It derives Serialize and Deserialize, and the whole thing is written to the goal_ledger table in SQLite as JSON columns.

pub struct GoalLedger {
    pub run_id: Uuid,
    pub goal: String,
    pub profile: String,
    pub status: GoalStatus,           // Running | Blocked | Complete
    pub plan: Vec<PlanItem>,
    pub acceptance: Vec<AcceptanceCheck>,
    pub decisions: Vec<String>,
    pub open_questions: Vec<String>,
    pub evidence: Vec<EvidenceItem>,
}

An AcceptanceCheck has seven fields, and the two boolean ones do different jobs. passed means evidence arrived and satisfied it. impossible means the check was argued away — either individually via mark_acceptance_impossible, or wholesale when the model calls mark_impossible. Both remove a check from the “missing” set, but only one of them is a success.

Note how evidence propagates. RuntimeKernel::record_verification pushes a VerificationFinished event, appends an EvidenceItem to the ledger, and — only if the verification passed — walks the acceptance list marking every check whose strategy matches. One passing cargo test run closes every RustTests check at once, which matters because plan_for_strategy can retarget several checks onto the same underlying command.

02 · DerivationFrom goal string to executed command

infer_acceptance is a keyword scan, and it is honest about being one. It lowercases the goal and applies five independent rules; every rule that matches adds a required check. If none match, a single generic-evidence check is created so that no run is ever ungated.

The matching is not naïve substring matching throughout. contains_word splits on anything that is not alphanumeric or underscore and compares whole tokens, so “code” matches code but not decoder. Where substring matching is used it is for multi-word phrases — "web app", "look up" — where token splitting would not help.

03 · PlansSix strategies, and the fallbacks that keep them satisfiable

Each strategy resolves to a VerificationPlan — a strategy tag, an optional command, and an evidence label. The evidence label is what ends up in the passing message, which is why an eval scenario can score by looking for the substring rust-checks or node-fixture-test.

fn rust_verification_command() -> String {
    [
        "CARGO_TARGET_DIR=target/localnpc-verify cargo fmt --check",
        "CARGO_TARGET_DIR=target/localnpc-verify cargo clippy --all-targets -- -D warnings",
        "CARGO_TARGET_DIR=target/localnpc-verify cargo test",
    ]
    .join(" && ")
}

The redirected CARGO_TARGET_DIR is a small but telling choice. Verification builds into target/localnpc-verify rather than target/, so the harness never invalidates the developer’s own incremental build state while checking the model’s work. The gate is fmt, then clippy with warnings denied, then test — chained with &&, so a formatting failure short-circuits before the expensive steps.

Fallbacks that prevent unwinnable runs

Two strategies deliberately degrade rather than fail. RustTests in a non-Rust repository falls back to plan_for_project and adopts the requested strategy id, so the resulting evidence still satisfies the check that asked for it. FileArtifact with no index.html does the same. The comment on the second case is precise about the failure it prevents:

The Playwright command is defensive in a way that reads like it was written after a bad afternoon: it prefers a pinned Python, falls back to python3 if that is not executable, checks that playwright actually imports before trying to use it, and wraps the whole invocation so that a failed headless launch degrades to artifact-existence rather than a hard error — while printing to stderr exactly which fallback it took.

04 · The gateWhat happens when the model says it’s done

finish_decision is four lines of filter. It is not a state machine, not a flag, and not something the model can write to.

pub fn finish_decision(&self) -> FinishDecision {
    let missing = self.ledger.acceptance
        .iter()
        .filter(|check| check.required && !check.passed && !check.impossible)
        .map(|check| check.id.clone())
        .collect::<Vec<_>>();
    if missing.is_empty() {
        FinishDecision::Complete
    } else {
        FinishDecision::MissingEvidence(missing)
    }
}

The finish action does not shortcut it. The arm in loop_runner.rs:701 runs verify_missing first — the same authoritative verification the verify action triggers — and only then calls finish_with_summary. That function records the model’s summary as a model-kind evidence item and calls finish_if_ready. Recording the summary explicitly does not mark any check passed; the doc comment says so directly.

The same authoritative-verification-first pattern shows up in the verify arm and in the repeated-capability_search escalation. All three converge on verify_missing then finish_if_ready, and only finish_if_ready sets GoalStatus::Complete and emits RunFinished { status: "complete" }. There is exactly one place in the codebase where a run becomes successful.

Manual evidence is checked against what was observed

A model can supply evidence directly through verify or goal_update. That evidence is not taken at face value for research tasks: apply_manual_verify_evidence runs alongside observed_source_urls — the URLs actually returned by web.search during this run — and evidence_cites_observed_source checks that a cited URL was one the harness really saw. A fabricated citation does not close a ResearchSources check.

05 · The other exitDeclaring a task not completable

A gate with no escape hatch produces a different pathology: a model that cannot satisfy a check thrashes until the step cap. mark_impossible is the sanctioned exit, and it is careful about what it claims.

It marks every still-open required check impossible with the model’s reasoning as evidence, appends an ImpossibleAcceptance evidence item, sets GoalStatus::Blocked, and emits RunFinished { status: "not_completable" }. It reuses the per-check mark_impossible path rather than inventing a new event kind — the comment notes this explicitly.

The distinction survives replay. Because impossible and passed are separate fields, a completed run whose ledger contains impossible checks is visibly different from one where everything was verified — you cannot read status: Complete alone and conclude the work was proven.

Five files carry this whole mechanism: src/goal/acceptance.rs derives the checks, src/goal/ledger.rs stores them, src/tools/verify.rs resolves and runs the commands, src/runtime/kernel.rs records results and computes the decision, and src/runtime/loop_runner.rs wires it into the step loop. None of them is long. The strength is in where the boundary sits, not in how much code is behind it.