Finding
Fresh review of Talent owner PR #293 at exact 63a33f246faca7ade1bae1c3bebbf6b9771af5ff and the #399 manifest-replacement contract found a distinct scientific/lineage gap.
#399 now makes manifest-version selection reproducible inside one replacement lineage: stable lineage identity, immutable manifest version/digest, deterministic supersession, and explicit as_recorded versus corrected_as_of views. ADR 0292 also binds each stage manifest to an exact eligibility/decision-policy version and required evidence versions.
What remains undefined is when a change to eligibility criteria, thresholding/ranking semantics, decision-policy meaning, or required-evidence semantics is still a correction of the same denominator lineage versus a genuinely new selection-policy regime that must not be traversed as an ordinary corrected-as-of replacement.
Without that distinction, an implementation can change the decision rule and still label M2 as a correction of M1. A corrected_as_of consumer can then silently cross from one selection procedure into another while appearing to reconstruct the same denominator. That creates several false-authority paths:
- a threshold, ranking rule, eligibility rule, or required-evidence meaning changes but the old and new manifests remain one correction lineage;
- a later policy regime retroactively changes who is considered in-scope for an earlier stage without creating a new analysis/evidence version;
- fairness/adverse-impact or validity evidence from policy regime P1 is compared to P2 as if only data were corrected;
- a no-op/editorial policy version bump is treated the same as a material semantic policy change because version identity alone does not express semantic compatibility;
- downstream
workforce_validation cannot tell whether a denominator delta came from corrected records or a changed selection procedure.
This is separate from #398 and #399. #398 selects one canonical terminal row per semantic opportunity occurrence inside one manifest. #399 selects one canonical immutable manifest version inside one replacement lineage/view/cutoff. This issue classifies whether two manifest versions are allowed to belong to the same correction lineage at all when the governing selection semantics changed.
Evidence / scientific rationale
Use the following as design evidence, not as a claim that U.S. law universally governs every Orgmetra tenant:
The engineering consequence is narrower than any jurisdictional rule: a material change in selection semantics must not masquerade as a data correction of the same scientific denominator.
Owner boundary
talent_management owns only the versioned process/policy provenance necessary to say which Talent decision regime produced a manifest. workforce_validation continues to own construct/criterion validity, fairness/adverse-impact methods, estimand/grouping choice, study interpretation, and any conclusion about whether evidence supports a changed procedure.
No protected demographic attributes move into Talent. No cross-service SQL is introduced. A semantic-regime identifier/digest is provenance, not a validity verdict.
Required contract refinement while ADR 0292 remains Proposed
Define an explicit policy-semantics compatibility boundary for each material stage. Exact UL may change, but the contract needs an equivalent of:
- immutable
decision_policy_version plus a canonical semantic policy/evaluation digest or equivalent evidence sufficient to distinguish semantic from editorial/no-op version changes;
- explicit classification of manifest replacement reason, separating data/evidence/terminal-outcome correction from material policy/criteria/procedure change;
- same-lineage correction allowed only when the governing material selection semantics remain compatible under a deterministic owner rule;
- a material change to eligibility meaning, threshold/cut score, ranking/order method, suppression/routing rule, required evidence meaning, or another rule that changes who can enter/advance/be excluded starts a new policy regime and must not be reached by ordinary
corrected_as_of traversal of the old regime;
- a genuinely semantic-preserving metadata/editorial/version reseal may remain in the same regime only when semantic equivalence is explicitly evidenced rather than inferred from a label;
- every manifest and downstream result binds the exact policy-regime identity/semantic digest in addition to manifest lineage/version/digest/view/as-of;
- re-analysis of historical opportunities under a new policy is a new simulation/counterfactual/analysis result with explicit new-policy provenance, not a retroactive correction of the historical as-recorded result.
If the final UL prefers policy_regime_id, decision_procedure_semantics_id, or another name, preserve the semantic distinction rather than the provisional field name.
RED acceptance cases
Before ADR acceptance or production implementation, fail at least when:
- an eligibility threshold changes (for example 70 → 80) and the replacement is accepted as a same-regime corrected manifest without a new policy regime;
- a ranking/order method changes but
corrected_as_of silently traverses into the new method;
- required evidence changes in a way that changes evaluability/eligibility, but the manifest stays in the old correction regime;
- suppression/routing logic changes who reaches human review while the denominator lineage is presented as a record correction only;
- policy semantic digest/regime evidence is absent, ambiguous, or incompatible with the selected manifest;
- a downstream fairness/validity result cannot identify both the exact manifest view and the governing policy-semantics regime;
- a historical
as_recorded result is rewritten after a later policy change instead of preserving the old result and emitting a new re-analysis version;
- a semantic-preserving editorial/no-op version bump is forced into a new regime without evidence that semantics actually changed;
- a material policy change is hidden as an occurrence correction or manifest replacement merely to preserve one lineage;
workforce_validation must infer policy compatibility from Talent table contents instead of consuming released/versioned provenance.
Completion boundary
Documentation reconciliation alone is not completion. Keep this issue open through ADR/TRACEABILITY reconciliation, executable domain/schema/API contracts, RED→GREEN tests, released owner evidence exchange, downstream workforce_validation binding, and normal protected integration. Do not close it merely because #399 added manifest lineage/as-of semantics or because policy version strings are already stored.
Finding
Fresh review of Talent owner PR #293 at exact
63a33f246faca7ade1bae1c3bebbf6b9771af5ffand the #399 manifest-replacement contract found a distinct scientific/lineage gap.#399 now makes manifest-version selection reproducible inside one replacement lineage: stable lineage identity, immutable manifest version/digest, deterministic supersession, and explicit
as_recordedversuscorrected_as_ofviews. ADR 0292 also binds each stage manifest to an exact eligibility/decision-policy version and required evidence versions.What remains undefined is when a change to eligibility criteria, thresholding/ranking semantics, decision-policy meaning, or required-evidence semantics is still a correction of the same denominator lineage versus a genuinely new selection-policy regime that must not be traversed as an ordinary corrected-as-of replacement.
Without that distinction, an implementation can change the decision rule and still label M2 as a correction of M1. A
corrected_as_ofconsumer can then silently cross from one selection procedure into another while appearing to reconstruct the same denominator. That creates several false-authority paths:workforce_validationcannot tell whether a denominator delta came from corrected records or a changed selection procedure.This is separate from #398 and #399. #398 selects one canonical terminal row per semantic opportunity occurrence inside one manifest. #399 selects one canonical immutable manifest version inside one replacement lineage/view/cutoff. This issue classifies whether two manifest versions are allowed to belong to the same correction lineage at all when the governing selection semantics changed.
Evidence / scientific rationale
Use the following as design evidence, not as a claim that U.S. law universally governs every Orgmetra tenant:
The engineering consequence is narrower than any jurisdictional rule: a material change in selection semantics must not masquerade as a data correction of the same scientific denominator.
Owner boundary
talent_managementowns only the versioned process/policy provenance necessary to say which Talent decision regime produced a manifest.workforce_validationcontinues to own construct/criterion validity, fairness/adverse-impact methods, estimand/grouping choice, study interpretation, and any conclusion about whether evidence supports a changed procedure.No protected demographic attributes move into Talent. No cross-service SQL is introduced. A semantic-regime identifier/digest is provenance, not a validity verdict.
Required contract refinement while ADR 0292 remains Proposed
Define an explicit policy-semantics compatibility boundary for each material stage. Exact UL may change, but the contract needs an equivalent of:
decision_policy_versionplus a canonical semantic policy/evaluation digest or equivalent evidence sufficient to distinguish semantic from editorial/no-op version changes;corrected_as_oftraversal of the old regime;If the final UL prefers
policy_regime_id,decision_procedure_semantics_id, or another name, preserve the semantic distinction rather than the provisional field name.RED acceptance cases
Before ADR acceptance or production implementation, fail at least when:
corrected_as_ofsilently traverses into the new method;as_recordedresult is rewritten after a later policy change instead of preserving the old result and emitting a new re-analysis version;workforce_validationmust infer policy compatibility from Talent table contents instead of consuming released/versioned provenance.Completion boundary
Documentation reconciliation alone is not completion. Keep this issue open through ADR/TRACEABILITY reconciliation, executable domain/schema/API contracts, RED→GREEN tests, released owner evidence exchange, downstream
workforce_validationbinding, and normal protected integration. Do not close it merely because #399 added manifest lineage/as-of semantics or because policy version strings are already stored.