Skip to content

science(talent): separate policy-regime changes from denominator corrections #400

Description

@seonghobae

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:

  1. an eligibility threshold changes (for example 70 → 80) and the replacement is accepted as a same-regime corrected manifest without a new policy regime;
  2. a ranking/order method changes but corrected_as_of silently traverses into the new method;
  3. required evidence changes in a way that changes evaluability/eligibility, but the manifest stays in the old correction regime;
  4. suppression/routing logic changes who reaches human review while the denominator lineage is presented as a record correction only;
  5. policy semantic digest/regime evidence is absent, ambiguous, or incompatible with the selected manifest;
  6. a downstream fairness/validity result cannot identify both the exact manifest view and the governing policy-semantics regime;
  7. 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;
  8. a semantic-preserving editorial/no-op version bump is forced into a new regime without evidence that semantics actually changed;
  9. a material policy change is hidden as an occurrence correction or manifest replacement merely to preserve one lineage;
  10. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions