Repository navigation
scientific(uncertainty): bind joint precision to owner-issued reference fit #670
Description
Finding
Fresh review of Draft #639 after #665/#666/#667/#669 found that the joint posterior path still permits a detached input/model/config substitution that the newer fit-owned numerical contracts already forbid.
ReferenceTopicInput::build_joint_coordinate_precision(&self, model, config, topic_ids) is public. A caller may therefore clone or hand-mutate a ReferenceTopicModel, pair it with a dimension-compatible ReferenceTopicInput and ReferenceTopicModelConfig, and obtain a JointCoordinatePrecision that looks owner-produced even though those three values never came from the same ReferenceTopicFit.
This matters because JointCoordinatePrecision::draw_joint_gaussian() and JointPosteriorDrawSet treat the resulting matrix/coordinates as the basis for deterministic plausible values. #665 introduced ReferenceTopicFit specifically to prevent this class of fit/input/config rebinding, but the joint-precision builder bypasses that aggregate.
A second, narrower coordinate-identity problem remains: the builder also accepts arbitrary caller-authored Vec<Uuid> topic IDs. That must not be mistaken for #663's source/vocabulary-proven topic identity. This issue should first bind input/config/model to the owner-issued fit; topic identity remains provisional until #658/#663 settle.
Required RED
Using an actual converged CPU f64 reference fit:
- require a public
ReferenceTopicFitmethod that builds the joint precision from the aggregate's retained input/config/model rather than accepting those values separately; - prove the returned document order and coordinate means match the fit-owned document-coordinate summary;
- keep the current generalized-Gauss-Newton matrix arithmetic and scientific(uncertainty): align diagonal Laplace variance with retained GGN curvature #669 diagonal consistency unchanged;
- do not let the new API imply that caller-supplied topic UUIDs are Evidence-authenticated or semantic identities.
The first RED may be API-absence at the public fit boundary. It must not claim release-level provenance or #663 completion.
Minimal causal direction
Add a fit-owned joint-precision projection on ReferenceTopicFit that delegates to the existing numerical builder using only the aggregate's private retained members. The detached builder may remain temporarily for internal/compatibility use, but the external contract should migrate to the fit-owned path and the old bypass must subsequently be narrowed before release.
Do not duplicate precision arithmetic, do not change the objective/estimator, and do not create a second topic-identity scheme while #658/#663 are unresolved.
Acceptance
- realistic public RED -> minimal fit-owned Rust API -> exact-head GREEN;
- existing joint precision and Philox plausible-value arithmetic remain unchanged;
- CHANGELOG plus fix(release): bind fail-closed reconstructable topic-lineage results (#638) #639/release(uncertainty): bind diagonal-Laplace variance to its fitted ALR location #664/scientific(uncertainty): align diagonal Laplace variance with retained GGN curvature #669/docs(ddd): restore queue authority and bounded-context ownership #435 handoff are current;
- detached public builder and caller-authored topic IDs are explicitly tracked as remaining release work, not silently treated as authoritative;
- no source copy, skip/xfail, tolerance inflation, or gate weakening.
Activity
test(topic): require fit-owned joint precision projection (#670)
fix(topic): bind joint precision to reference fit (#670)
docs(changelog): record fit-bound joint precision (#670)
seonghobae commentedon Sep 22, 2026
Source-level progress on the #639 owner lane:
e9fafa18457b5a57ccd6896c68053048f6667cf0adds an actual converged-fit test requiringReferenceTopicFit::build_joint_coordinate_precision(...). The predecessorab3453f...has no such fit-owned API. Hosted runs for the RED commit were superseded/cancelled by ordinary-forward commits, so this is not being claimed as hosted RED evidence.7e6186031056102ac708d180815951fe3826fcacadds the method onReferenceTopicFitand delegates to the existing owner arithmetic using only the aggregate's private retained input/config/model. No precision/objective/draw arithmetic changed.9472071f5bbdb05e0ec98727aa0f9a73bb6fd010.The new public supported path removes detached input/model/config rebinding for callers that use the owner-issued fit. This issue remains open because
ReferenceTopicInput::build_joint_coordinate_precision(...)is still public for compatibility and still accepts caller-authored topic UUIDs. Those UUIDs remain provisional fit-local coordinates, not #663 source/vocabulary-proven topic authority. Before release, the detached bypass must be narrowed/migrated and topic coordinate identity must converge with #658/#663 rather than inventing another scheme.Exact-head hosted checks for
9472071f...are newly queued; no GREEN is transferred from a predecessor.test(scientific): require joint precision owner boundary (#670)
fix(scientific): seal detached joint precision builder (#670)
test(scientific): migrate known-truth precision to fit owner (#670)
docs(changelog): record sealed joint precision owner boundary (#670)
seonghobae commentedon Sep 22, 2026
Fresh owner-boundary repair on canonical #639 ordinary-forwards the remaining detached-builder gap without changing GGN/Philox arithmetic.
9bcae05d6b87510d3f690f2d6d0a4a4d7a692a0frequires downstream code to be unable to nameReferenceTopicInput::build_joint_coordinate_precision; on predecessor9472071f...the method was public, so the snippet would compile and thecompile_failcontract would fail.517edc5731542c6642ae257f78ca45d05726e4b3makes the detached arithmetic primitivepub(crate)and documents that public ownership isReferenceTopicFit.50a29980a6c401403fb98c9b8afaf369a8622a24moves the existing real-fit joint-precision assertion toReferenceTopicFit::fit(...).build_joint_coordinate_precision(...); malformed geometry remains owner-internal where crate-private access is appropriate.9eb52c22dbceb50ac0086554cba1ac76e10e1958.The remaining
topic_ids: Vec<Uuid>on the fit-owned method are still provisional caller coordinates and do not satisfy #663/#658 source/vocabulary-proven topic identity. Keep this issue open until exact-head hosted gates and normal owner review/landing; no hosted GREEN is claimed yet.