Aefinity AI

L11 Mixed Q3 · Silent weight changes

Continuous validation: does a one-byte corruption get caught, and what hides it?

QuestionIf one byte of a deployed model file changes, will a monitoring check actually report it?

Run by us; no unaffiliated reproduction

01Why it matters

A monitor that quietly repairs what it was meant to report is worse than no monitor.

02Method, step by step

  1. Run the self-check twice by hand, about 6.5 minutes apart.
  2. Overwrite one byte of model.safetensors on purpose and run the verifier on it.
  3. Restore the files and run the monitor script twice by hand.
  4. Re-run on a fresh clone on 2026-10-01.

Method as recorded

By hand on one host (Intel i5-10210U, no GPU, ChromeOS Crostini): two self-checks about 6.5 minutes apart, one byte of model.safetensors overwritten on purpose (0xff at offset 1,000,000), the verifier run directly on the corrupted file, then the files restored and the monitor script run twice by hand (about 11 minutes apart, clean files only). No scheduler. A re-run on a fresh clone at commit 205b024 on 2026-10-01 reproduced the monitor PASS and the corruption FATAL. Run by us.

03Results, exact and sourced

  1. R1Two baseline runs matched.

    **Phase 1 result: PASS** — two hand-started runs, about 6.5 minutes apart on one host, produced matching digests (n=2, same host, same day).

    Verbatim source cis2-spec / 2026-09-27-CONTINUOUS-VALIDATION.md

  2. R2A one-byte weight change was stopped by the sha256 hash pin in the verifier before the forward pass ran.

    CIS2_VERIFY3 FATAL: model.safetensors sha256 mismatch,

    Verbatim source cis2-spec / 2026-09-27-CONTINUOUS-VALIDATION.md

  3. R3Negative finding: the self-check's fetch step detects the mismatch but re-downloads the pinned weights, so the monitor (which wraps the self-check) would likely log PASS and mask the corruption. This was inferred from the earlier self-check run on the corrupted file; the monitor itself was not run on corrupted weights.

    repairs corrupted weights silently and would likely log PASS, masking the corruption in monitor mode

    Verbatim source cis2-spec / 2026-09-27-CONTINUOUS-VALIDATION.md

  4. R4The monitor's FAIL path was never exercised.

    The monitor script was not run against corrupted weights, so its FAIL path was not exercised in this experiment.

    Verbatim source cis2-spec / 2026-09-27-CONTINUOUS-VALIDATION.md

  5. R5A flaw in our own monitor script was disclosed: the logged 'digest_hint' was really a test-binary name suffix (script since changed to parse the witness digest line, or print unknown).

    is not a model or output digest. It is the suffix of the cargo test binary name

    Verbatim source cis2-spec / 2026-09-27-CONTINUOUS-VALIDATION.md

04What it does NOT show

That continuous validation works as a deployed service. There was no scheduler, n=2, one host, and the monitor was never run on corrupted weights.

05Scope and caveats

  • Shows only that the file-hash gate works; the corrupted run never reached the forward pass, so this is no new evidence about logit digests.
  • config.json, tokenizer.json, tampered pins/EXPECTED_DIGESTS.md and a tampered verifier binary were not tested.
  • n=2 on one host, no scheduler, hand-run; the document says it is not an operational continuous-validation deployment. Scheduled operation, multi-host and long-horizon data not shown.
  • The monitor PASS only means the self-check matched this repository's own EXPECTED_DIGESTS.md; the document calls it a consistency check, not an independent one.
  • The 2026-10-01 re-run was by us; the source calls it 'independent' but no outside party is named, so no unaffiliated reproduction. The 09-27 run times and the second baseline run could not be re-checked.
  • The document says wiring the monitor to cron and disabling the fetch self-repair in monitor mode would be needed before FAIL could serve as an incident signal.

06Outcome

Mixed

Some parts held, some did not, or we corrected ourselves.

07What we learned

The hash gate catches a one-byte change. But a convenience feature, the automatic re-download, would likely hide exactly the corruption a monitor exists to report (inferred, not run on corrupted input).

08Check it yourself

Read the result page. The repository's self-check commands are above under CIS-2.

  • L06
    Positive

    One flipped bit in the weights: which checks notice?

    In the larger run, among the 247 trials where the output actually changed, the text-replay column missed 182 and the top-k/receipt-style check missed 82. Some flips (43) changed nothing in the computation. A check on the computation itself is by definition silent only on flips that changed nothing, but that 0/247 is true by construction, so the informative finding is how often the weaker checks miss. Single prompt and model, harness-chosen flips, no adversary.

    Q3

  • L07
    Positive

    Realistic edits to the embedding table, including one hidden row

    Output checks are only as good as the prompts you test with. One edited row that no prompt read was missed by text replay and by the top-5 check in 40 of 40 trials, while a check over the computation caught all 40. Even when prompts did read the edited row, those output checks caught only 11 and 21 of 40.

    Q3

  • L10
    Mixed

    What receipts cost on a real agent episode

    Receipts are not free. In this episode the receipt loop took 2.51x the plain decode, and the source calls that an upper bound. On old hardware, verification took 40 s on the i5-5200U machine and minutes on the Celeron N4020. The cost should be reported next to every integrity claim. These are single runs, not a benchmark.

    Q4