scientific(validation): bind promoted recovery authority to exact evaluated payload identity

[seonghobae]

Scientific/provenance finding

The current #488 scientific-recovery path binds final authority to:

• ScientificRecoveryProfileV1::sha256() for the predeclared design/acceptance policy; and
• ScientificRecoveryExactHeadReceiptV1::receipt_sha256() for the exact tested source receipt.

It does not retain an identity for the actual grouped truth_replications / recovered_replications payload that passed the numerical gate.

Consequently two different recovery datasets can be evaluated under the same profile and exact-head receipt, both receive ScientificallySupported, and produce the same downstream audit tuple (claim, profile_sha256, exact_head_receipt_sha256). The profile's DGP/seed-manifest/estimand/state-composition digests identify the planned design, not the exact represented recovery outputs supplied to promotion.

That is a reproducibility/evidence-lineage defect. It does not imply the numerical RMSE/MCSE decision is wrong; it means downstream authority cannot prove which represented trajectories/states were actually evaluated.

Required RED

On canonical Draft #488, construct two distinct valid grouped recovery payloads that both satisfy the same profile and exact-head receipt (for example two different exact-recovery datasets with RMSE 0). Require:

• repeated promotion of the same represented payload to retain the same recovery-evidence identity;
• different represented truth/recovery payloads to retain different recovery-evidence identities even when the resulting authority/profile/test-receipt tuple is otherwise identical;
• +0.0 and -0.0 not to create distinct recovery-evidence identities when the scientific represented value is zero;
• outer replication order and within-replication coordinate order/length to remain committed because the state-composition contract gives those positions meaning.

The predecessor API cannot satisfy this because ScientificRecoveryPromotionV1 has no recovery-payload identity.

Minimal causal repair

Derive a versioned, domain-separated SHA-256 inside Validation Evidence after input validation and before authority is returned. Bind at minimum:

• schema/version;
• exact recovery-profile SHA-256;
• outer replication count;
• each replication index and inner cardinality;
• canonical represented f64 bits for every truth/recovery coordinate (canonicalize signed zero; non-finite values remain rejected by the numerical boundary).

Retain this recovery_evidence_sha256 in ScientificRecoveryPromotionV1 alongside the profile and exact-head receipt identities.

Do not call this a signature, execution attestation, seed-execution proof, or pre-execution registration proof. This closes payload content identity only. Per-replication seed/execution provenance and signed/verifiable evidence remain subsequent hardening gaps.

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.

Refs #488 #623 #625 #626 #627 #630 #631 #632.

[seonghobae]

Implementation lineage on canonical Draft #488:

• source-level compile RED 65c1e74a5a52341f5cff87f434d42594dca84095 adds the public payload-identity contract. Against the predecessor export it cannot compile because ScientificRecoveryPromotionV1 has no recovery_evidence_sha256() method. No hosted failing RED receipt is claimed because repair commits followed before a terminal run.
• causal owner repair b9ab14094f10dd70643b059d3ef90ddea6a0dd31 adds a Validation Evidence wrapper that derives tepp.scientific_recovery_evidence.v1 identity after the canonical numerical/profile/receipt/ADR-0014 gate succeeds.
• public export migration 56d3179e512bb8847e3cc99d6c882f676ee6826f makes the payload-bound promotion result/function the crate surface while leaving the numerical owner implementation internal.
• CHANGELOG 7a409f67b6bfe1fc7abd9b9009db9411033ba4d0 records the evidence boundary.
• rustfmt-shaped doctoring/current exact head 37cca531e0ea7eb8ca8e6348a2cc0120231765cf preserves the same semantics.

The digest binds profile identity, ordered outer replication index/count, each truth/recovery inner cardinality, and canonical finite binary64 values. +0.0/-0.0 are intentionally one scientific payload identity. It is content identity only; no signature, seed-execution proof, or pre-execution chronology is claimed.

Fresh exact-head workflows are live/non-terminal, so keep Draft/open and do not transfer predecessor receipts.

[seonghobae]

Exact-head follow-up: #488 advanced ordinary-forward to b9313ae24aa8ddb90d222042d7b8da6f7f178b68. This commit is not a scientific-policy change. It removes newly introduced fallible usize -> u64 conversions from the payload-hash helper because validation_core already fails compilation off 64-bit targets and the existing profile digest encodes usize directly. The fallible conversion arms were therefore structurally unreachable production coverage debt. Payload schema/content binding, signed-zero canonicalization, RMSE/MCSE acceptance, receipt semantics, and authority composition are unchanged. All 37cca531... workflow receipts are predecessor evidence and do not transfer; fresh b9313ae... exact-head workflows are live/non-terminal.