The Problem
Traditional AI inference operates on trust. The provider claims the model produced a specific output, and the user must accept this claim without independent verification.
This trust model fails in regulated environments. Government procurement, security clearances, and enterprise compliance demand cryptographic proof, not promises.
The Receipt
An execution receipt is a structured proof artifact. It binds:
- Input tokens (via BLAKE3 digest)
- Routing decisions (adapter selection, MoE gating)
- Model version (immutable reference)
- Output tokens (via BLAKE3 digest)
- Timestamp and execution context
All elements are combined into a cryptographically signed document that can be independently verified.
The Binding Mechanism
Input Digest
input_digest = BLAKE3(canonical_json(input_tokens))The canonical input is hashed. This digest becomes the cryptographic fingerprint of the prompt.
Seed Derivation
exec_seed = HKDF-SHA256(input_digest, model_version, context)The execution seed is derived deterministically. Same input → same seed.
Output Digest
output_digest = BLAKE3(canonical_json(output_tokens))The output is hashed. This digest binds the result to the execution.
Receipt Structure
{
"version": "1.0",
"input_digest": "blake3:...",
"exec_seed": "hkdf:...",
"model_version": "v2.1.3",
"routing_log": [ ... ],
"output_digest": "blake3:...",
"timestamp": "2026-01-20T21:00:00Z",
"signature": "ed25519:..."
}The receipt is signed with the executor’s private key. Any tampering invalidates the signature.
Hostile Verification
A receipt enables verification by parties who do not trust the original executor:
- Verifier obtains the receipt
- Verifier replays inference with the same input and model
- Verifier compares their output digest to the receipt’s output digest
- If digests match, the receipt is valid
No trust required. Pure cryptographic proof.
Token-Level Audit Trails
Basic receipts prove input-output binding. Token-level trails extend this to capture every intermediate decision:
Adapter Routing
Which LoRA was selected? Why? The decision is logged and bound into the receipt.
MoE Gating
Which expert was activated for each token? The routing matrix is recorded.
Quantization
What precision was used for each operation? The choices are documented.
These trails transform the runtime from a black box into an inspectable system.
The Mandate
Regulated deployments require evidence:
Government Procurement
Federal acquisitions demand verifiable audit trails. Receipts provide the evidence required for compliance documentation.
Security Clearances
Classified environments cannot accept “trust me” claims. Cryptographic proof replaces human trust.
Enterprise Compliance
GDPR, HIPAA, and SOC 2 audits require reproducible evidence chains. Receipts bind inference events to cryptographic proofs.
AdapterOS Implementation
AdapterOS generates execution receipts as a first-class primitive:
- BLAKE3 for input/output digests
- HKDF-SHA256 for seed derivation
- Ed25519 for receipt signatures
- Token-level logs for routing accountability
- Canonical JSON for stable serialization
Patent application filed. Under review. Not an issued patent.
Storage and Retrieval
Receipts are stored in an append-only log:
- Immutable: Once written, receipts cannot be modified
- Indexed: Queryable by input digest, timestamp, or model version
- Distributed: Can be replicated for redundancy
Third parties can request receipts for any historical inference and verify them independently.
Performance Impact
Receipt generation adds overhead:
- BLAKE3 hashing: ~1-5ms per inference
- Signature generation: ~0.1ms
- Log append: ~0.5ms
Total overhead: <10ms for most inference tasks. Negligible compared to model execution time.
The Chain of Custody
Receipts create a chain of custody for AI outputs:
- Input received (timestamped)
- Receipt generated (signed)
- Output delivered (bound to receipt)
If an output is disputed, the receipt provides cryptographic proof of what the model actually produced.
Future Work
Potential extensions:
- Multi-party receipts (co-signed by multiple validators)
- Zero-knowledge proofs (verify without revealing inputs)
- Hardware attestation (bind receipts to secure enclaves)
References
- BLAKE3: https://github.com/BLAKE3-team/BLAKE3
- HKDF: RFC 5869
- Ed25519: RFC 8032
This is a canonical research note. For an interactive visualization, see ai.jkca.me/verification.