science(talent): separate external artifact integrity from semantic dependency authority

[seonghobae]

Finding

Fresh review of Talent owner PR #293 at exact 47dca8e2a21fd3a89fc5f449773fdfbdb831c038 after the #401 reconciliation found a distinct cross-owner semantic-authority gap.

#401 correctly requires the Talent policy-regime identity to be owner-recomputable from a versioned canonical semantic projection and to close over every material external dependency using a released owner identity plus immutable version/digest evidence. That prevents caller-supplied regime IDs, mutable branch dependencies, and silent omission of material upstream inputs.

What remains underspecified is the meaning of the external dependency digest/version itself. A full released artifact digest is strong integrity/provenance evidence, but it is not automatically a semantic identity for the subset of Job/FJA/KSAO, assessment, performance, evidence-requirement, model/tool, or other owner truth that can alter Talent selection behavior.

Without an explicit upstream semantic receipt, two opposite false-authority paths remain possible:

• a metadata-only/documentation/reseal change in an upstream released artifact changes its full integrity digest and spuriously forces Talent to mint a new policy regime even though the selection semantics are identical;
• a materially changed upstream semantic contract can be treated as compatible only because Talent sees an opaque new version/digest and locally asserts or reverse-engineers equivalence, which would either self-certify the dependency or require Talent to copy/parse foreign owner truth in violation of the bounded-context boundary.

This issue is distinct from #401. #401 makes the Talent-owned aggregate policy-regime projection reproducible and dependency-closed. This issue defines how a dependency owned by another bounded context contributes semantic authority without conflating artifact integrity with semantic equivalence or forcing Talent to reconstruct foreign domain truth.

Owner boundary

The owner of the external dependency remains authoritative for the semantics of its released contract. Examples include job_architecture for Job/FJA/KSAO truth and the applicable assessment/performance/validation owners for their own released evidence contracts.

talent_management may consume only released/versioned owner contracts or ACL-projected evidence. It must not:

• query another bounded context's application tables;
• copy the upstream source model merely to calculate a local semantic digest;
• infer semantic equivalence from labels, release names, version-number shape, or an unchanged local Talent policy;
• treat an artifact-integrity digest as a validity/fairness verdict.

workforce_validation remains authoritative for validity, fairness/adverse impact, estimand/grouping, transportability, and scientific interpretation. It must receive the same released external semantic-dependency provenance needed to reproduce which procedure was actually studied.

Required contract refinement while ADR 0292 remains Proposed

Define an owner-published released semantic-dependency receipt or equivalent ACL projection for each material external dependency. Exact UL may differ, but the contract must preserve these distinctions:

• external artifact integrity identity and external selection-semantic identity are separate evidence fields/meanings;
• the receipt identifies the authoritative owner/context and released contract/artifact/version being referenced;
• the artifact integrity digest or equivalent proves the exact released bytes/object identity consumed;
• a versioned upstream semantic projection/schema, semantic contract identifier, semantic digest, or equivalent owner-issued identity states the material semantics exposed for downstream decision-policy composition;
• any assertion that two upstream releases are semantically compatible is issued by the upstream owner through a deterministic, versioned, auditable equivalence/migration rule or equivalent released evidence—not by Talent prose or caller assertion;
• if an upstream release changes only non-material metadata and the upstream owner publishes reproducible same-semantic evidence, Talent may retain the same policy regime while still recording the new artifact integrity/version provenance;
• if the upstream semantic identity changes in a way material to entry, evaluability, advancement, exclusion, ordering/ranking, thresholding, suppression, routing, or human-review reachability, Talent must not traverse it as the same policy regime merely because local policy bytes are unchanged;
• if the upstream release/version changes but the required semantic identity/equivalence evidence is absent or ambiguous, resolution fails closed. Talent must not locally manufacture compatibility; the safe outcome is an incompatible/new regime or blocked composition until owner evidence exists;
• manifests and downstream analysis results bind the exact set of external owner receipts used, not merely a Talent-computed aggregate digest;
• historical as_recorded evidence retains the exact external owner receipts originally used. A later upstream semantic correction produces a new correction/analysis evidence version rather than mutating released historical evidence.

The repository does not need one universal serialization format or digest algorithm for every bounded context. What matters is that each owner publishes a released, versioned, reproducible semantic contract and that Talent consumes it through the owner boundary without reconstructing foreign truth.

RED acceptance cases

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

1. an upstream release changes only metadata/reseal bytes, the owner publishes the same semantic identity, but Talent creates a new regime solely because the full artifact digest changed;
2. a Job/FJA/KSAO qualification changes materially while local Talent policy bytes remain unchanged, yet the old Talent regime is reused because only a generic release version/integrity digest is recorded;
3. Talent receives an upstream version/digest without a released semantic receipt/equivalence contract and accepts a caller assertion that it is compatible;
4. Talent copies or queries foreign Job/FJA/KSAO/assessment/performance application truth to calculate downstream semantic equivalence locally;
5. a mutable branch, floating release label, unreleased schema, or live cross-service row state is presented as external semantic authority;
6. an external receipt's owner/context/contract identity does not match the dependency slot declared by the Talent semantic projection;
7. artifact-integrity equality or inequality is treated by itself as proof of semantic equality or inequality;
8. two upstream releases are declared equivalent by an unversioned operator note or unauditable migration rule;
9. workforce_validation receives only the aggregate Talent policy_regime_id and cannot obtain the exact external semantic receipts used to reproduce the studied procedure;
10. a later upstream correction or semantic-equivalence decision retroactively rewrites an already released Talent manifest/result instead of producing append-only corrected evidence;
11. two conflicting upstream semantic/equivalence receipts exist for the same released dependency pair and Talent selects one opportunistically instead of failing closed;
12. a receipt is correctly signed/versioned for the upstream owner but is stale, wrong-purpose, wrong-tenant where tenant scope applies, or otherwise outside the declared applicability/effective window and is still admitted into the policy regime.

Evidence scope

RFC 8785, W3C PROV-DM, and NIST AI RMF Playbook references already doctoring #401 remain relevant only for deterministic representation, derivation/provenance, and external-dependency governance. They do not establish that a cryptographic digest is semantic equivalence, nor do they define HR selection validity. The upstream domain owner must define the semantic contract; workforce_validation determines scientific interpretation.

Completion boundary

Documentation reconciliation alone is not completion. Keep this issue open through ADR/TRACEABILITY/doctoring reconciliation; executable owner/consumer contract(s) for external semantic receipts; RED→GREEN tests covering integrity-versus-semantic identity and owner-issued equivalence; released/versioned owner evidence exchange; downstream workforce_validation reproducibility; and normal protected integration.

Do not close this merely because #401 stores exact external versions/digests. Those are necessary integrity/provenance evidence, but this finding concerns the separate cross-owner authority for semantic compatibility.

[seonghobae]

Protected-code validation sharpens this finding and avoids over-specifying a duplicate digest.

At protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f, JobAnalysisSnapshot already provides an owner-side deterministic content identity: canonical_json() is the exact deterministic UTF-8 version-evidence representation and content_digest() addresses those bytes. This is a useful precedent for a released owner semantic receipt, not evidence that every full artifact digest is automatically selection-semantic authority.

The current snapshot representation also serializes provenance fields such as evidence source_title, source_version_code, retrieved_at, and content_digest_sha256, and the snapshot document includes review provenance such as reviewed_at. Therefore its content digest can change when provenance/version-evidence bytes change even if a downstream Talent selection procedure would consider the relevant Task/FJA/KSAO meaning unchanged. Conversely, Talent cannot safely decide that two changed snapshots are semantically equivalent by parsing/copying Job Analysis internals; job_architecture/Job Analysis remains the semantic owner.

Refined #402 rule:

• Separate evidence meanings do not require two different hash values or duplicate artifacts. An upstream owner's existing canonical content digest may satisfy both exact-artifact integrity and downstream semantic-dependency identity only if the released owner contract explicitly defines the canonical projection as the downstream-material semantics and defines its stability/equivalence rules.
• If the canonical owner snapshot intentionally includes provenance/editorial fields whose change does not necessarily change downstream selection semantics, the upstream owner must publish a narrower versioned semantic projection/receipt or owner-issued equivalence evidence. Talent must not manufacture that projection itself.
• If a provenance field is actually material to eligibility/evaluability/selection (for example evidence-version or applicability semantics), the owner contract may declare it material; this issue does not presume that all provenance is non-semantic.
• Generic build/package/release digests, floating version labels, or opaque artifact digests remain insufficient by themselves unless the owner contract gives them the required semantic meaning.

This protected-code read confirms #402 is not a hypothetical duplicate of #401: the repository already has strong content-integrity/version evidence, while cross-owner semantic compatibility authority is still a separately specified contract concern. Keep #402 open and reconcile this refined rule into ADR 0292/TRACEABILITY before the #100 commercial baseline is changed.

[seonghobae]

Owner ordering update: fresh review found dependent execution-congruence issue #403. Keep #402 first. The runtime cannot prove expected-vs-observed execution congruence safely until each material external dependency has owner-issued semantic authority rather than only an opaque integrity/version digest. After #402 is reconciled into ADR 0292/TRACEABILITY/doctoring, #403 can bind the observed resolved dependency/parameter set to those owner receipts. Do not collapse the two issues: #402 is cross-owner semantic authority; #403 is per-stage actual-execution reconciliation.

[seonghobae]

Owner-side documentation reconciliation is now ordinary-forward on PR #293 exact 460896edc5ae63624d42f10d2c61892ff902713a. ADR 0292, Talent TRACEABILITY, and reference doctoring now distinguish external artifact integrity from owner-issued downstream selection-semantic authority, define an ExternalSemanticDependencyReceipt-equivalent contract, prohibit Talent-side reconstruction of foreign owner truth, and carry the #402 RED boundary. Sole-writer PR #100 has also propagated the durable commercialization invariant at exact ba5bd1bf8c3d0c4e83c762a783c5cd1f1976156b.

This is not completion. #402 stays open until executable owner/consumer domain/API/schema contracts demonstrate the RED cases, owner receipts/equivalence evidence are released and consumed without mutable/source-copy shortcuts, workforce_validation can reproduce the dependency semantics from released evidence, and normal protected integration succeeds.