Determinism

The compress pipeline is deterministic. Concretely:

• Fixed model weights, loaded once per service generation. The receipt's debug.model_registry names every model that ran.
• No sampling anywhere in the pipeline.
• Batch size and numeric precision are pinned, so the same input bytes and the same parameters produce byte-identical output and a byte-identical receipt. This is checkable by you: replay the same call and compare output hashes.

What this does and does not mean

It means: run the same call twice - today or next month, same engine generation - and you get the same compressed output and the same receipt. An agent can treat its own context compression as a reproducible build step, and a third party can re-run a receipt's claim.

It does not mean: different input texts with the same length produce similar outputs or similar runtimes. Compression is content-driven - a different corpus slice compresses differently, and verified-mode cost scales with the structure of the text (see latency), not with character count alone.

It does not mean: a later engine generation reproduces earlier receipts. The receipt records which models ran; if we upgrade a model, that shows up in model_registry on the new receipts.