science(talent): canonicalize replacement manifest lineage and as-of denominator views

[seonghobae]

Finding

Fresh review of Talent owner PR #293 at exact aa857c9d1ab7ecc751a7ac382795a69deb8e4994 and canonical baseline PR #100 at exact a5b02e6145619cf59a343625331cc45be6f55906 found a distinct denominator-versioning gap after #398.

#398 correctly defines how one closed manifest resolves each semantic opportunity occurrence identity to exactly one canonical active terminal entry. ADR 0292 also states that a closed DecisionOpportunitySet / StageCohortManifest is immutable and a later correction appends a linked replacement/reconsideration version.

What remains undefined is which manifest version is authoritative when multiple closed replacement versions exist for the same material stage/cohort lineage. Occurrence-level canonicalization inside each manifest does not answer manifest-level selection across versions.

Without an explicit manifest-lineage/as-of contract, a consumer can:

• union original manifest M1 and corrected replacement M2 and double-count the same semantic opportunities;
• silently use only the newest M2 and rewrite the historical denominator that was actually available/used when the original Talent decision was made;
• pick M1 and ignore a later valid correction when a current corrected view is intended;
• resolve two competing replacement branches differently across services;
• produce a Workforce Validation result whose denominator cannot be reproduced because the selected manifest version/digest and temporal view were not recorded.

This is separate from #398. #398 is canonical row selection within a manifest. This issue is canonical manifest/version selection across immutable replacement manifests.

Owner boundary

talent_management owns the immutable manifest lineage/version/provenance required to reconstruct the Talent process. workforce_validation continues to own analytic estimand/grouping choice, protected-group joins, validity/fairness/scientific methods and interpretation.

No protected attributes move into Talent. No cross-service SQL is introduced. Scientific consumers receive released/versioned manifest evidence through owner contracts/ACLs.

Required contract refinement while ADR 0292 remains Proposed

For each material-stage opportunity-set lineage, define an immutable/versioned contract equivalent to:

• stable opaque manifest_lineage_id for replacement/reconsideration versions representing the same material-stage opportunity-set lineage;
• immutable manifest_version plus exact content digest/reference for every closed version;
• an explicit supersedes_manifest_version / correction predecessor link for replacement versions;
• deterministic acyclic lineage resolution with no dangling predecessor and no ambiguous competing active successors unless a controlled conflict-resolution version explicitly supersedes them;
• replacement versions preserve semantic opportunity occurrence identities for corrected occurrences; genuinely added/removed opportunities require explicit controlled delta provenance/reason rather than silent set drift;
• superseded manifest versions remain immutable historical evidence but are not blindly co-counted with their replacement in a single denominator view;
• consumers must choose an explicit temporal/correction view, not an implicit unqualified latest.

At minimum support semantically distinct reproducible views such as:

1. as-recorded: the exact manifest version/digest that governed the decision or stage at a specified system/effective-time/cutoff;
2. corrected-as-of: the deterministic canonical replacement version in the lineage as of an explicit correction/system-time cutoff.

Names may change during UL review, but the distinction cannot be implicit.

Every released scientific/buyer analysis consuming Talent denominators must bind the exact manifest_lineage_id, selected immutable manifest version/digest, requested view semantics and as-of/cutoff. A later replacement cannot retroactively alter the evidence identity of an already published analysis; a recomputation uses a new analysis/evidence version.

Cross-version reconciliation

For a selected manifest version, the existing #398 occurrence-level closure invariant remains:

entry_count == unique semantic opportunity occurrence count == canonical active terminal count == sum(canonical terminal classes)

Across manifest replacements, additionally require deterministic lineage integrity. A replacement is not a new business cohort merely because evidence or a terminal classification was corrected. Conversely, a genuinely new stage/cohort/business opportunity must not be hidden as a replacement version in the old lineage.

The implementation contract should make additions/removals/changed terminal outcomes between M1 and M2 auditable by semantic occurrence identity and controlled reason/provenance.

RED acceptance cases

Before ADR acceptance or production implementation, fail at least when:

• a consumer blindly unions M1 and replacement M2 into one denominator;
• a historical/as-recorded query silently returns the newest corrected manifest;
• a current corrected-as-of query silently returns a superseded predecessor;
• an API/analysis accepts an unqualified latest without explicit view/as-of semantics;
• two replacement manifests are simultaneously canonical for the same lineage/view/cutoff;
• the supersession graph is cyclic, dangling or ambiguous;
• a correction mints a new manifest_lineage_id without a genuinely new stage/cohort;
• a genuinely new cohort/stage is smuggled into an old correction lineage;
• corrected occurrences change semantic occurrence identity without a genuinely new opportunity;
• opportunity entries are added or removed across replacement versions without controlled delta provenance;
• a workforce_validation result cannot identify the exact Talent manifest lineage/version/digest/view/as-of that supplied its denominator;
• downstream code must query Talent tables directly to resolve the replacement lineage;
• a later correction mutates the evidence identity of an already released scientific result instead of producing a new result/version.

Completion boundary

Documentation reconciliation alone is not completion. Keep this issue open through executable domain/schema/API contracts, RED→GREEN tests, released owner evidence exchange and normal protected integration. Do not close it merely because #398 canonicalizes rows inside one manifest or because a dashboard can show a corrected denominator.

[seonghobae]

Follow-on boundary found while reviewing #399 against current ADR 0292: #400 separates manifest correction lineage from selection-policy regime. #399 remains valid and open; it should not absorb or close #400.

A replacement manifest can be canonical under #399 only after the owner contract determines that its governing selection semantics are compatible with that correction lineage. Material changes to threshold/cut score, ranking/order, eligibility meaning, required-evidence meaning, suppression/routing, or other rules that change who can enter/advance/be excluded must not be silently traversed by corrected_as_of as if they were data corrections. Re-analysis under a new policy regime is new evidence, not a retroactive rewrite of the historical result.