Scientific / provenance finding
#627–#635 bind scientific-recovery authority to canonical design/profile content, exact grouped recovery payloads, exact-head test evidence, ordered seed-manifest membership, and per-replication seed/execution lineage. The remaining chronology defect was still actionable: the same profile content could be constructed after observing execution results and supplied at promotion time. Content hashing alone cannot prove that the exact policy was approved before any simulation execution artifact existed.
Morris, White, & Crowther (2019, DOI 10.1002/sim.8086) treats simulation studies as empirical experiments, recommends pre-specifying the ADEMP design, and recommends retaining RNG state per repetition for reproducibility and dependence checks. TEPP therefore must not infer pre-execution approval from caller timestamps, commit time, or post-hoc matching content.
RED → causal repair
Canonical owner vehicle remains Draft #488.
- source-level compile RED
afb970141db66718021073d654e5d880cc9b7b26 added a public contract requiring owner-ledger profile-registration chronology. The predecessor API had no chronology types or eighth promotion argument. Repair followed before a hosted terminal result, so no hosted failing RED is claimed.
- causal production repair
be7257cf29bca915cedd671bc1a66aab8dfd2f82 adds ScientificRecoveryProfileRegistrationStatusV1, ScientificRecoveryExecutionLedgerEntryV1, and ScientificRecoveryProfileChronologyV1; the chronology binds exact profile SHA-256, immutable ledger/registration-entry identities, monotonic registration sequence/status, and one later unique ledger entry for each planned execution artifact.
- public exports
464eb7c2c3677e51c8ea5b4633be8d1052d50272 expose the versioned chronology contract.
- all existing scientific-recovery contracts were ordinary-forward migrated through
61ba9728..., 4635338e..., 79189d19..., 2b13d42f..., 8fcd74fa..., be67c948..., 81130c3e..., and 18b3d224....
- refusal/edge coverage
910944f3935764a6d815831b61716052eb683499 covers approved/pending/rejected registration, registration-at-or-after execution refusal, duplicate sequence/entry identity, registration-entry reuse, malformed ledger identities, wrong cardinality, profile mismatch, and execution-artifact mismatch.
- CHANGELOG
539b70415c7933f0e32a69330b618c0f61bb930e records the boundary.
- exact-head cleanup
106f0a8ee80a1450a5c65156b7ea0532ced0c696 validates chronology before invoking the underlying numerical/exact-head authority constructor and removes a redundant post-construction cardinality branch already guaranteed by typed constructors plus replication validation.
Current contract
Public promotion is now:
promote_scientific_recovery(candidate_head, protected_head, truth_replications, recovered_replications, profile, exact_head_receipt, replication_receipts, profile_chronology)
The chronology constructor requires execution-entry cardinality to equal planned_replications; every execution sequence is unique and strictly greater than the registration sequence; execution ledger-entry identities are unique and cannot reuse the registration-entry identity. Promotion additionally requires the chronology profile identity to equal the exact promoted profile, requires Approved, and aligns every chronology execution-artifact identity with the corresponding ScientificRecoveryReplicationReceiptV1.
Successful ScientificRecoveryPromotionV1 retains a domain-separated profile_chronology_sha256 beside profile, exact-head receipt, grouped recovery-payload, and replication-provenance identities.
This is owner-ledger chronology evidence, not signature verification. Ledger entry digests and monotonic positions remain trusted-adapter inputs. It does not claim trusted timestamping, GitHub artifact attestation, Sigstore verification, SLSA provenance, or proof that the named execution artifact was cryptographically produced from the declared RNG state.
Current exact-head gate
#488 exact head is 106f0a8ee80a1450a5c65156b7ea0532ced0c696, Draft/open/mergeable on protected main@a243f18da4a4ca8a8d068c39922537f1f8ed6ad0.
Fresh exact-head workflows are non-terminal:
- Documentation Quality
35515991251 queued;
- Bias SE Exact-Proof Budget
35515991279 queued;
- SAST Semgrep
35515991379 queued;
- CodeQL PR
35515991287 queued;
- Security Scan
35515991362 queued;
- Rust Foundation CI
35515991397 queued.
No predecessor-head receipt transfers. Keep Draft; do not blind-rerun, wake-commit, merge, or weaken gates while this generation is live. Qualifying independent current-head APPROVED review is still required.
Remaining boundary
The next evidence-hardening gap is authenticity, not another content hash: signed/verifiable exact-head and execution attestations must authenticate the trusted-adapter ledger/artifact claims. #492/released orchestrator/free, protected-main integration, code-current #435 TRACEABILITY/product-gap authority, and immutable release/recovery evidence remain normal prerequisites.
Refs #488 #627 #634 #635 #492.
Scientific / provenance finding
#627–#635 bind scientific-recovery authority to canonical design/profile content, exact grouped recovery payloads, exact-head test evidence, ordered seed-manifest membership, and per-replication seed/execution lineage. The remaining chronology defect was still actionable: the same profile content could be constructed after observing execution results and supplied at promotion time. Content hashing alone cannot prove that the exact policy was approved before any simulation execution artifact existed.
Morris, White, & Crowther (2019, DOI
10.1002/sim.8086) treats simulation studies as empirical experiments, recommends pre-specifying the ADEMP design, and recommends retaining RNG state per repetition for reproducibility and dependence checks. TEPP therefore must not infer pre-execution approval from caller timestamps, commit time, or post-hoc matching content.RED → causal repair
Canonical owner vehicle remains Draft #488.
afb970141db66718021073d654e5d880cc9b7b26added a public contract requiring owner-ledger profile-registration chronology. The predecessor API had no chronology types or eighth promotion argument. Repair followed before a hosted terminal result, so no hosted failing RED is claimed.be7257cf29bca915cedd671bc1a66aab8dfd2f82addsScientificRecoveryProfileRegistrationStatusV1,ScientificRecoveryExecutionLedgerEntryV1, andScientificRecoveryProfileChronologyV1; the chronology binds exact profile SHA-256, immutable ledger/registration-entry identities, monotonic registration sequence/status, and one later unique ledger entry for each planned execution artifact.464eb7c2c3677e51c8ea5b4633be8d1052d50272expose the versioned chronology contract.61ba9728...,4635338e...,79189d19...,2b13d42f...,8fcd74fa...,be67c948...,81130c3e..., and18b3d224....910944f3935764a6d815831b61716052eb683499covers approved/pending/rejected registration, registration-at-or-after execution refusal, duplicate sequence/entry identity, registration-entry reuse, malformed ledger identities, wrong cardinality, profile mismatch, and execution-artifact mismatch.539b70415c7933f0e32a69330b618c0f61bb930erecords the boundary.106f0a8ee80a1450a5c65156b7ea0532ced0c696validates chronology before invoking the underlying numerical/exact-head authority constructor and removes a redundant post-construction cardinality branch already guaranteed by typed constructors plus replication validation.Current contract
Public promotion is now:
promote_scientific_recovery(candidate_head, protected_head, truth_replications, recovered_replications, profile, exact_head_receipt, replication_receipts, profile_chronology)The chronology constructor requires execution-entry cardinality to equal
planned_replications; every execution sequence is unique and strictly greater than the registration sequence; execution ledger-entry identities are unique and cannot reuse the registration-entry identity. Promotion additionally requires the chronology profile identity to equal the exact promoted profile, requiresApproved, and aligns every chronology execution-artifact identity with the correspondingScientificRecoveryReplicationReceiptV1.Successful
ScientificRecoveryPromotionV1retains a domain-separatedprofile_chronology_sha256beside profile, exact-head receipt, grouped recovery-payload, and replication-provenance identities.This is owner-ledger chronology evidence, not signature verification. Ledger entry digests and monotonic positions remain trusted-adapter inputs. It does not claim trusted timestamping, GitHub artifact attestation, Sigstore verification, SLSA provenance, or proof that the named execution artifact was cryptographically produced from the declared RNG state.
Current exact-head gate
#488 exact head is
106f0a8ee80a1450a5c65156b7ea0532ced0c696, Draft/open/mergeable on protectedmain@a243f18da4a4ca8a8d068c39922537f1f8ed6ad0.Fresh exact-head workflows are non-terminal:
35515991251queued;35515991279queued;35515991379queued;35515991287queued;35515991362queued;35515991397queued.No predecessor-head receipt transfers. Keep Draft; do not blind-rerun, wake-commit, merge, or weaken gates while this generation is live. Qualifying independent current-head
APPROVEDreview is still required.Remaining boundary
The next evidence-hardening gap is authenticity, not another content hash: signed/verifiable exact-head and execution attestations must authenticate the trusted-adapter ledger/artifact claims. #492/released
orchestrator/free, protected-main integration, code-current #435 TRACEABILITY/product-gap authority, and immutable release/recovery evidence remain normal prerequisites.Refs #488 #627 #634 #635 #492.