Repository navigation
release(config): reject zero-seed RNG alias in topic-lineage wire #660
Description
Finding
The CPU f64 reference estimator initializes its xorshift state with seed.max(1). Consequently deterministic seeds 0 and 1 execute the same RNG stream and the same numerical initialization, although tepp.trsl_topic_lineage.reference_config.v1 currently admits both as distinct wire values and hashes them into different configuration identities.
This creates a second released alias after #659's duplicate-value repair: [0,11] and [1,11] name different retained configuration bytes even though the first fit attempt is numerically identical. A manifest such as [0,1] also executes the same initialization twice while satisfying ordinary integer uniqueness.
The reference estimator records the caller seed in FitState, so silently normalizing 0 to 1 at the release boundary would still obscure the actual wire identity. The safe first-release boundary is to refuse zero rather than change the estimator RNG mapping or rewrite caller bytes.
Required RED
At the digest-bound topic-lineage configuration boundary:
- a nonzero ordered manifest such as
[1,11]remains valid; [0,11], with its own correct canonical SHA-256, fails closed before fitting;- no
0 → 1normalization or silent manifest rewrite occurs; - distinct nonzero seed order remains preserved.
Minimal causal direction
Extend TopicLineageMethodConfiguration::parse so the unreleased v1 wire accepts only nonzero, unique deterministic seeds while leaving ReferenceTopicModelConfig, xorshift implementation, fit selection/tie behavior, and scientific arithmetic unchanged.
Keep #639 Draft and ordinary-forward. Exact-head hosted checks and qualifying independent review remain required before merge or release. Refs #638 #639 #659.
Activity
test(release): refuse topic-lineage zero-seed alias (#660)
fix(release): reject topic-lineage zero-seed RNG alias (#660)
docs(changelog): record nonzero topic-lineage seed manifest (#660)
docs(release): refuse zero-seed RNG alias (#660)
seonghobae commentedon Sep 21, 2026
#660 ordinary-forward status correction: the first fixture commit
f1753a96df4c2c0a52b6c29e81b6717a6734b091was not a valid causal RED because it hard-codedselected_seed = 1while the zero-seed configuration declared[0,11]; predecessor artifact validation would already reject that detached selected-seed mismatch. Production repair6c9a86d5105c0137f9da48c8c7d6f9a9e836d03fstill addresses the independently verified source defect (fit_seedinitializes RNG state withseed.max(1), so wire seeds 0 and 1 execute the same stream), followed by CHANGELOG9a638c9ea779c86a8f9f9e55c0274bd1129695f8and release-contract doctoring7f3813f01397d19081dc7ffdb6dcf0f23730dd38. Corrected regression fixtured7989f9ce7ea2f3a2daa6300f5aa77dadea592a1binds the zero configuration toselected_seed = 0, removing the confound. Because that correction is ordinary-forward after the production repair, no pre-fix test RED is claimed for #660.ReferenceTopicModelConfig, xorshift arithmetic, first-wins selection, and caller bytes remain unchanged; hosted exact-head GREEN is still required.test(release): bind zero-seed fixture to selected seed zero (#660)
seonghobae commentedon Sep 22, 2026
Follow-up owner finding: the wire-level zero-seed repair is valid and should remain. Fresh review of the numerical owner found that
ReferenceTopicModelConfig::validate()still accepts seed0and duplicate seeds, whilefit_seed()usesseed.max(1)and the fit loop executes the manifest verbatim. With the new owner-issuedReferenceTopicFit, this means fit-local owner state can still be minted from[0,11]or[7,11,7]even though the release wire correctly refuses those aliases. Opened #668 to move the nonzero+unique invariant into the numerical owner while preserving seed order and keeping #659/#660 parser checks as defense in depth. No change to this issue's release repair or RNG arithmetic is proposed.