Durable Agent Work-Landing Replay

Landing language must follow recorded evidence

An agent's "I committed the fix" is a claim, and this component reads recorded landing examples and decides whether each one's evidence supports the words used to describe it. An agent that says "I committed the fix" is making a claim, and the claim is the part that is usually wrong. This component reads recorded examples of an agent finishing a piece of work and decides whether the evidence in each example supports the words used to describe it.

Four inputs produce four metadata-only records

It reads a fixture of landing attempts, a policy, a protocol, and broken cases, plus copied internal control bodies in bundle mode, and emits a metadata-only board, result, validation, and negative-coverage record. It takes a fixture of recorded landing attempts, a landing policy, a projection protocol, and a set of deliberately broken cases. In bundle mode it also reads the copied bodies of the internal control source files the model was tested against. It emits a metadata-only result set: a board, a result record, a validation record, and a fourth record confirming every expected negative case was caught.

Recorded claims only, with no live mutation

It runs no Git, stages nothing, moves no ledger, and excludes launch: it reads recorded claims and rejects the ones the evidence does not back. It does not run Git, stage a file, move a ledger, or authorize a launch. It reads recorded claims and rejects the ones the evidence does not back.

Purpose

Does the evidence support the landing language

The narrow question is whether a recorded landing's evidence supports its language, since a loose check passes any row that merely describes itself well: a confident row with nothing behind it. The question is narrow. Given a recorded landing attempt, does the recorded evidence support the landing language? A loose check passes any row that describes itself well, which is exactly the failure mode: a confident row with nothing behind it.

HEAD movement and validation order are separate floors

A landed-commit claim needs recorded HEAD movement, a commit-path claim needs validation before the attempt, and every row still needs blocker and ledger evidence. The component turns two ordinary rules into rejections. A row that uses landed-commit language is rejected unless the recorded Git HEAD moved between before and after, so "I landed it" cannot stand on a HEAD that never advanced. A row on a commit path is rejected unless validation is recorded as preceding the commit attempt, so "it passed" cannot be back-filled after the fact. Blocker capture for metadata-blocked rows and work log completion for every row are the other two floors.

Copied internal control bodies ground the check

Six digest-provenanced internal control files let readers inspect the mechanics behind the landing rules instead of trusting a paraphrase of them. The check is also source-backed. The mechanics it tests rows against are not paraphrased. The six internal control source files are copied into the bundle with digest provenance, so a reader can see which code the model was checked against instead of trusting a summary.

How it works

Two entrypoints compose the same checks

Fixture and bundle entrypoints both call _build_result, differing only in negative-case inclusion, manifest requirements, and fresh-record reuse. Two entry points drive the same builder. run reads the first-wave fixture with include_negative=True and writes four durable records. run_work_landing_bundle reads an exported bundle with include_negative=False, adds the source-module manifest check, and can reuse a fresh prior record when the input digest is unchanged. Both call _build_result, which composes four independent checks and one secret scan into a single verdict.

Row validation checks evidence and forbidden authority

_validate_run_row requires validation, claimed-path, and completion refs while rejecting stationary HEADs, late validation, uncaptured blockers, private leaks, and authority overclaims. _validate_run_row carries the row-level mechanism. For each recorded run it requires validation refs, claimed path refs, and a work log completion ref. It rejects a commit_claimed_landed row whose head_before equals head_after. It rejects a commit-path row (landing_status in COMMIT_ATTEMPT_STATUSES) that does not record validation_precedes_commit_attempt. It rejects a metadata-blocked row with no blocker capture ref, any row that claims live Git mutation, staged unrelated dirty paths, or launch-scope decision, and any row whose keys or strings leak a private body or non-public paths.

Six copied modules must match digest and anchors

validate_source_module_imports accepts the six exact-copy internal control modules only when their class, count, sha256, paths, and required anchors all match the manifest. validate_source_module_imports keeps the source claim honest. The manifest must declare copied_non_secret_macro_body, keep body_in_receipt false, and match its own module count. Each of the six rows names a internal control file under system/lib/, tools/meta/control/, or tools/meta/factory/, states an exact_copy relation, and carries a sha256. The check recomputes the digest of the copied target and rejects a mismatch, then rejects the row if any required anchor string is absent from the copied body. The copied files are workitem_runtime_entrypoint.py, work_landing_status.py, work_landing.py, mission_transaction_preflight.py, scoped_commit.py, and work_ledger.py.

The final verdict requires every independent check

_build_result passes only with all checks green, no missing negative case, and no secret hit, then projects four evidence counts into the board. _build_result merges the four checks. The final status is a pass only when no expected negative case is missing, the secret scan has zero blocking hits, and every check passed. _board_from_result then projects four mechanic counts: claimed rows, landed-commit rows, validation-before-commit passes, and metadata-blocked rows. On the first-wave fixture that is three claimed rows, one landed-commit row, two commit-path rows that must record validation order, and one metadata-blocked row, with all nine negative cases observed. Every record carries the AUTHORITY_CEILING constant, and each finding and copied-module row sets body_in_receipt: false.

flowchart TD Fixture["Fixture inputs projection, policy, runs, nine broken cases"] Source["Copied internal control bodies six files by digest"] Build["_build_result"] Runs["validate_work_landing_runs claim, validation order, HEAD advance, blocker capture"] Imports["validate_source_module_imports class, relation, digest, anchors"] Records["metadata-only records board, result, validation, coverage confirmation"] Fixture --> Build Source --> Imports Build --> Runs Build --> Imports Runs --> Records Imports --> Records

Negative cases

Nine broken rows define the refusal floor

A passing fixture must catch all nine missing-evidence, ordering, mutation, boundary, blocker, launch, and private-path failures through the same row validator. The fixture ships nine broken rows, one per key in EXPECTED_NEGATIVE_CASES. A pass requires all nine to be caught. They are: a row with no validation ref, a row whose completion is missing, a landed-commit claim with no HEAD advance, validation recorded after a commit attempt, a row claiming live Git mutation authority, a row with no dirty-tree boundary, an uncaptured metadata blocker, a launch overclaim, and a non-public paths leak. Catching those refusals is part of the positive claim, not a separate concern.

Prior Art Grounding

Provenance fields stay distinct through landing

W3C PROV and SLSA motivate keeping paths, validation, commit attempts, HEAD movement, blocker capture, and ledger completion as separately checked evidence. The posture comes from provenance and software supply-chain integrity work. The W3C PROV family models the entities, activities, and agents behind an artifact. SLSA tracks source, build process, provenance, and artifact integrity so a consumer can reason about where an artifact came from. This component borrows that separation for agent work landing: claimed paths, validation refs, commit attempts, HEAD before and after, blocker capture, and ledger completion are distinct evidence fields, checked one at a time.

Validation Result record Path

Two read-only commands verify behavior and parity

./repo-pytest tests/test_durable_agent_work_landing_replay.py -q --basetemp=/tmp/microcosm_durable_agent_work_landing_replay_pytest
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

A pass joins negative coverage and source integrity

The test pass requires every negative case, a clean secret scan, and matching copied-source digests; the corpus pass establishes projection sign-off only. The first runs the component over the fixture and its nine broken cases. A pass means every negative case was caught, the secret scan was clean, and the copied source digests matched.