A citation attributes credit, enables verification, and chains intellectual dependency. Those functions require material that is stable, retrievable, and independently checkable.
Typical AI outputs fail all three. The text exists at generation time, often without a durable deposit, without a full execution context, and without a cryptographic link between input, model, and output. Institutions respond in kind: publishers bar AI authorship, universities treat undisclosed use as misconduct, journals retract hallucinated references. Detection tools are unreliable enough that regulators such as Australia’s TEQSA have told universities to redesign assessment rather than depend on detectors.
That is not coordinated rejection of a useful tool. It is recognition that current systems produce answers without the metadata verification requires. Better prompts alone do not fix it. The gap is architectural.
Where citations break
Nondeterminism
Determinism means identical inputs produce identical outputs. Typical AI inference is not deterministic: parallel floating-point order varies; sampling is often intentional; hardware, library versions, and batching can still diverge even with fixed seeds. A citation implies a stable referent. An unreproducible output is an assertion about something that once existed.
Execution context
A paper citation points at a fixed artifact. AI outputs usually do not: no repository deposit, no persistent identifier, incomplete recording of model version, system prompt, history, and inference config. Even stored text without that context is a fragment of unknown provenance.
Cryptographic linkage
Traditional citations lean on institutional infrastructure — publishers, repositories, resolvable identifiers. AI outputs rarely bind input, model, and output with a signature, hash chain, or trusted timestamp. Without that, provenance claims are assertions without evidence.
Watermarks
Watermarks answer “was this generated by AI?” They do not answer which input, which model version, which config, or when. They do not enable re-execution. They can be stripped by paraphrase; detectors without watermarks produce false positives; formats remain fragmented. Useful for authenticity questions. Insufficient for citation.
Execution receipts
An execution receipt is a signed record of the conditions under which an output was produced. It supplies the provenance metadata needed for verification — not a claim that the content is true.
Fields
- Input hash — cryptographic hash of the complete computational input (prompt, context, config parameters).
- Model identifier — versioned identity of weights and architecture.
- Configuration state — temperature, sampling, seed if any, system-level constraints active at run time.
- Output hash — hash of the complete model output before post-processing.
- Timestamp — time from a trusted source.
- Signature — signature over the above, produced by the execution environment.
The receipt holds hashes, not full content. Parties with the originals can verify match; parties without cannot reconstruct content from hashes alone.
Hash over the full computational input: user prompt, system instructions, multi-turn history, retrieved context, inference parameters. Output hash covers the full model output before post-processing. Standard collision-resistant hashes (e.g. SHA-256).
The signature binds those fields. Signing keys typically live in an HSM or TEE, with attestation linking the key to known infrastructure. Compromised keys allow forged receipts — key management is part of the trust story, not an afterthought.
Verification by re-execution requires deterministic runs: fixed seeds, deterministic numerical algorithms, controlled parallel order, version-locked weights, tokenizers, and inference code. When that holds, a party with the input can re-run and compare against the receipt. Hardware and library nondeterminism make that property expensive, not automatic.
Provenance is not correctness
With a receipt, a citation can include the output, the receipt, and a commitment to provide input for verification. That resembles experimental reporting: methods described, raw material available on request, replication possible in principle.
Most citations will still be accepted without re-execution. The epistemic change is the possibility of verification — assertion moves toward checkable evidence.
A receipt proves that a stated input produced a stated output under a stated model and config. It does not prove correctness, usefulness, or safety. A consistently wrong model produces valid receipts for wrong outputs.
Limits
Deterministic execution often costs throughput. Version locking constrains ops flexibility. Key compromise breaks the chain. Multi-model and RAG pipelines need receipt composition rules that standards do not fully settle. Institutional acceptance (publishers, regulators) is incomplete. Adversarial robustness of receipt systems remains an open engineering problem.
Traceability rules such as those in the EU AI Act create demand for mechanisms of this kind. Receipts are one design that can meet a provenance requirement. They are not a complete trust stack.
This design proves execution conditions. It does not prove the answer was right. The useful object for review is the answer together with its source, execution record, and review state — not bare text alone.