Repository navigation
scientific(validation): bind exact-head test evidence to immutable receipt identity #630
Description
Finding
#629 correctly stopped the specialized scientific-recovery path from minting ScientificallySupported authority without ExactHeadTests, but the repaired public API still accepts claim_evidence: &[ClaimEvidence]. ClaimEvidence::new(ExactHeadTests, true) contains only a kind and boolean; it carries neither the tested commit identity nor an immutable CI/test receipt identity.
That means the specialized recovery path can be handed a passing exact-head boolean that was actually obtained on a predecessor commit, while PromotionRequest only compares candidate_head with protected_head. The generic gate therefore cannot prove that the exact-head test evidence itself belongs to the candidate. #629 explicitly left durable exact-head evidence-receipt identity as a remaining hardening gap.
This is an authority/evidence-provenance defect, not a recovery-metric defect. RMSE/MCSE arithmetic, grouped independent replications, planned denominator, profile provenance, failure policy, and practical targets must not change.
Required RED
On canonical Validation Evidence PR #488, add a public contract requiring scientific recovery to consume an exact-head test receipt that carries:
- the tested Git commit SHA;
- an immutable canonical SHA-256 receipt/artifact identity;
- an explicit terminal state (
passed,failed,queued,skipped).
The contract must prove that:
- a passed receipt bound to the candidate head may compose with computed recovery;
- a passed receipt bound to another head fails as predecessor evidence;
- failed, queued, and skipped receipts fail closed with the existing canonical errors;
- malformed/noncanonical receipt SHA-256 fails closed;
- the returned scientific promotion retains both the recovery-profile SHA-256 and the exact-head receipt SHA-256 so downstream code cannot silently discard which receipt supported authority.
The predecessor boolean-only recovery API should be unable to satisfy this contract.
Minimal causal repair
Keep the generic ADR 0014 ClaimEvidence model intact for now. Harden the specialized scientific-recovery boundary by introducing a versioned exact-head receipt value object in the Validation Evidence owner, validate its head/digest/status, convert only a matching passed receipt into the internal ExactHeadTests=true evidence item, compute ScientificRecovery=true internally, and then call canonical promote_claim.
Do not infer CI truth from the receipt digest: receipt contents remain trusted-adapter evidence. The repair must bind identity and prevent predecessor/queued/skipped/failing evidence from being relabeled as a detached passing boolean. A later generic claim-receipt migration may reuse this contract.
Keep open through RED → causal repair → exact-head Rust/coverage/security/CodeQL/proof-budget → qualifying independent review → normal prerequisite/protected-main integration and code-current TRACEABILITY/product-gap authority.
Activity
seonghobae commentedon Sep 20, 2026
Ordinary-forward #488 lineage is now:
2322854d9905c47cd61a4495f12617cad95e7c00: requires a head-bound immutable receipt, predecessor-head refusal, terminal-state refusal, canonical SHA-256, and retention of the receipt identity. No hosted failing RED receipt is claimed because repair commits followed before a terminal workflow result.c8219a994810946a0248c72999130837bd985deb: addsScientificRecoveryExactHeadReceiptV1/ScientificRecoveryExactHeadReceiptStatusV1, checks receipt head against the candidate, maps failed/queued/skipped to the existing canonical errors, and constructs internalExactHeadTests=trueonly from a matching passed receipt.fc95390856bcf2413ed9a78d154202addbd4b679.5f8456e37f1a691fb3098a0442303acf276dbbef,2eed467b349d9e7bbce4ec306ce63f39c8ade29e,32094a7fd063fe07c5a15f544150b727c5482d84,214d11340a66660eb5787b7d92ac1efc254d9c31,3cc25189f8d346aaff4d5db97fd583fccee9b142.b8ce510ac0232df13b506668e62da2ccad35cdc9.The specialized scientific-recovery path is now bound to both the versioned recovery-profile SHA-256 and the exact-head test-receipt SHA-256. The receipt digest remains trusted-adapter provenance, not a cryptographic proof that CI itself passed; generic
ClaimEvidencestill retains its existing adapter-trust model outside this specialized path. Keep #630 open through fresh exact-head hosted gates, qualifying independent review, #492 prerequisite/protected-main integration, and single-writer TRACEABILITY/product-gap currentization.seonghobae commentedon Sep 20, 2026
Standards/provenance note for the next hardening step: SLSA v1.2 is current and treats provenance as verifiable information about where/when/how an artifact was produced; GitHub artifact attestations cryptographically bind repository/workflow/environment/commit context through Sigstore/OIDC and GitHub explicitly requires signature/timestamp/signer verification for meaningful security. The current #630 value object intentionally stops short of claiming that level: its SHA-256 is only an immutable receipt identity under a trusted adapter. A later owner-correct integration should prefer a verifiable attestation/bundle or equivalent signed receipt over extending the boolean trust model. Keep that distinction in TRACEABILITY; do not relabel the present digest as SLSA/GitHub attestation evidence.
seonghobae commentedon Sep 20, 2026
#631 ordinary-forward refines this receipt contract without closing #630. #630's head/status gate remains valid, but its initial
receipt_sha256()semantics were only the supplied artifact digest; identical artifact digests could therefore share one advertised receipt identity across different tested heads/statuses. #631 adds runtime REDd4154eb433df8944a4b10b48b711141b0337cc8b, causal binding repair06899ee91b536a44a5127a98a055c77e6ed2d972, authority migration1f36eea61108e906676b8d2172de8af16b687b64, current head0259dafae4e215355b548e7c9a7d910974d6351e. Underlying artifact digest remains separate trusted-adapter evidence; no signature/attestation claim is introduced. Keep #630 open until the shared exact-head acceptance/integration bar is actually satisfied.