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

  1. Build a census version of the decode that uses the non-conforming multiplication order.
  2. Run SmolLM2-135M on 'Once upon a time' for 16 tokens.
  3. 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

  1. 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
  2. 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
  3. R3The alternate order moved the witness digest.

    CENSUS witness_digest_moved=true

    Verbatim source cis2-spec / E25_RMSNORM_ASSOCIATION.md
  4. 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

Positive

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

Read the page and the CHANGELOG erratum E-1 (links above).