How receipts prevent bait-and-switch
The structural problem with discounted inference, and how signed receipts make silent model substitution a provable fraud rather than a suspicion.
The problem
Every discounted inference reseller faces the same suspicion: how do I know you are not quietly serving me something cheaper? Route traffic to a smaller model, a quantized build, or an aggressive cache, and most customers would never notice. Response quality varies naturally, so occasional weak answers prove nothing, and by the time a customer suspects anything, there is no evidence either way. The economics reward exactly this behavior, which is why the suspicion is rational.
Trust-me assurances do not solve a problem whose failure mode is undetectable. Evidence does.
What a receipt commits to
Every Draftworks response carries an Ed25519 signature over a payload containing:
- the model id as the upstream reported it, pinned version included (
gpt-5.6-sol-2026-07-09), - SHA-256 hashes of the exact request bytes you sent and the exact response bytes you received,
- the token counts you were billed for, and the request id.
The full spec covers the field order and the streaming hash rule. The signature is checkable by anyone, forever, against the published public key: in your browser on the verify page, or in four lines of Node.
Why that closes the gap
Substitution requires lying about the model id. With receipts, that lie has to be signed. Every response becomes a permanent, transferable, cryptographically attributable statement: Draftworks claims this exact model produced these exact bytes. One demonstrated false receipt is not a quality dispute, it is documentary evidence of fraud, reproducible by any third party, attached to every single request we ever served. The expected cost of cheating flips from "probably nobody notices" to "one counterexample ends the business."
The receipt also binds the content, not just the label. Because response_sha256 covers the bytes you received, we cannot later dispute what was served, truncate logs, or claim a middlebox altered the response. What you hold is what we signed.
The last mile: verifying the label itself
A receipt proves what we claimed. The remaining question is whether the claim is true, and that is independently checkable: Draftworks forwards logprobs through unmodified, and those distributions are signed into the response bytes. The model verification guide ships an open audit script that compares next-token distributions from Draftworks against the vendor's own endpoint on prompts you choose. Faking that would require making a substitute model emit the real model's exact distributions, which is to say, running the real model.
Receipts make cheating self-documenting; the audit makes it detectable on demand. Together they replace "trust us" with a system where dishonesty is strictly worse for us than honesty.
Verify the model
A runnable statistical test that checks whether Draftworks serves the model it claims, using log-probability fingerprints compared against OpenAI's own endpoint.
Architecture
The serving path in detail — what runs where, how Azure serves the models, and what touches your data on the way through.