1. The question

Every practical form of working-state compression in the AI ecosystem today is lossy: it changes the numbers the model computes with, and therefore can change the answers the model gives. For a chatbot that may be acceptable. For a system whose retained state is meant to serve as the record of what the model considered, it is not. The record must be the state, not an approximation of it.

Revyzor's lossless mode reconstructs the working state exactly, checked layer by layer at capture. But a byte-level check is an engineering claim. The question a buyer actually asks is behavioural:

Across hundreds of real questions, does the model with Revyzor in the path give the same answers as the model without it?

For regulated use, "almost always" is not an answer. So we measured it, repeatedly, across configurations chosen to stress the claim from different directions.

2. The setup

Each run uses five tasks from LegalBench, the standard legal reasoning benchmark: corporate lobbying classification, two supply-chain disclosure tasks, merger-agreement consideration typing (MAUD), and insurance policy interpretation. 100 questions per task, 500 per run, deterministic decoding, exact-match scoring against the published gold labels.

Every configuration is run twice: once as a plain baseline, once with Revyzor's lossless compression active on every layer of the working state for every question. Nothing else changes: same weights, same prompts, same engine version, same GPU class. Any difference between the two columns is therefore attributable to the compression path or to the serving engine's own run-to-run variation, and we distinguish the two below.

We tested across three axes:

• Model family: Qwen2.5-7B-Instruct and Gemma 4 31B, two unrelated architectures.
• Precision: Gemma 4 was run both 4-bit quantised and at full precision (bf16, the official published weights).
• Workload: single-shot answers, and a harder multi-step mode in which the model chains extract, map, and conclude steps per question, so any divergence compounds across steps.

3. The results

Configuration	Answers unchanged with Revyzor	Benchmark score (both arms)
Qwen2.5-7B, full precision, single-shot	498–499 / 500	~371 / 500
Gemma 4 31B, 4-bit quantised, single-shot	499 / 500	384–385 / 500
Gemma 4 31B, full precision, single-shot	500 / 500	385 / 500
Gemma 4 31B, multi-step reasoning (200 chained answers)	199–200 / 200	task-dependent

"Answers unchanged" compares the raw generated answer, question by question, between the baseline arm and the Revyzor arm of the same run. Full-precision Gemma 4: all 500 raw answers identical, and identical scores on all five tasks, including 100/100 on MAUD in both arms.

What about the 1–2 answers that differed?

Three configurations show one or two differing answers. We investigated each one rather than rounding them away:

• Every differing answer sits on a near-tie between two labels, the kind of question where the model's top two choices are almost equally weighted.
• The differences go in both directions: sometimes the Revyzor arm scores the point, sometimes the baseline arm does.
• In every affected run, Revyzor's per-layer checks recorded exact reconstruction on every layer of every question, including the questions whose answers differed.
• The serving engine itself is not run-to-run deterministic under batched scheduling: the same arm, rerun, shows the same order of variation with no compression involved.

The conclusion we draw, and invite others to test: the residual variation is serving-engine scheduling noise, not compression. Where conditions removed the near-ties (the full-precision 31B run), the variation went to zero.

4. The pattern

Two trends run through the table, and both point the same way.

First, parity tightened as the model got bigger and more precise. The strongest configuration, the largest model at full precision, is the one where all 500 answers matched. This matters because it is exactly the configuration regulated deployments run: full-precision weights, nothing lossy anywhere in the stack. The compression ratio in that configuration was 1.45×, with per-layer handling in the 11–22 millisecond range, inline with serving.

Second, the hardest workload held. Multi-step chained reasoning is the stress case: the model's own intermediate outputs become inputs to later steps, so any perturbation has hundreds of opportunities to compound. Across 200 chained answers per run, the two arms matched 199–200 times, with one run matching perfectly on all 200. Retention held on precisely the workload, long recursive reasoning, that retention exists to serve.

Accuracy and assurance scaled together. The bigger and more precise the model, the higher the benchmark score, and the tighter the parity. There is no trade to manage.

5. What we do not claim

A results note is only as credible as its stated limits. Ours are these:

• Absolute scores reflect the models, not Revyzor. A 7B model scores lower than a 31B model on legal reasoning. Revyzor changes neither; parity is the claim, not the scores.
• One benchmark family. All figures here come from LegalBench tasks. We chose legal reasoning because it is our first published domain; the architecture is domain-general, but these numbers are not evidence for other domains.
• In-session compression is what these runs demonstrate. Every answer in the Revyzor arm was generated from state that had been compressed and reconstructed in place, on every layer. Suspend-and-resume across sessions is measured separately (a 5,097-token session reloads in 56.2 ms against 417 to re-read it, on Qwen2.5-7B in bf16 on an L40S) and is not what the 500/500 figure refers to.
• Engine noise exists either way. The 1–2 answer variation in some runs is a property of batched serving, present with or without Revyzor. We report it rather than hiding it, because a buyer will find it anyway.

Full methodology, per-task tables, raw answer files, and the rerun recipe are available under NDA.