Inference Receipts

A signed, portable, content-free record of what actually served an LLM request: the model asked for, the model that ran, both prices, and what authorized any difference. One mandatory algorithm, one canonical byte form, a forty-line verifier.

$ node verify/verify.mjs examples/receipt.signed.json examples/issuer-keys.json
OK   example-2026-08 (gateway.example, receipt rcpt_9f2c41d0e6b74a58)

$ node verify/verify.mjs examples/receipt.tampered.json examples/issuer-keys.json
FAIL example-2026-08: signature does not match the canonical payload bytes

The tampered example differs from the valid one by a single digit of the savings figure. That is the entire product: a claim about served inference that a counterparty can check without trusting the party who made it.

The problem

An increasing share of inference is bought through someone else: a gateway, a router, a reseller, an agent framework, another agent. Every intermediary makes after-the-fact claims: this model served you, this is what it cost, this swap was authorized, this much was saved. Today every one of those claims lives in a dashboard owned by the party making it. You can read it. You cannot carry it away, hand it to an auditor, attach it to a dispute, or check it against anything.

The machine-payments world has settlement rails and no proof of what was served. Model substitution incidents keep demonstrating that "which model actually ran" is a real question with real money on it. A receipt is the missing artifact: specific, signed, portable, falsifiable.

What is in this repo

Path	What it is
SPEC.md	The specification: record fields, canonical form (RFC 8785 plus an integers-only profile), Ed25519 envelope, key discovery, verification, threat model.
verify/	Reference verifier. Node built-ins only; the canonicalizer is ~80 lines, the verifier ~40.
examples/	A worked signed receipt, the issuer key file, a tampered copy that must fail, and the script that regenerates all three. The example's arithmetic is internally coherent on purpose: redo it and you are auditing a receipt.

What a receipt looks like

The worked example's payload, abbreviated (id, issued_at, and policy_version elided; the full envelope is in examples/receipt.signed.json):

{
  "receipt": "inference-receipt/0.1",
  "issuer": "gateway.example",
  "request_id": "req_5b8a12c9d3f04e77",
  "requested": { "provider": "openai", "model": "gpt-5.4" },
  "served":    { "provider": "deepseek", "model": "deepseek-v4-flash" },
  "decision": {
    "kind": "substituted",
    "evidence_ref": "https://gateway.example/evidence/cell_classify_v3_2026-08-01"
  },
  "usage": { "input_tokens": 5000, "output_tokens": 800 },
  "money": {
    "currency": "USD", "unit": "micros",
    "served_cost": 4760,
    "counterfactual_cost": 45000, "counterfactual_basis": "requested_model_list_price",
    "savings": 40240, "savings_state": "measured_at_serve",
    "fee": 10060, "fee_basis": "fraction_of_savings_2500bps"
  }
}

Three design rules do the work:

1. Requested vs served is the spine. The contract and the fact, side by side, with decision obligated to explain any gap and to cite the published evidence that authorized it.
2. No naked numbers. Every derived figure carries its basis: what baseline, how settled, what fee rule. An unstated basis is how a savings claim becomes marketing.
3. Content-free by construction. No prompts, no completions, no embeddings. Receipts travel; the format refuses to make that a leak.

What a signature does and does not prove

A valid signature proves the issuer said this, it has not changed, and they cannot take it back. It does not prove the named model actually ran; nothing on paper can. What it changes is the economics: a false receipt is signed evidence against its issuer, checkable against published prices, month-end invoices, re-execution sampling, and the issuer's own other receipts. Dashboards assert nothing signed. The full argument is SPEC.md section 7.

Status and provenance

Extracted from the receipt discipline running in production at Finest, where every gateway serve writes a record with these semantics and customers read them over an authenticated API. The signature envelope is the part specified here first: it is what makes a receipt portable beyond its issuer.

Version 0.1 is a draft and wants adversaries. The most useful contributions, in order: a receipt your system cannot express, a second independent issuer, and an attack on the threat model.

Citing the spec: Inference Receipts v0.1, github.com/finest-ai/inference-receipts, SPEC.md section N. Sections are stable within a version.