Evidence and reproducibility
Results you can inspect, test and replay. Not merely generate.
If a model's output ever has to be defended, a log is not enough. You need to show which model file, which adapter, which binary, which seed and which exact bytes, and a way for someone who was not in the room to check. Runner writes that record for every recorded run and every trained adapter, signs it, chains it, and ships the verifier in the same binary.
The practical benefit first
Three things a receipt lets you do that a log does not.
Prove what the model said
A recorded run carries the prompt and output token ids and the exact streamed output bytes. Replay it on the same binary and the verifier reports VERIFIED, DIVERGED at a named token or byte, or UNVERIFIABLE. One exit code, so a script or a CI job can act on it.
Prove what it learned from
Every adapter is written with a sidecar recording the base, data and adapter sha256, the seed, the full configuration, and the binary sha, compiler, OS and architecture that produced it. Same inputs on the same build reproduce the same adapter file byte for byte, gated in CI. Quantize and merge steps write the same kind of signed record, each linking the records of its inputs, and runner --lineage walks a model file, or a served answer's receipt, back to the download it started from.
Prove what you actually shipped
The loaded GGUF can be verified against an OpenSSF Model Signing bundle before it serves a token. Receipts chain to the previous receipt, so a sequence of runs is a sequence, not a pile.
How it works
Record, sign, chain, verify.
All of it is flags on the same binary that serves the model. No sidecar service, no database.
--transcript FILE writes a one-shot run as a record: model, adapter and binary hashes, the effective execution profile, the exact seed and sampling configuration, prompt and output token ids, and the raw streamed bytes. Raw bytes are authoritative because a byte-token piece need not be valid UTF-8; a readable JSON string travels beside them.--keygen makes an Ed25519 key you hold (or an ML-DSA-44 post-quantum key with --keygen-algo). --sign-key signs each receipt; --transcript-prev links it to the previous one so tampering with any link breaks the chain after it.--receipts DIR on a server writes the same record for every finished generation, chained in write order across restarts and signed when a key is given; each response names its receipt. The record also names the measured envelope the model loaded under and what shaped the output beyond the sampler, such as a JSON schema by digest.--verify FILE replays the record and exits 0 for VERIFIED, 2 for DIVERGED at a token or output byte, 3 for UNVERIFIABLE (invalid record or an artifact whose hash does not match).--export-pack DIR --pack-out PACK gathers a server's receipts, the model signature and key, the envelope manifest and any attachments, such as approval records, into one evidence pack. --check-pack PACK verifies all of it offline and states whether the receipts form one unbroken segment of the chain, so a receipt left out between two others shows.# record a run, signed and chained to the previous one
./runner -m model.gguf --lora adapter.gguf -p "..." \
--transcript run-2.json --transcript-prev run-1.json --sign-key my.key
# replay it later, anywhere: exit code 0, 2 or 3
./runner -m model.gguf --verify run-2.json; echo $?
# refuse to serve a model whose signature bundle does not verify
./runner -m model.gguf --model-sig model.sig --model-pubkey signer.pub --serve
# a server that writes a signed receipt per request, then a pack for a reviewer
./runner -m model.gguf --serve --receipts receipts/ --sign-key my.key
./runner --export-pack receipts/ --pack-out pack/
./runner --check-pack pack/; echo $?scripts/audit-demo.sh runs the whole chain in under a minute on an 8 GB Mac: a signed 1,000-token sampled run, a replay that trusts only the signer's public key, and three forgeries refused. docs/audit-demo.md.
Flag rows for --transcript, --verify, --keygen, --sign-key, --transcript-prev, --model-sig and --model-pubkey are in the command-line reference. The signing code is the TweetNaCl Ed25519 subset, vendored as src/ed25519.c.
Same executable, same inputs, same sampled tokens. One binary, one model file, one config and seed: emitted token ids are identical across runs and across thread counts. Exercised by the test suite on every change.
Training byte-determinism, same build. --train with identical inputs reproduces the same adapter file, byte for byte, verified by sha256 in CI.
Quantization determinism. --quantize and --merge-lora write the same output bytes for the same inputs on the same build.
T1, same binary: bit-exact replay; verified token ids and raw streamed bytes equal the record exactly. T2, cross-ISA: token-level replay on another machine or architecture; token ids must match, floating-point internals may not, and the boundary is libm.
Independent rebuilds are not byte-identical. A different compiler, version or ISA legitimately produces a different floating-point sequence. Cross-build verification is what the T2 token tier is for.
Cross-engine identity is not promised. Adapter files interoperate, measured; token streams do not.
Numerical identity of hidden states is never promised. The contract is about emitted tokens and written artifacts, not intermediate activations.
Timing, memory footprint and throughput are not part of the contract.
The claim boundary
Deterministic, with named edges.
The boundary follows what a single binary controls. Inside one executable the instruction sequence is fixed, so accumulation order and math-library behavior are fixed, and byte-identity is enforceable. Across builds, libm and codegen legitimately differ, so the honest cross-build claim is token identity under replay, which is what --verify implements.
Page titles elsewhere say "deterministic". The claim Runner makes is the narrower one: reproducible on the same build, and receipted so a later reader can check what ran. Claims stronger than the mechanism can enforce would eventually be false somewhere, and the project would rather have a narrower promise that is always true. Full text: docs/determinism-scope.md.
Measured
What has been checked, by whom, and where.
The public adapter was produced twice
Qwen3-4B-Runner-ToolUse-Q4_K_M was trained in two independent runs with the same sha256 on the adapter file, measured 2026-08-22. Its card carries the sidecar and the training command, so the third run can be yours.
An external reproduction on a Tesla T4
An independent reproduction posted on the Hugging Face forum on 2026-08-23 confirmed the claim on hardware the project never touched, including the GPU-assisted backward on a Tesla T4: identical adapter sha256 and loss, CPU vs GPU, byte for byte. The same report contributed a finding the project had not measured: rebuilding from source under a different ISA profile changes the adapter bytes while behavior is essentially unchanged. That finding is why the rebuild edge is written into the scope. Write-up: docs/adaptation-engine.md.
Blocking-independence by construction
Every f32 dot tail is an explicit fmaf, which has exactly one admissible result, and a CI leg pins the SIMD gates at x86-64-v3 and v4. The numerical route and its current verification requirements are documented in the performance reference.
Second device family as a gate
A release requires a CUDA smoke gate on real hardware, because GitHub runners have no GPU and the CUDA backend is compiled on three platforms and executed by none of them. Its assertions are invariants rather than expected constants, so one script covers a desktop card, a datacenter card and a unified-memory device. Compatibility reports that executed no check at all are refused by the release check.