L15 Positive Q6 · Do our tests test anything
E25: the RMSNorm multiply order matters, and our spec sentence saying otherwise was false
QuestionDoes a tiny change in the order of multiplication change the AI's internal numbers, even when the output text stays the same?
Run by us; no unaffiliated reproduction
01Why it matters
If text matches while the bits differ, comparing output text cannot show that two systems computed the same thing.
02Method, step by step
- Build a census version of the decode that uses the non-conforming multiplication order.
- Run SmolLM2-135M on 'Once upon a time' for 16 tokens.
- Count elements that differ, and check whether the digest and the tokens moved.
Method as recorded
Scalar witnesses, a unit test of the real function, and a census build running the pinned decode in the non-conforming order on SmolLM2-135M (prompt "Once upon a time", 16 generated tokens), one host (a Debian 13 Crostini VM on ChromeOS, x86_64; no timing reported). Run by us; recorded as erratum E-1.
03Results, exact and sourced
-
R1The spec's earlier claim that no divergence had been observed was wrong.
That sentence is false as of 2026-09-09.
Verbatim source cis2-spec / E25_RMSNORM_ASSOCIATION.md -
R234.60% of RMSNorm elements in one 16-token decode differ between the two orders (SmolLM2-135M).
231,014 of 667,584 RMSNorm elements — 34.60% — distinguish the two orders in a single 16-token decode.
Verbatim source cis2-spec / E25_RMSNORM_ASSOCIATION.md -
R3The alternate order moved the witness digest.
CENSUS witness_digest_moved=true
Verbatim source cis2-spec / E25_RMSNORM_ASSOCIATION.md -
R4In the same run, the generated tokens did not change (for this 16-token vector only).
CENSUS argmax_digest_moved=false
Verbatim source cis2-spec / E25_RMSNORM_ASSOCIATION.md
04What it does NOT show
That tokens never change: a longer decode might compound the differences, and this was not tested.
05Scope and caveats
- The false sentence had already been shown false by E22 and was not updated until E25.
- The SmolLM2-135M result is one pinned vector; the census build is an instrument, not a conforming verifier. The document also reports a second model (Qwen2.5-0.5B) census, and the CHANGELOG E-1 addendum gives its counts; the entry's figures here are SmolLM2 only.
- The source states tokens_moved=false is a fact about this 16-token vector, not a guarantee: a longer decode could compound one-ULP differences into a different argmax. E25 does not test that.
- An earlier draft reported a raw counter (1,335,168) without noting a double decode; corrected in the document.
- Run by us on one host; no unaffiliated reproduction.
06Outcome
The check worked as expected, within the stated scope.
07What we learned
A reordering that leaves the generated text unchanged (on this short vector) still changes the bits, so comparing text is not enough. A published limitation was out of date, and we corrected it in the open.
08Check it yourself
- cis2-spec / E25_RMSNORM_ASSOCIATION.mdhttps://github.com/Aefinity-AI/cis2-spec/blob/main/docs/E25_RMSNORM_ASSOCIATION.md
- cis2-spec / CHANGELOG.mdhttps://github.com/Aefinity-AI/cis2-spec/blob/main/CHANGELOG.md
Read the page and the CHANGELOG erratum E-1 (links above).