Conversation
check_ring_spec_drift.py reported ring-096-rust DRIFTED against specs/numeric/formats.t27 on five functions. The constitution decides which side moves: Article SSOT-MATH gives numeric meaning "one normative source of truth: specifications in the t27 language", so the spec is the truth and the ring follows it. The spec itself was wrong in one place: gf16_to_f32, ternary_to_f32 and quantize_value returned `gf16` (a u16 encoding) while their names and callers mean a float. They now return f32, which is the boundary the L6 codec specs/numeric/gf16.t27 already uses (gf16_encode_f32(f32), gf16_decode_to_f32(GF16) f32). Its tests stop calling gf16.to_f64, which gf16.t27 does not declare; gf16_to_f32_normal_one uses 0x3E00, which is 1.0 under FORMAT-SPEC-001.json's GF16 bias 31 (0x3C00 is 0.5). rings/ring-096-rust moves its five functions from f64 to f32. A new test re-encodes all 63,488 normal GF16 codes through the f32 boundary and gets the same 16 bits back. 43 ring tests pass. Both formats seals resealed with `t27c seal specs/numeric/formats.t27 --save`. Drift: ring-096 DRIFTED (differing 5, rc 1) -> CONVERGED (differing 0, rc 0). Part of #5906. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Oct 4, 2026
Merged
Merged
Merged
Closed
This was referenced Oct 5, 2026
Merged
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #5746
Part of #5906
Decision: the spec is the truth, so the ring follows it (option a)
The law that decides it:
docs/T27-CONSTITUTION.mdArticle SSOT-MATH: "The mathematical, numeric, and physical meaning of Trinity S³AI / t27 has one normative source of truth: specifications in the t27 language (*.t27files), exercised through the officialtripipeline..."AGENTS.md: "Specs are source of truth -- behavior belongs in.t27/.tri"SOUL.md: "T27 is a spec-first architecture where mathematical truth, not implementation, is the source of truth."conformance/FORMAT-SPEC-001.json+specs/numeric/gf16.t27are the numeric ceiling -- never forked"The spec was wrong in one place.
gf16_to_f32,ternary_to_f32andquantize_valuereturnedgf16, which lowers tou16, an encoding, although each one produces a float. They now returnf32. That is the same boundary the L6 codec already uses:gf16_encode_f32(value: f32) GF16andgf16_decode_to_f32(gf16: GF16) f32. So the change agrees with L6 and does not fork it.Changes
specs/numeric/formats.t27gf16tof32.gf16.to_f64, which gf16.t27 never declares. They compare f32 values directly.gf16_to_f32_normal_onenow uses0x3E00. Under FORMAT-SPEC-001.json (GF16 bias 31,2^(E-31) * (1 + M/512)) that is 1.0. The old value0x3C00is 0.5; it is binary16's encoding of 1.0.ternary_to_f32_is_inversenow checks all three trits.rings/ring-096-rust/src/lib.rsf32instead off64. Internally the encoder still normalises in f64, which is lossless.f32_boundary_is_lossless_for_every_normal_code: all 63,488 normal GF16 codes go throughf32_to_gf16(gf16_to_f32(x))and come back as the same 16 bits.cargo test: 43 pass (42 before)..trinity/seals/numeric_Formats.jsonand.trinity/seals/Formats.jsonwere resealed witht27c seal specs/numeric/formats.t27 --save.docs/now: new entry for this change.Drift (
python3 tools/check_ring_spec_drift.py)Before (origin/master 7943bc4), rc 1:
After, rc 0:
I did not touch
tools/check_ring_spec_drift.pyand did not raise any ledger.Other spec-guards steps (run locally on this branch)
published_figuresself-check: rc 0.published_figures --check: rc 1, with 8 DRIFT figures. They are identical on master, so this red is pre-existing (Four advisory gates are red on master for inherited reasons, one cause per pull request #5497) and not caused by this PR. On CI the job stops at this step on master and on this branch alike.diagnostic_capacity: rc 0.ring_spec_differential.py: ring-090 rc 0 (936/936), ring-099 rc 0 (80/80), ring-096 rc 2. This red is new, and it appears because ring-096 converged: CONVERGED pairs now enter the differential. It cannot be fixed inside this issue's boundary:u5/u4constants verbatim, so the harness does not compile (E0425).TritorFormatvalues. Even with the constants patched, 4 functions are REFUSED.unimplemented!().==, so code0xFFFF(NaN on both sides) would always read as a disagreement.t27c test-report specs/numeric/formats.t27: BLOCKED before and after. On master the cause isgf16.zigFileNotFound. Now it is the spec's bodyless functions (@compileError("not yet implemented")). The seal recordstests.blocked. So "its tests pass" can only be met once formats.t27 has bodies.Left open (outside this boundary)
0x3E00pow2_table[0]andgf16_from_components(0,0,0)tests say0x3C000x7F01, while gf16.t27 usesGF16_NAN = 0xFE01.🤖 Generated with Claude Code