fix(conformance): check tern_tc receipts, and cover every ternary matrix

[gHashTag]

Description

This PR fixes the Stage B.1 harness from 1f131fd. That harness printed "284160/284160 receipts authenticated under node0's key", but it never compared a tag. It built each receipt preimage and then dropped it. It counted status 0x01 as authentication, ignored the nonce echo, and compared only row sums.

I tested it against a cell that signs with a key the host does not hold. It still printed receipts authenticated 160/160 and PASS.

• Still stands: the 28,416 bit-exact row dots.
• Withdrawn: the 284,160-receipt count, because it was never checked. It is replaced by a measurement with the fixed harness (below).

The rewrite also covers work that had been booked as new hardware. As a result, all 42 ternary matrices of tern_tc run on the existing 32-trit cell:

• w_down: 864 = 27 × 32, so each row is 27 chunks.
• wk and wv: these are 320-in matrices that were skipped before.
• int8 activations (--act int8): each activation is split into six balanced-ternary digit planes.

Board runs (2026-09-27, owner's M1 Pro, recorded in TERN_TC_LAYER_RECEIPTS.md and conformance/board_runs/):

• All 42 matrices of the trained model at window 24: PASS. 403,200/403,200 receipts verified, 33,792/33,792 rows bit-exact, 85.5 s, 4,716 answers/s (board_runs/tern_tc_all_w24.log).
• Layer 5 w_down with int8 activations at window 8: PASS. 51,840/51,840 receipts, 320/320 rows.
• The link limit is the USB bridge's receive buffer.
  • Every long run with more than 512 bytes of answers in flight slipped: window 64 four times, window 30 once. No answer that arrived whole was wrong or badly signed.
  • A test registered before it ran (rerun step 3) predicted a PASS at window 26 (494 B) and a slip at window 30 (570 B). Both happened. The threshold is therefore between 494 and 570 bytes, around the CP2102N's 512-byte receive buffer.
  • Not the old hub either (rerun step 4; pre-registered in cf82eeb at 09:34:19Z, run 15 s later, recorded in c590308 and corrected in e1834ee, board_runs/tern_tc_all_w64_genesys.log).
    • Setup: the CP2102N alone behind a Genesys 05e3:0610 single-TT hub on another bus, away from the FE1.1s dongle that carries the JTAG adapter.
    • Result: window 64 still slipped, as predicted. 188,936 receipts were verified. Exit 1, one attempt, and the command changed only in its port.
    • The hole is 53 bytes, not the 8 first recorded (e1834ee). I checked this against the harness's frame layout (A5 | y | status | nonce | node id | tag):
      • the failed read opens with the first 4 bytes of answer 0x3e208, the one due next, and then the head of answer 0x3e20b;
      • so the last 15 bytes of 0x3e208 and all of 0x3e209 and 0x3e20a were lost.
      • The commit message of c590308 still says 8.
    • What it shows: the old dongle, bus and port are not needed for the loss. Between the window-64 control and this run the harness changed only in comments and help text, so for that pair the USB path is the only difference.
    • What it does not show: the earlier window-64 slips came after 6,744 to 19,049 jobs, but a single run cannot say whether the old dongle made loss more frequent.
    • Untried: a connection with no hub at all.
  • The CP2102N datasheet asks for handshaking above 1 Mbaud. The node has no RTS/CTS.
  • Harness process pauses are not the trigger: runs at 24 and 26 survived pauses of 22.4 and 25.8 ms, and the reload control below survived 127.9 ms.
  • What stalls the bridge's USB transfers is not measured.
  • The harness now keeps 19 × window under 512 bytes (default 24).

Also on this branch (from the owner's machine, bc3015d to 09b3d6f):

• GFTernary × Z[φ], layer 0, on the board: PASS, as pre-registered.
  • gft_zphi_ax7203.py runs GFTernary (t·φ) weights on Z[φ] activations on the same node, with no new RTL and no reflash.
  • Result: 403,200/403,200 receipts verified, and 5,632/5,632 Z[φ] rows bit-exact against a plain Z[φ] multiplication oracle, in 85.35 s (board_runs/gft_zphi_l0.log).
  • The pre-registration was committed 38 s before the run started.
  • Not shown: a TNF accumulator or rounding. The digit recombination and the φ step are host arithmetic.
• TERN_TC_WEAK_POINTS.md ranks ten weak points of the tern_tc record.
• TERN_TC_PRIOR_ART.md is a prior-art survey. It checks the CP2102N figures against the datasheet.

Later on the owner's machine (523447c to fba3995), recorded here as committed:

• GF8 ADD, exhaustive, on the AX7203 at 154839 baud: 65,536/65,536 bit-exact, 0 fails, 254 s. The run was pre-registered in 054b1fe and recorded in bc40613 (board_runs/gf8_add_exhaustive_154839.log).
• TNF16 add and mul on the AX7203: 1,035,886/1,035,886 bit-exact, 0 fails, 0 lost (cf12a50, board_runs/tnf16_board_ax7203.log). This is the first board log for any TNF format (tnf_ref.py TNFFormat(4, 11), v2-spec).
  • It was run once, as pre-registered in aa4511d, 19 minutes after that commit.
  • The log ends with the spec's PASS_LINE verbatim. It names the spec's sha256 703b35c0…, which equals the pre-registered file's, and the request-set sha256 2b1ea80b…2c38, which was written into FORMATS_ON_BOARD.md before the run.
  • All eight sets passed, add and mul for each: edge, near, pinned and uniform.
  • 10,118 answers/s at window 24, over 102.4 s.
  • Before the board, the core RTL, a Python model of the datapath and the yosys gate netlist had each matched all 1,035,886 requests.
• mxdot4, an MXFP4 and TNF4 block dot product, on the AX7203: 251,616/251,616 bit-exact, 0 fails, 0 lost (e243f27, board_runs/mxdot4_board_ax7203.log). One exact cell computes the dot product of two 32-element blocks with E8M0 scales, and the two formats differ only in the element table.
  • Before the board (8b98e6c, 4f68a4d): the core RTL and the yosys gate netlist of the core (FORMATS=3, 1,706 LUT instances, on xilinx/cells_sim.v) each matched all 251,616 requests.
  • The run. One flash (board_runs/mxdot4_flash.log: IDCODE 0x13636093, 778.8 s) and one run, 07:58:47 to 08:02:02 UTC. All 10 groups passed: edge, pinned, scales, top and uniform, for each format.
  • The run speed. 1,413 answers/s at window 6 behind the USB hub, 178.0 s against an 83.7 s wire floor. The USB round trip sets that rate, not the board.
  • Checked here against what was committed before the run:
    • the log's spec sha256 e63d4a31… equals the spec file at 8b98e6c, and the spec is unchanged since;
    • the log's last line is the spec's PASS_LINE verbatim, at the spec's window of 6;
    • the vector sha256 107843f1…cb2d is the one written into FORMATS_ON_BOARD.md in 8b98e6c;
    • the flashed bit's sha256 dec2ada9…d01a equals artifacts/bitstreams/mxdot4_board_ax7203.bit.sha256 from 8b98e6c;
    • mxfp_ref.py and block_tnf.py match the sha256 pins in the spec;
    • between 8b98e6c and the run, no spec, RTL, bitstream or vector generator changed. The one host-script edit in e243f27 is its docstring's run command.
  • What this is not:
    • It is exactness on silicon for both element tables through one datapath. It is not a quality result, and the block-axis perplexity verdict (MXFP4 21.94, TNF4 36.72) stands.
    • The pre-registered cost prediction (TNF4 within 5% of MXFP4 in LUTs) is refuted (-12.0%), and the sign of the gap flips with the synthesis flags. What holds regardless is structural: TNF4 is a subset of MXFP4.
• The TRI-NET node is back on the board, and its control run passed as pre-registered (pre-registered in 0fdbeb6, run recorded in c1e7091).
  • The reload. One load of the CI node0 artifact from run 30762491794 (board_runs/node0_ci_flash.log): sha256 0fafd225e2d18f73…eddb4, IDCODE 0x13636093, 778.7 s, exit 0.
  • The control (board_runs/tern_tc_all_w24_reload.log):
    • setkey was installed and its ack verified on node 0x5452494e;
    • receipts verified (tag) 403,200/403,200, and rows bit-exact 33,792/33,792;
    • exit 0, in 86.17 s at 4,679 answers/s.
  • Checked here against the pre-registration:
    • the log's command is the pre-registered window-24 command, character for character;
    • the flashed bit's sha256 is the pre-registered one;
    • all three PASS conditions hold;
    • there is one run log, so one attempt.
    • The harness file has changed since b1e95f6 only in help text.
    • The pre-registration was committed at 08:31:19Z. That is 49 s after the load began and 18 minutes before the control run started at 08:49:40Z.
  • Weak point 5 gets a status. The bitstream on the board is pinned by its full hash and load log. A local rebuild gives a different payload (99d90a6a against CI's ee75d97b), which is consistent with the two yosys versions.
• Ternary storage search: stopped by its own ruler, no verdict (1f68b92, research/block/TERNARY_STORAGE_VERDICT_2026-09-27.md).
  • The question: does a 27-level element in a 3-trit cell beat MXFP4 E2M1 at equal storage?
  • How it is set up: the search is written as specs/numeric/ternary_storage_search.t27 (10 test blocks, 70 asserts), and its runner's parameters are generated from that spec. The runner must first reproduce three of main's perplexities within 0.01, and it stops if one misses.
  • What happened:
    • BASE was off by 0.0005 and MXFP4 rule B by 0.0044, both within the ruler.
    • TNF4_7 rule B missed by 0.0398 (36.7612 against 36.7214), so the runner stopped.
    • No claim arm ran, so there is no verdict either way, and there was no retry.
    • The suspected cause, library drift on a different machine, is not proven.
  • What stands without a claim arm:
    • TNF4_7 plus the 1/12 code equals E2M1 bit for bit;
    • the storage arithmetic: 101 trits per block against 102, and densely packed MXFP4 needs 86.
  • On the order of events: the commit says the spec was written before any arm ran. The spec, the runner and the results arrived in the same commit, though, and no earlier commit of the spec exists on any branch. So that order is the author's statement, not something git shows.
  • A position survey follows (e1834ee, research/block/TERNARY_POSITION_SURVEY_2026-09-27.md). It is secondary sources, not a measurement:
    • nobody publishes a 27-level ternary element;
    • several binary formats already beat MXFP4;
    • a 3-trit cell holds 4.75 bits, so the fair opponents are 4.5-bit formats.
• Ethernet step E2: a PHY status reader, built and simulated, not flashed (1733ab1).
  • It is an MDIO reader for the board's two KSZ9031 PHYs. It resets them, reads the PHY ID and status, restarts auto-negotiation at 100 Mb/s and prints one UART line per poll. Nothing drives TX.
  • openXC7 build: 848 LUT and 939 FF; post-route Fmax 133.26 MHz on mclk and 174.61 MHz on rxc.
  • Icarus simulation against a KSZ9031 status model: link and no-link PASS at RTL, and the synth_xilinx netlist prints the same UART lines byte for byte.
  • The model and the RTL share one reading of the register map, so the simulation cannot catch a misread datasheet. Flashing waits on the VCCO_16 check and the owner's yes.
• A loss-counting UART diagnostic, pre-registered; no arm has run yet (fba3995, specs/trinet/uart_loss_diag_ax7203.t27).
  • The arms: window 64, then window 24, 2,016,000 jobs each, once. The runner resyncs on the next job whose tag verifies, so one run counts every hole instead of stopping at the first.
  • Predictions, written before the run:
    • if the losses are the 512-byte buffer overrunning, window 24 has no hole and window 64 at least one;
    • the Genesys prior (1 in 189,001 jobs) predicts about 10 events at window 64, and any count from 1 to 30 is unsurprising.
    • The only claim, that window 64 loses more often than window 24, needs an exact binomial test at 1/100.
  • The spec's worked example is the corrected 53-byte Genesys hole.
  • Checked here on fba3995:
    • --self-test passes 9/9. Five injected holes of 16/53/4/59/7 bytes are found at their sizes, and a drop, damage, a lie, a wrong key and a dead node are each classed;
    • uart_loss_diag_from_spec.mjs --check finds the parameters file in step with the spec (7 tests, 20 asserts, 0 failures).
• The baud sweep and the edge test.
  • The 33 requested rates were 5 on the wire (523447c).
  • Both sweep edges sit on the CP2102N divider boundaries (4d90d59).
• Write-ups:
  • FORMATS_ON_BOARD.md (85e0eb7);
  • NODE_ETHERNET_PLAN.md, for moving the job link to the board's Ethernet port (3e00ed6);
  • NODE_TOOLCHAIN_RESTORE.md (27087cb), which also records that the fleet clock figures are adapter bins.

This PR targets trinet-fleet-truth (open PR #355), so its diff contains only this work. The base has been merged in (discover_port.py).

Related Issue

Related to #355. It corrects a claim made in commit 1f131fd.

Specification Link

N/A. These are conformance hosts and a testbench, not generated code.

Changes Made

• Bug Fix: receipts are now verified. A response counts only if its status, nonce (issued once), node id, SipHash-2-4 tag and per-chunk y all check. A row passes only if its chunk sum equals the dot product computed from the int8 weights directly.
• Feature: --all now covers all 7 matrix kinds, including w_down as 27 chunks. New flags:
  • --act int8;
  • --setkey, which installs the key and verifies the ack tag;
  • --emit-requests / --responses, for RTL co-simulation;
  • --synthetic, for tern_tc-shaped weights when no model.bin is present.
• Tests: --self-test checks the harness against a reference cell. It has 8 negative controls, and each one must fail: wrong key, a signed lie, a flipped tag bit, an unissued nonce, another node id, a dropped response, 16 bytes lost mid-stream (the board failure, replayed), and an unkeyed node.
• Fix after the first board run:
  • --window defaults to 24, which keeps answers in flight under the CP2102N's 512-byte buffer.
  • The summary reports the jobs actually written and answers/s (it used to print the jobs planned), plus the longest host pause between reads.
  • A failed read logs its hex, the jobs outstanding and the bytes waiting.
• Documentation: conformance/TERN_TC_LAYER_RECEIPTS.md, with every board run, the controls, the registered buffer test and the byte analysis.

Files Changed

• conformance/tern_tc_layer_ax7203.py: rewritten harness
• formal/tern_tc_layer_rtl_tb.v: plays the harness byte stream through the unchanged trinet_node_core.v + trinet_siphash24.v over UART
• conformance/TERN_TC_LAYER_RECEIPTS.md: what is verified, by what, and how to reproduce it; the board runs
• conformance/board_runs/*.log: raw board logs (checked for the key: 0 hits)
• conformance/gft_zphi_ax7203.py, GFT_ZPHI_ON_THE_NODE.md, TERN_TC_WEAK_POINTS.md, TERN_TC_PRIOR_ART.md: added on the owner's machine (see above)

Golden Chain Checklist

• Spec First / Code Generation: N/A (Python hosts and a Verilog testbench)
• No Manual Edits in var/trinity/output/
• No forbidden files, and no shell scripts

Testing Checklist

• Unit: python3 conformance/tern_tc_layer_ax7203.py --self-test → PASS, all 18 checks, on this machine and on the owner's. A mutant that reports planned jobs as sent fails the new control. gft_zphi_ax7203.py --self-test → PASS. uart_loss_diag_ax7203.py --self-test → PASS, 9/9.
• Integration: RTL co-simulation, Icarus Verilog 12.0 (results below)
• python3 -m pyflakes conformance/tern_tc_layer_ax7203.py → clean. The old file had 5 findings, including siphash24 imported but unused.
• Board:
  • all 42 matrices: 403,200/403,200 receipts verified, 33,792/33,792 rows bit-exact, three times (windows 24 and 26, and the control after the reload);
  • GFTernary × Z[φ], layer 0: 403,200/403,200 receipts, 5,632/5,632 rows;
  • mxdot4 (MXFP4 and TNF4 block dot): 251,616/251,616 bit-exact, with the hashes checked against the pre-run commit.

Test Results

RTL, layer 0, all 7 matrices (synthetic tern_tc-shaped weights)
  receipts verified (tag) : 67200/67200 under node 0x5452494e
  rows bit-exact          : 5632/5632  (activations: ternary)
RTL, layer 5 w_down, int8 activations (6 digit planes)
  receipts verified (tag) : 51840/51840
  rows bit-exact          : 320/320  (activations: int8)
RTL controls
  no setkey frame   -> 0/640 credited, all status 0x04, FAIL
  different key     -> 0/1280 receipts, 0/128 rows, FAIL
Old harness vs a wrong-key cell -> "receipts authenticated 160/160", PASS  (the defect)

AX7203, 2026-09-27, trained model.bin          (answer bytes in flight = 19 x window)
  --all, window 64 (403,200 jobs)     FAIL  18,984 verified, then 16 answer bytes lost
  matvec_demo, window 64 (3,200)      PASS  3200/3200 receipts, 320/320 rows
  w_down int8, window 64 (51,840)     FAIL  9,886 verified, then 4 answer bytes lost
  w_down int8, window 8 (51,840)      PASS  51840/51840 receipts, 320/320 rows, 4,344 jobs/s
  self-test on b1e95f6                PASS  18/18
  --all, window 24 (456 B)            PASS  403200/403200 receipts, 33792/33792 rows,
                                            85.49 s, 4716 answers/s, longest host pause 22.4 ms
  --all, window 64 (1,216 B), control FAIL  6,679 verified, then 59 answer bytes lost
  GFTernary x Z[phi], layer 0, w24    PASS  403200/403200 receipts, 5632/5632 Z[phi] rows (pre-registered)
  --all, window 26 (494 B), registered PASS 403200/403200 receipts, 33792/33792 rows, 85.29 s
  --all, window 30 (570 B), registered FAIL 149,986 verified, then 7 answer bytes lost
  --all, window 24, after the reload  PASS  403200/403200 receipts, 33792/33792 rows, 86.17 s,
                                            4679 answers/s, longest host pause 127.9 ms (pre-registered)
  --all, window 64, own Genesys hub   FAIL  188,936 verified, then 53 answer bytes lost
                                            (answers 0x3e208-0x3e20a; pre-registered prediction: FAIL)

AX7203, 2026-09-27, other formats (owner's runs, checked against their pre-run commits)
  GF8 ADD exhaustive, 154839 baud     PASS  65536/65536 bit-exact, 254 s
  TNF16 add+mul, window 24            PASS  1035886/1035886 bit-exact (fails=0, lost=0), 102.4 s
  mxdot4 MXFP4+TNF4, window 6         PASS  251616/251616 bit-exact (fails=0, lost=0), 178.0 s

Performance Impact

• No change to the hardware. Host cost is about 16 µs of SipHash per job, well below the 210 µs per job at line rate. Measured on the board:
  • about 4,680 to 4,720 answers/s at windows 24 and 26;
  • 4,344 at window 8;
  • about 4,540 to 4,750 at 64 before the slips.

Breaking Changes

• No. The CLI is a superset. Note that --all now means all 42 matrices, and --window defaults to 24. The old 24-matrix set is --mats wq,wo,gate,up.

🔥 TOXIC VERDICT

What Works

• The receipt checks, each shown able to fail.
• The whole tern_tc layer set, including w_down and int8 activations, runs bit-exact through the real RTL.
• On the board:
  • all 42 trained matrices with every one of 403,200 receipts verified, three times: windows 24 and 26, and again after the node was reloaded from the CI artifact;
  • w_down with int8 activations;
  • GFTernary × Z[φ] on layer 0;
  • GF8 ADD exhaustively, TNF16 add and mul, and the MXFP4/TNF4 block dot, each bit-exact against a run registered before it.
• No answer that arrived whole was wrong or badly signed.

What Doesn't Work

• More than 512 bytes of answers in flight on this link: the CP2102N's receive buffer overruns, and the node cannot be held off. Moving the UART to its own hub did not change that.

Known Issues

• SipHash is a shared-key MAC. It authenticates the node to the key holder. It is not publicly verifiable, and it does not stop an operator forging their own receipts.
• A lost frame stops the run rather than resynchronising. This fails safe. The pre-registered loss diagnostic (fba3995) resyncs instead, to count losses; the main harness is unchanged.
• The activation vectors are random test vectors, not the model's real activations, and there is no forward pass.
• The bitstream on the board is the CI artifact. A local rebuild does not reproduce its payload (99d90a6a against ee75d97b), which is consistent with the two yosys versions but not yet explained.
• The ternary storage search could not reproduce one of main's reference perplexities on this machine (TNF4_7 off by 0.0398), so it has no verdict. That drift itself is unexplained.

Toxic Verdict

Overall Assessment: APPROVE. This PR set itself a condition: a board rerun that reproduces 42/42 matrices with every receipt verified. That condition is met. Self-Score: 8/10. Silicon passed, and the link limit is bracketed by a registered test. Real activations are still open.

🌳 TECH TREE Options

Option 1: Real activations

• Description: Dump the int8 inputs from tc_infer for a real prompt and run one full layer with them.
• Complexity: ★★☆☆☆

Option 2: Flow control on the node

• Description: Add RTS/CTS to trinet_node_core.v and the AX7203 constraints, as the CP2102N datasheet asks above 1 Mbaud. Then rerun at window 64.
• Complexity: ★★★☆☆

Option 3: Leave the UART

• Description: Move to Ethernet or a USB FIFO. Measured throughput is UART-bound.
• Complexity: ★★★★☆

Recommendation: Option 1. It turns this from a weights check into a step towards a forward pass. Window 24 already runs at line rate, so Option 2 buys safety margin, not speed.

Deployment Notes

• None.

Reviewer Notes

• The nonce-to-job map is FIRST_JOB_NONCE + index. The setkey frame uses a separate nonce, so its ack can never be credited as work.
• Commits 4601246, 50e8d95, 0bdeab2, 1e2677a, 05d1f8b, bc3015d, 8a20321, 7c35699, d437476 and 09b3d6f were made on the owner's machine. They hold the board logs, the write-ups, the pre-registrations and the survey. So were 523447c, 4d90d59, 27087cb, 3e00ed6, 85e0eb7, 054b1fe, bc40613, aa4511d, cf12a50, 8b98e6c, 4f68a4d, e243f27, 0fdbeb6, c1e7091, cf82eeb, c590308, 1f68b92, e1834ee, 1733ab1 and fba3995.

🤖 Generated with Claude Code

https://claude.ai/code/session_011vMJx1ZWk2hq58jyEecRBY

[gHashTag]

Two commits landed on the owner's machine after the description above was written. Both are in this merge and in main via #355.

The UART loss diagnostic ran as pre-registered (fba3995 → 5a31118, conformance/UART_LOSS_DIAG.md, board_runs/uart_loss_w64.log, uart_loss_w24.log).

• Window 64 (1,216 B in flight): 2,015,426 accepted, 574 lost in 121 events (119 byte holes of 3–417 B, 2 whole frames), 0 wrong y.
• Window 24 (456 B): 2,016,000 accepted, 0 lost, 0 wrong y.
• PRED_BUFFER held. PRED_RATE failed: 121 events against about 10, outside the 1–30 the spec called unsurprising. The events cluster (variance/mean 1.86 per 100,800-job bin), so a Poisson interval is too narrow for them.
• CLAIM_W64_WORSE: yes. P = 3.8e-37 against the 1/100 threshold.
• Both arms took about 425 s, so on this path the request direction bounds the wire, and windows above 26 buy nothing.

Checked here against the pre-registration:

• W64 started at 11:27:26Z and W24 at 11:35:12Z. That is 3 and 11 minutes after fba3995 (11:24:30Z), in the pre-registered order, with one log per arm.
• Both logs name the spec sha256 5d8587dd…, which is the file at fba3995.
• The instrument check holds in both arms: accepted + wrong y + lost + in flight = 2,016,000, the number sent.
• On fba3995, --self-test passes 9/9 and uart_loss_diag_from_spec.mjs --check finds the parameters in step with the spec.
• The key file is not in this container, so the key check is the author's (0 hits). What I could check here: the new logs hold no hex run of key length, and the one 64-hex value is the spec's sha256.

A second trit-cell search is pre-registered (49a84ad, specs/numeric/ternary_storage_search_v2.t27), against NVFP4 and MX+. No arm has run yet.

---

Generated by Claude Code