Repository navigation
science(workforce-validation): bind final-weight lineage to exact typed component receipts #411
Description
Finding
Fresh review of canonical Workforce Validation owner PR #235 at exact 203da7a1051eb3282a98e69e732023f579325413 found a reproducibility gap inside the otherwise complete-looking #407 final analysis-weight contract.
FinalAnalysisWeightAuthorityRecord binds the base-weight method, base_weight_evidence_digest, base-weight artifact, ordered adjustment coordinates, and final artifact. Each FinalWeightAdjustmentCoordinate binds an adjustment code/method, input/output artifacts, configuration digest, evidence_receipt_digest, and evidence_kind.
The separately governed typed component authorities are stricter:
BaseWeightAuthorityRecordowns an exactbase_weight_evidence_receipt_reference, receipt digest, and evidence version.NonresponseAdjustmentAuthorityRecordowns an exactnonresponse_receipt_reference, receipt digest, and evidence version.- Calibration and trimming/bounding authorities likewise own explicit receipt identity/version/digest and owner-resolved chronology.
The final-weight receipt currently carries only digest-level linkage for the base-weight evidence and each specialized adjustment receipt. It does not carry the exact base-weight receipt reference/version, nor an exact specialized adjustment receipt reference/version inside each ordered adjustment coordinate. The existing owner-read APIs do not define a released content-addressed reverse-lookup contract that can deterministically recover those identities from digest alone.
Consequently, a released final-weight receipt can satisfy its own structural contract while a downstream reproducer cannot deterministically re-resolve the exact typed component authority that supposedly justified a base weight or adjustment. It must either guess/scan by digest, rely on out-of-band state, or reconstruct foreign truth. That is weaker than #407's requirement that the exact final point-estimation construction be independently reproducible.
This is distinct from #410. #410 canonicalizes the shape of tuple-backed records after owner reads. This finding concerns whether the final-weight lineage contains sufficient immutable coordinates to perform the correct governed component reads in the first place.
Owner boundary
workforce_validation remains the owner of the final point-estimation weight construction and its scientific lineage. Component values remain with their existing authorities. Do not copy row-level weights, protected auxiliary values, response/disposition source rows, or foreign application tables into the final-weight record.
The final-weight contract must bind released typed component evidence through exact owner coordinates. A digest is integrity evidence; without an explicit released reverse-lookup/equivalence contract it is not by itself an owner-record locator or proof of which append-only receipt/version supplied the evidence.
Required contract
A final analysis-weight receipt must make every material component authority independently re-resolvable from immutable released coordinates. At minimum:
- bind the exact base-weight evidence receipt reference, governed evidence version, and digest in addition to method/artifact identity;
- for every adjustment whose
evidence_kindnames a governed specialized receipt, bind the exact specialized receipt reference, evidence version, and digest together with the existing method/configuration/input/output coordinates; - verify that the referenced typed component record's input/output artifact transition and method/configuration semantics agree with the ordered final-weight coordinate before the final receipt can authorize scientific use;
- preserve component owner-resolved release/supersession chronology. A final weight may not use component evidence that had not been released by the relevant construction instant or that is outside the allowed authority interval for the governed use;
- keep base, intermediate adjustment, final point weight, eligibility, and variance evidence distinct; do not substitute one receipt family for another merely because digests or artifacts match;
- if a future design deliberately uses digest-only resolution, first establish a released/versioned owner contract that makes digest-to-canonical-receipt resolution deterministic, collision/conflict fail-closed, purpose-bound, and auditable. Do not infer that contract from database indexing or implementation convenience.
RED acceptance cases
- A final-weight receipt contains the correct base-weight evidence digest/artifact but no exact base-weight receipt reference/version, and no released digest-resolution contract exists.
- Two append-only base-weight receipts can share otherwise compatible scientific coordinates, while the final receipt cannot state which governed receipt/version it consumed.
- A specialized nonresponse/calibration/trimming adjustment contains only
evidence_kind+ digest; reproducing the final receipt requires guessing or scanning for the receipt reference. - A caller substitutes a different specialized receipt identity with matching local method/artifact fields and the final-weight resolver cannot detect that the governed receipt lineage changed.
- A component receipt was superseded or not yet released for the construction/use chronology, but digest-only linkage cannot establish the exact component authority interval.
- Reproduction requires cross-context SQL, mutable branch/source inspection, or out-of-band operator knowledge to map a digest back to its owner receipt.
- A final result is treated as scientifically reproducible even though the final analysis-weight receipt cannot re-resolve every typed component authority it names.
Completion boundary
Do not close for issue prose or digest-field documentation alone. Completion requires an executable canonical #235/#407 contract, source-first RED→causal GREEN coverage, exact typed component receipt binding or an equally strong released deterministic resolver contract, current-head 100% owned test/docstring/edge coverage, PostgreSQL/packaging/security acceptance, independent review, normal protected integration, and durable adoption through #248 or a verified successor after the parent is protected truth.
Activity
seonghobae commentedon Sep 19, 2026
Implemented an ordinary-forward source contract on canonical PR #235; this is not hosted/protected completion yet.
Lineage:
afb7422e3fdd1d29d4230563032cdccd63f920d6added the absent final-weight→typed-component binding contract;77f89d26fc0b297d3f7ae131b6e3ac3dd353cbf6addedfinal_weight_component_binding_authority.py;540f5810b5a046f6cba18e8faf37a0f60266bb1f;af509f32fab910f96015fab7412d82a137932051;7ba1b111cff71462780d69afdf53014c9cc8f162.The repair deliberately does not mutate the already-governed v1 final analysis-weight receipt. Instead it introduces a released companion owner record keyed only by exact final receipt reference/digest/evidence-version. That record returns the exact base-weight receipt reference/version/digest and exact specialized adjustment receipt reference/version/digest. This makes digest a consistency coordinate rather than an implied reverse-lookup API and leaves row-level weights/response/calibration source values in their owners.
The new family is canonical tuple-backed owner evidence, so it also applies #410's fail-closed reconstruction rule to the outer record and nested specialized receipt locators before target/currentness projection. README durable handoff now requires #248 or a verified successor to persist this as the 22nd application-owner family after normal parent integration.
Current exact-head Foundation/Security/SAST/CodeQL runs were queued when checked. Do not close #411 yet: exact-head 100% owned coverage, package/PostgreSQL/security acceptance, independent review, protected #235 integration, and durable atomic/unique binding adoption remain outstanding. The source repair is evidence of progress, not released scientific authority.
seonghobae commentedon Sep 19, 2026
Second-stage #411 source repair advanced through exact public package closure; issue remains open and this is not hosted/protected completion.
Fresh source review found that the first companion binding solved immutable locator identity but not executable re-resolution: native component owner APIs such as nonresponse/calibration require their complete scientific compatibility tuples, so downstream code could not call them from only receipt reference/version/digest without out-of-band coordinates.
Ordinary-forward lineage for this residual gap:
b83372b78f99b995e5728a106c20803fa064032f: requires exact receipt-identity component reads, semantic cross-checking, construction-time chronology, missing-receipt fail-closed, and complete specialized-adjustment coverage;a6377d77f45114f47b3dd53206c799869fcdc723: addsfinal_weight_component_evidence_resolution.py;13030a961de8feb6b549834a68a0d0d589314189: proves the new reproducibility contract was not exposed through the owned package;af292bd8febb5e2b1231c276446d1eb0c77c73cd: exports projection types, protocol, errors andcorroborate_final_weight_component_evidencethroughorgmetra_workforce_validation_api.The resolver defines value-minimized exact base/specialized component projections and a deterministic receipt-identity read port. It canonicalizes returned tuple evidence, verifies the binding targets the same final receipt, requires every and only governed specialized adjustment to have a locator, checks base method/artifact semantics and specialized method/version/input/output/configuration against the ordered final-weight construction, and requires each component to have been released and current at final-weight construction.
This does not create a 23rd application-owner family; #407 remains at 22 families. Durable #248 adoption still must implement released/auditable adapter projections from native component authorities to this identity resolver after normal parent integration. Digest scans, mutable indexes, source-copy, cross-context SQL, or operator knowledge are not substitutes.
Current source head is
af292bd8febb5e2b1231c276446d1eb0c77c73cd. Do not close #411: full exact-head pytest and 100% statement/branch/docstring/edge evidence, installed-wheel public-surface/package closure, PostgreSQL/security gates, qualifying independent review, protected #235 integration, and durable unique/atomic binding + receipt-identity resolution remain required.seonghobae commentedon Sep 19, 2026
#411 authority update for current #235 exact head
095bae6e7115e20b5d76cd41d87772e7c4297d97.Fresh source review found that the first companion binding solved immutable locator identity but not executable re-resolution: native component owner APIs require their complete scientific compatibility tuples, so receipt reference/version/digest alone still required out-of-band coordinates.
Ordinary-forward residual lineage is now
b83372b78f99b995e5728a106c20803fa064032fRED →a6377d77f45114f47b3dd53206c799869fcdc723deterministic receipt-identity resolution;13030a961de8feb6b549834a68a0d0d589314189RED →af292bd8febb5e2b1231c276446d1eb0c77c73cdpublic package closure;f6bbe7f018869411ba7d0d9b2898f440cb8c6130RED →095bae6e7115e20b5d76cd41d87772e7c4297d97binding-after-final release causality.The resolver now canonicalizes returned tuple evidence, verifies the binding targets the same final receipt, requires every and only governed specialized adjustment to have a locator, checks base method/artifact semantics and specialized method/version/input/output/configuration against the ordered final-weight construction, requires component release/currentness at final-weight construction, and rejects a binding released before final-weight authority.
This remains source progress, not completion. #407 stays at 22 application-owner families; the resolver is a cross-owner consistency service. #248 still must implement released/auditable durable projections after normal parent integration. Exact-head pytest/100% coverage, installed-wheel closure, PostgreSQL/security gates, qualifying independent review, protected integration and immutable release remain outstanding. Keep #411 open.
seonghobae commentedon Sep 19, 2026
Fresh #411 follow-up at canonical #235 exact
f6c060031819a50d2eaa1674104739c830b6f6f6: receipt-identity and transform semantics remain intact, but review found a distinct owner-scope provenance gap now tracked as #412.Before #412,
BaseWeightComponentEvidence/AdjustmentComponentEvidencedid not carrytenant_record_idorvalidity_study_id; the read port received those lookup coordinates, but returned projections could not independently prove that they came from the same owner scope. #412 source lineage is65e711df...RED →313b4b9e...scope-bound production repair → currentf6c06003...wrong-study/wrong-tenant regressions.The #411 deterministic locator/semantic contract is therefore strengthened, not replaced: exact receipt identity + native owner tenant/study provenance + transform semantics + release/currentness are all required. #411 remains open until exact-head hosted/package/PostgreSQL/security/independent-review/protected-integration and durable #248 adoption are complete.
seonghobae commentedon Sep 19, 2026
Additional #411 residual verified and repaired ordinary-forward after #412 scope binding.
The issue body already requires component owner chronology to be valid for both construction and governed use. At head
de1751a7...,corroborate_final_weight_component_evidence(...)only enforced component release/currentness atfinal_weight.constructed_at; it checked final-weight and binding currentness atused_atbut could still accept a base or specialized component superseded after construction and before governed use.Source lineage:
1c703e3e1a9ef3f63763b91f9eed82ec70b957e6source-first RED adds base and specialized cases superseded after construction but beforeUSED_AT;4e41e8f427dd3047e9326dca83eeb51ef34501dcadds_require_component_current_at_use(...)and applies it to base and specialized projections after construction-time validation.This preserves historical construction validation while preventing a still-current final weight/binding from authorizing use after one of its exact typed component authorities has already cut over. This is source-established repair only; keep #411 open pending exact-head hosted/package/PostgreSQL/security/independent-review/protected integration and durable #248 adoption.
seonghobae commentedon Sep 19, 2026
#423 follow-up: exact #235 predecessor
89b1334c...still admitted a materialcustom_transformwhose only evidence coordinate was a digest, while this issue's component-binding/corroboration path intentionally resolves only governed specialized receipt families. That left one remaining digest-without-locator admission path under the broader #411 reproducibility principle. Source-first REDd7aa67c6d2550a0b3ff8d790e845667009d02438, causal admission repair17b80f9e360dc82bf93c6831c2c6d3504af50a90, and stale-test alignment9625f95dc3b90ba119c462a7587accf2c4f068e1now fail closed for adjustment codes without a released governed owner resolver. This is additive to #411; do not close either issue from source alone. Current-head functional/coverage/wheel/PostgreSQL/hosted-review/protected-integration evidence must be reacquired.