Round-8 review (GPT-5.6, register key `slh-provenance-contradictory`, HIGH),
raised in round 7 and unfixed since.
The machine-enforced subject is unambiguous and appears in PROVENANCE.json and
extract.sh:
fips205-source @ a3ce8e8644fe302019ed7ae271912333f1476de4
It appeared in ZERO markdown files. The prose instead named three other
revisions across four documents — README `797b4ef`, TRUSTED-BASE `3153988`,
ATTESTATION-BASIS `c945821` — so a reader could not tell which Rust the proofs
are about. Subject identity is part of the attestation object: a proof about a
model is not evidence for an unspecified source revision.
README.md current snapshot head -> a3ce8e8, with the lineage
bea1051 -> 797b4ef -> a3ce8e8 stated explicitly and
matching PROVENANCE.json's own upstream_deviation text
TRUSTED-BASE.md current snapshot head -> a3ce8e8
ATTESTATION-BASIS.md subject -> a3ce8e8, AND the "four model_integrity_sha256
hashes" claim corrected: only TWO (Types.lean,
Funs.lean) are regenerated by extract.sh; the two
*External.lean files are hand-maintained and separately
byte-pinned. Stating four invites a reproducer to expect
extraction to produce files it never touches.
RECORDED-RUN.md IS DELIBERATELY NOT REWRITTEN. It records a run that really
happened on 2026-07-24 against `797b4ef`. Editing the identity of a past run to
match today's pin would falsify the record rather than correct it. It now
carries a header saying so and naming the current pin.
Independent extraction remains UNVERIFIED — no third party has regenerated the
Lean from the Rust. That is unchanged by this commit and is stated where a
reader will meet it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Third reviewer returned ATTEST-with-conditions at 1bc4f39. Its conditions are
committed verbatim as ATTESTATION-BASIS.md so the limits travel with the
artifact instead of living in a review document a consumer never sees. Condition
9 — that extract.sh's byte-identical regeneration has never been observed by any
party but the author — is the campaign's last open item, and the file records
that both reviewers are now blocked on it for different environmental reasons.
HARNESS PINS ARE NOW SELF-DERIVING. My round-7 fix hardcoded the required pin
names, which the reviewer correctly called a second thing to keep in sync, and
it supplied the boundary the harness does have: the executable bit. check.sh now
requires every executable file in verification/ to be pinned (itself excluded —
it cannot pin itself), plus Proofs/Audit.lean. A new harness script therefore
fails closed until pinned. Consequence, and the reviewer argued for it:
check-selftest.sh, drill.sh and extract.sh are now pinned too — the self-test is
the only artifact demonstrating the gates work, and its assertions have been
defective in four consecutive rounds, so weakening it should be a reviewable
rotation rather than an unnoticed edit.
THE EXTRACTION SCRIPT'S GUARANTEES ARE NOW STATED HONESTLY. The reviewer found a
tautological assert in it — comparing a dict against the comprehension that had
just built it — in the script written to fix a provenance-honesty defect. My
first repair (comparing kept[k] against t[k]) was tautological for the same
reason, which I confirmed by negative test. No check inside a transformer can
detect a corrupted input, because the transformer defines the output from that
input; that lesson is now recorded in the code. Both fake checks are gone and
the header and provenance text name what actually protects the result — the
pinned SOURCE_SHA256, the sk-must-be-present check, the group and test counts,
and verify mode — each of which I negative-tested.
Also: the self-test keeps its backups outside verification/ (cp -p preserves the
executable bit, so an in-tree backup would have looked like an unpinned harness
file and failed a run for an unrelated reason); the Phase-0 banner no longer
says a file 'differs' when an entry is simply absent; and attack 18's assertion
follows the renamed diagnostic and now requires both missing pins to be named.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
