Conversation
…r build's receipt can never skip validation (Refs #3748) aprender-37's Qwen3.5 GPU correctness cells logged "CPU reference forward skipped [source=receipt]" and measured nothing: the receipt key's "apr version" was CARGO_PKG_VERSION, so every 0.69.0 build shared one, and a receipt written by build A let build B skip F2 — a regressed GPU kernel could serve behind another build's green receipt. Version + git sha would still let a dirty tree, or another feature set, ride a clean build's receipt. Per #3748's amended done_when 1: - key = (model sha256, sha256 of the running executable, device); the version and git sha (apr sets its label at startup) are recorded beside the key for humans, never compared; schema 2, so every version-keyed receipt revalidates once; - one receipt file per (model, executable, device): builds A, B, A never overwrite each other; - both hashes cached by the file's (canonical path, size, mtime, inode) — a warm run reads nothing; a file rewritten mid-hash is never cached; any cache failure falls back to hashing; - every F2 line names its source and the executable ([source=receipt exe=…] / [source=fresh exe=…]) and how each hash was obtained (cached | hashed); F2Outcome carries exe_sha256. Mutants, each RED then restored GREEN: key on the version (exe comparison dropped) → 2 falsifiers RED; key on the model only (one file per model) → A→B→A and the per-device file RED; a stale cache after an in-place rebuild (mtime ignored) → the identity table RED. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ended key (Refs #3748) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…da and gx10 (Refs #3748) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
§13.11 rung 1 — quorum shadow verdict Shadow mode: this records a verdict and merges nothing. A refusal |
noahgift
added
the
needs-owner
This was referenced Sep 23, 2026
Contributor
Author
|
closed by operator 1-day PR rule; reopen/rebase to resume. No live owner session, red CI on the current head, not carried by main or any open integration PR. Linked issue: #3748 (open, milestone 0.70.0). Linked issues are not touched by this close. Branch is NOT deleted: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#3748: F2 receipts keyed on (model sha256, executable sha256, device)
Closes #3748.
Receipts were keyed per MODEL only. A different
aprbinary at the sameversion could skip F2 validation on another build's receipt, and every run
re-paid the 64-position CPU forward (2.4 s lambda / 10.1 s gx10) even when
nothing changed.
Fix (
f2_receipt.rs):F2ReceiptKey{model_sha256, exe_sha256, device}.decidecompares all three and names the one that differs(
ExeSha256Mismatch).receipt_pathis<model>-<exe16>-<device>.json, sobuilds A→B→A never overwrite each other. Both hashes are cached by
FileIdentity{canonical path, size, mtime_ns, inode}(
cached_sha256/exe_sha256), re-stat after hashing, and fall back tohashing on any cache failure. Schema bumps to 2. Every F2 line names its
source and the executable's sha16 (
[source=receipt exe=…]/[source=fresh exe=…]), andF2Outcome.exe_sha256carries it for cells.Shown on device, before and after (Qwen3.5-9B-Q4_K_M, fresh
APR_F2_RECEIPT_DIR,apr run --gpu,gpu-q --prio 1): before, binary X2(X + one appended byte, same version) skipped F2 on X's receipt on both
lambda and gx10. After, at
e771c8995: B (A + one byte) never skips (fresh,7.4 s lambda / 9.3 s gx10); A→B→A never overwrite; a warm run hashes nothing
(0 ms, down from 2503/10048 ms cold); warm wall time fell 14.3→11.9 s
(lambda) and 27.7→14.8 s (gx10). Full tables in
docs/audits/impl-PMAT-3748-receipt.md.Mutants (each applied, run, reverted; restored tree 22/22 green):
falsifier_a_planted_receipt_from_a_different_executable_revalidates,falsifier_the_same_version_from_another_executable_never_skipsREDbuilds_a_then_b_then_a_never_overwrite_each_other,a_second_device_is_a_second_receipt_fileREDthe_hash_cache_hits_warm_and_misses_on_any_identity_changeREDChecks:
cargo test -p aprender-serve --lib f2_receipt22 passed ·cargo test -p apr-cli --lib7300 passed ·cargo fmt --all -- --check·cargo deny check advisories·cargo test -p aprender-contracts --lib1689 passed · cuda release build on both hosts.
Not in this row: recording
sourceinside ladder/derived cells is thejudge's side (#3745 S2 / #3712 B2). The qwen3moe F2 (#3714) writes no
receipt and validates every run — unaffected.
Status: receipt-only, per the cop's batching default. Quorum lanes are
queued for when the model pool comes back (gemini/gpt-oss both out as of
this branch's push — see #3772). Not armed.