How do I prove which model version, prompt and settings produced a specific AI output?

What should I check, step by step?

1. Record the model the provider reports in the response, not only the one in your request. OpenAI's chat completion object returns model and, where available, system_fingerprint; Anthropic's Messages response returns model; Gemini's GenerateContentResponse returns modelVersion and responseId. If you requested an alias (for example a -latest name), the reported value is what pins the version.

2. Hash the prompt as sent, not as templated in your code: serialize the full request messages (system prompt, user turns, tool results already in context) plus tool definitions to one byte string and take SHA-256. Keep the bytes; the hash is only useful if you can produce the original.
3. Put every generation setting into one settings object (model requested, temperature, top_p, max tokens, seed, stop sequences, tool_choice, response_format or JSON schema, reasoning or thinking budget) and hash its canonical form with sorted keys, so key order can't change the hash.
4. Hash the exact output bytes you returned to the user or the next step, after any post-processing you apply. If you post-process, record the raw output hash too and say which one is which.
5. Keep the provider's request or response id and created time next to the hashes. They let you or the provider correlate the run later while logs still exist.
6. Record the code version that built the prompt (git commit of the template and any retrieval config). A prompt hash without the template version tells you that something changed, not what.
7. Seal the record once, at return time: sign it and get an independent timestamp, so a record rebuilt after a dispute is distinguishable from one made when the answer came back.
8. Write down the limits next to the record: a caller-reported record can't prove which weights served the request, and seeds are best effort, so a re-run may legitimately differ.

Why 'we used model X' isn't enough

Aliases move. Anthropic's models overview says that for models before the 4.6 generation the short alias points to a dated snapshot ID (from 4.6 on, every ID is a pinned snapshot), and Gemini documents -latest style names that are updated over time. A config file that names an alias doesn't say which version answered on a given day; the model value in the response does.

• Backends change under a fixed ID. OpenAI documents system_fingerprint as the backend configuration fingerprint and tells you to compare it with seed to understand why outputs might differ. Anthropic's September 2025 postmortem describes three infrastructure bugs that degraded some responses for weeks without any model ID change. A record that carries the response-side identifiers is the best you can do from the outside.
• Prompts drift too. Templates, retrieved context, tool schemas and system prompts are edited far more often than model versions. If only the user's question is logged, two outputs with the same 'prompt' can come from very different requests.

What content-addressed means here, and how someone checks it

Each part of the run is identified by the SHA-256 of its exact bytes: prompt_sha256, output_sha256 and a hash of the canonical settings object. The record then carries those hashes plus the model and provider names, and the record itself is hashed and signed.

• A reader with the originals recomputes each hash. If the prompt, settings or output they were given hashes to the recorded value, it is the same content that was recorded; any edit, even whitespace, fails. A reader without the originals learns nothing about the content, so the record can be public while prompts stay private.
• Keep the originals somewhere durable. The record proves a match; it doesn't store the text. Losing the prompt bytes means nobody can ever show which prompt produced the output, even though the hash is on file.

What this proves and what it doesn't

Proves: this exact output was recorded together with this prompt, these settings and this reported model, no later than the signed issued time, and none of it has changed since.

• Doesn't prove: that the provider actually ran the named weights (only the provider can attest that), that the output is correct, or that re-running will reproduce it. For first-hand capture, Rightshold's agreement mode calls the models itself and records what it received.
• For a single answer's timing question (what did the model say on a given day) the shorter guide on proving what a model said at a specific time is enough; this page is about tying the output to the full configuration that produced it.