Repository navigation
spec-guards: ring-096-rust disagrees with specs/numeric/formats.t27 on 5 signatures (f32/gf16 vs f64) #5746
Closed as not planned
Description
spec-guards step "Does every ring still agree with the spec it names" (tools/check_ring_spec_drift.py) is red on master. One pair causes it:
DRIFTED ring-096-rust specs/numeric/formats.t27
hand fns 7, spec fns 6, shared 6, differing 5
differs: f32_to_gf16
differs: f32_to_ternary
differs: gf16_to_f32
differs: quantize_value
differs: ternary_to_f32
This is old, not new. Master never reached this step while the seal step was red. #5737 made the seal step green, and that exposed it. I reproduced it on a clean master (146321c) with rc 1, and in run 37115950307. #5497 lists it as one row of a larger table: "A numeric-type decision". This issue is that row on its own.
Where they disagree
| fn | specs/numeric/formats.t27 |
rings/ring-096-rust/src/lib.rs |
|---|---|---|
gf16_to_f32 |
(x: u16) -> gf16 |
(x: u16) -> f64 |
f32_to_gf16 |
(a: f32) -> u16 |
(a: f64) -> u16 |
f32_to_ternary |
(x: f32) -> Trit |
(x: f64) -> Trit |
ternary_to_f32 |
(t: Trit) -> gf16 |
(t: Trit) -> f64 |
quantize_value |
(x: f32, fmt: Format) -> gf16 |
(x: f64, fmt: Format) -> f64 |
The spec's own return types do not agree with each other either. For example, gf16_to_f32 returns gf16, not f32.
Decision needed
Which side is the source of truth?
- (a) The spec. Fix the return types in
formats.t27that are clearly wrong (gf16_to_f32 -> f32, etc.), then bring the ring in line with the spec'sf32. - (b) The ring. The
f64signatures are the intended contract. Rewrite the spec signatures tof64and reseal anything the change touches.
Boundary
rings/ring-096-rust/specs/numeric/formats.t27- plus the seal(s) for
formats.t27under.trinity/seals/, if the spec changes
Do not touch tools/check_ring_spec_drift.py, and do not raise any ledger to hide the drift.
Acceptance
python3 tools/check_ring_spec_drift.pyno longer reports ring-096 as DRIFTED.- The spec-guards step "Does every ring still agree with the spec it names" is green on the PR.
- If
formats.t27changes, it is resealed witht27c seal specs/numeric/formats.t27 --save, and its tests pass.
Refs #5497
Activity
gHashTag commentedon Oct 4, 2026
Tracked as row 1b of epic #5906 (master's three inherited reds). Next step there: check whether docs/T27-CONSTITUTION.md (SSOT-MATH, L6) already answers the spec-or-ring question this issue asks; if it does not, the decision stays with the owner.
chore(seals): take master's formats seals before merging master (Refs #…
chore(policy): one-time exception for ring-096 lib.rs (Refs #5746)
chore(seals): re-seal formats.t27 against master's compiler (Refs #5746)
github-actions commentedon Oct 8, 2026
Re-filed as #7776.
An attempt claimed this issue on 2026-10-03 and left an empty branch. A dispatch row that has spent its retry ceiling is released once and then keeps its issue for good, which is the right rule for a third identical failure and the wrong outcome for an issue nobody ever attempted twice. The new issue carries the same work, the same boundary, and today's brief.
Closing this one so the swarm can take the work again.