scientific(coverage): bind shard provenance before calibration evidence assembly

[seonghobae]

Finding

#733 now provides an owner-issued per-replication executor, bounded shard execution, and final schema-v4 evidence assembly. The remaining execution/recovery gap is between those two boundaries: execute_coverage_calibration_shard(...) returns only a bare Vec<CoverageCalibrationReplicationOutcome>, while assemble_coverage_calibration_evidence_v1(...) accepts a bare outcome slice plus a caller-supplied source_head.

That means a long-running/resumed 10,000-DGP study can persist or concatenate shard results without carrying the source/scenario provenance that produced each shard. A caller can therefore mix otherwise valid ordinal outcomes produced by different source heads (or an earlier scenario implementation), then pass one current source_head at final assembly. Exact ordinal/permutation validation and the outcome digest still pass because neither can prove that all outcomes came from the claimed execution provenance.

This is not merely external storage authentication. The application owner itself currently discards execution provenance before the resume/persistence boundary, so the final record can state a source/scenario identity that was never bound to each constituent shard.

Required RED / repair

• introduce a typed shard result owned by analysis_engine that carries a versioned shard schema, half-open ordinal range, simulation scenario ID/fingerprint, exact lowercase source head, and the indexed outcomes produced for that range;
• make the shard constructor/executor derive scenario identity/fingerprint from CoverageCalibrationSimulationDesign rather than accepting caller strings;
• validate source-head shape before execution/persistence and require the returned outcome identities to match the declared half-open range exactly;
• provide deterministic JSON serialization and an immutable digest for the shard record so resumed/distributed execution can compare persisted shard identity without relying on filenames or completion order;
• change final v1 evidence assembly to consume shard records, reject mixed source heads/scenario identities/fingerprints, reject overlapping/gapped/out-of-range shard ranges, and only then flatten the exact indexed outcomes into the existing validation_core evidence owner;
• keep validation_core as the owner of full 0..N permutation, denominator, coverage, MCSE, percentile, and final evidence arithmetic; do not duplicate those calculations in analysis_engine;
• do not claim that a digest authenticates external storage or the build environment. It is an immutable application-level provenance binding only.

Acceptance boundary

This repair makes the declared 10,000-DGP study shard/resume path scientifically reconstructable. It does not execute the study, define a post-hoc numerical-failure threshold, replace artifact signing/attestation, satisfy hosted gates, promote #680, or create a release.

Refs #639 #680 #725 #726 #728 #731 #732 #733.

[seonghobae]

Ordinary-forward source repair is now on #639 at exact head 04cbb3d46633ed5adfc922351ccf98f2c5203508.

Lineage: ed7956db27e1175f5ceec5781f9183d79f9e8546 source RED → 6b23c63a241302a6db351eae6d0b662aeb06208b provenance-bound shard record/final assembly → 30d78da839a16a11c4a3bcb9b38698776bfc4e89 public export → e63c347a43b567c0c013102fb048c944e36db328 existing study-contract currentization → 04cbb3d46633ed5adfc922351ccf98f2c5203508 CHANGELOG.

CoverageCalibrationShardRecord binds schema/range/scenario ID+fingerprint/source head/indexed outcomes before persistence; its digest covers exact outcome identities and binary64 coverage bits. Final v1 assembly now accepts shard records rather than caller-supplied bare outcomes + one late source string, rejects mixed source/scenario, gaps/overlap/range drift, then delegates the full ledger to validation_core.

The RED commit advanced before hosted execution, so this is source-level RED→repair only. Exact-head hosted gates are still queued/pending and the declared 10,000-DGP run has not been executed. Keep #734 open until the delta lands normally or a verified successor inherits it; do not treat the shard digest as external-storage/build authentication.

[seonghobae]

Successor recovery finding #735 is now ordinary-forward on #639 at exact head 59e9e523a93471e7a24f9f35330acaef1dd163fa.

#734's shard record could persist JSON + digest but had no owner-issued path to rehydrate persisted JSON into the typed record. #735 adds validated CoverageCalibrationShardRecord::from_json(...) with private wire structs, canonical schema/source/fingerprint/range/outcome-identity checks, and digest-preserving round-trip coverage. #734's source/scenario/range binding remains unchanged; this repairs the persistence/resume consumption boundary rather than superseding its scientific provenance semantics.

Do not close #734 yet: neither protected-main inheritance nor qualifying exact-head hosted evidence exists.