Practical Outcomes

You can defend AI outputs in audit, legal, and quality review with provenance evidence.
You can reduce rework in regulated workflows by attaching verifiable execution records.
You can support independent replay and verification when disputes occur.
You can archive outputs with evidence that remains useful over time.

Problem Statement

Academic and policy institutions are increasingly unwilling to accept AI-generated material as citable evidence. The reasons are structural, not merely procedural: AI outputs lack the properties that citations require.

A citation serves multiple functions. It attributes credit. It enables verification. It establishes a chain of intellectual dependency. For these functions to work, the cited material must be stable, retrievable, and independently verifiable. AI outputs, as currently produced, satisfy none of these requirements.

The consequences are visible across domains. Publishers prohibit AI authorship. Universities treat undisclosed AI use as misconduct. Journals retract papers containing fabricated AI-generated references. Research indicates that AI models fabricate between 18% and 69% of their citations, depending on model and topic. A 2024 analysis found that conference submissions reviewed by multiple peer experts still contained hallucinated references that went undetected. AI detection tools have proven equally unreliable: Australia's higher education regulator TEQSA advised universities to redesign assessments rather than depend on detection, warning that AI-assisted work is "all but impossible" to detect consistently.

These responses are not coordinated rejection of a useful technology. They reflect the same issue: AI outputs do not meet the evidentiary standards citations assume. Better prompts and better models alone do not solve this. The problem is architectural. Current systems produce outputs without the metadata needed to verify how those outputs were produced. Without verifiable provenance, AI outputs cannot function as evidence.

Why Citations Are Failing

The failure of AI citations has three technical causes. Each must be addressed for AI outputs to become citable.

Nondeterminism

Determinism means that identical inputs produce identical outputs. AI inference, as typically implemented, is not deterministic.

The sources of nondeterminism are multiple. Floating-point arithmetic on parallel hardware produces results that depend on execution order, which varies between runs. Many language models use stochastic decoding, where randomness is intentionally introduced to improve output quality. Temperature settings, top-k sampling, and nucleus sampling all introduce controlled randomness. Even with fixed random seeds, different hardware, library versions, or batch sizes can produce different outputs.

This matters for citation because a citation implies retrievability. If a reader cannot retrieve the same content from the same source, the citation fails its verification function. An AI output that cannot be reproduced is not a stable referent. It is an assertion about what once existed.

No Stable Execution Context

A citation traditionally points to a fixed artifact: a published paper, a book edition, a dataset version. The artifact exists independently of the act of citing it.

AI outputs have no comparable stability. The output exists only in the moment of generation. It is not deposited in a repository. It has no persistent identifier. The execution context—the model version, the system prompt, the conversation history, the inference configuration—is typically not recorded.

Even if the output were stored, the execution context necessary to interpret it would be missing. The meaning of an AI output depends on what was asked, in what order, with what constraints. Without this context, the output is an isolated text fragment whose provenance is unknown.

No Cryptographic Linkage

Trust in citations rests on institutional infrastructure: publishers that verify submissions, repositories that maintain versions, identifiers that resolve to stable locations. This infrastructure establishes provenance through institutional accountability.

AI outputs lack equivalent infrastructure. There is no cryptographic linkage between the input, the model, and the output. There is no attestation that a particular input produced a particular output using a particular model at a particular time. There is no hash, no signature, no timestamp from a trusted source.

Without cryptographic linkage, claims about AI provenance are assertions without evidence. A user can claim they asked a particular question and received a particular answer. They cannot prove it.

Why Watermarks Are Insufficient

Watermarking has been proposed as a solution to AI provenance. The approach deserves evaluation, but it addresses a related and distinct problem.

A watermark embeds a signal in content that indicates its origin. For AI-generated text, watermarks typically modify the statistical distribution of token choices in ways that are detectable but not obvious to readers. The purpose is to answer the question: "Was this content generated by AI?" When watermarks work correctly, they enable detection of AI-generated material even after modification.

But watermarks indicate origin, not provenance. A watermark can establish that content came from an AI system. It cannot establish what input produced that content, which model version was used, what configuration parameters were active, or when the generation occurred. It cannot enable reproduction of the generation process. The distinction matters: for a citation to function, a reader must be able to verify the cited claim by examining the source. A watermark confirms that content is AI-generated but provides no path to verification.

Watermarking also faces practical constraints that limit its applicability. Text watermarks are vulnerable to removal through paraphrasing. Detection tools that do not rely on watermarks have proven unreliable, leading to false charges of plagiarism. Standards remain fragmented—a watermark created by one system may not be readable by another. And adoption remains limited: only 38% of AI image generators implement adequate watermarking practices. Watermarking addresses an important problem—authenticating AI-generated content—but it does not address the provenance problem that prevents AI outputs from functioning as citations.

Execution Receipts

An execution receipt is a cryptographically signed record that attests to the conditions under which an AI output was produced. It provides the provenance metadata necessary to make AI outputs verifiable and, therefore, citable.

Definition

An execution receipt is a data structure containing:

Input hash: A cryptographic hash of the complete input to the AI system, including the prompt, any context, and configuration parameters.
Model identifier: A versioned identifier for the model used, sufficient to identify the exact weights and architecture.
Configuration state: The inference parameters active at execution time, including temperature, sampling method, random seed if applicable, and any system-level constraints.
Output hash: A cryptographic hash of the complete output produced by the model.
Timestamp: A timestamp from a trusted time source, establishing when the execution occurred.
Signature: A cryptographic signature over the above fields, produced by the execution environment, attesting that the stated input produced the stated output using the stated model at the stated time.

The receipt does not contain the full input or output. It contains hashes that allow verification without disclosure. A party holding the original input and output can verify that they match the hashes in the receipt. A party without access cannot reconstruct the content from the hashes.

What Is Hashed

The hashing function operates over the complete computational input. For a language model interaction, this includes:

The user prompt in its exact form
Any system prompt or instruction set
Conversation history if the interaction is multi-turn
Retrieved context if the system uses retrieval augmentation
All inference parameters

The output hash covers the complete model output before any post-processing.

The hashes are computed using standard cryptographic hash functions (e.g., SHA-256) that are collision-resistant: it is computationally infeasible to find two different inputs that produce the same hash.

What Is Signed

The signature binds together the input hash, output hash, model identifier, configuration, and timestamp into a single verifiable attestation.

The signature is produced by the execution environment—the system that runs the inference. This requires that the execution environment has access to a signing key and that the key's provenance can be established.

In a deployed system, the signing key might be held in a hardware security module (HSM) or trusted execution environment (TEE). The key's association with a particular execution environment can be established through attestation chains that link the key to known, auditable infrastructure.

Determinism and Replayability

For execution receipts to enable verification, the execution must be reproducible. Given the same input and configuration, the same model must produce the same output.

This requires deterministic execution. The sources of nondeterminism described earlier—floating-point variance, stochastic decoding, hardware differences—must be controlled or eliminated.

Deterministic execution is achievable but not automatic. It requires:

Fixed random seeds for any stochastic operations
Deterministic algorithm selection in numerical libraries
Controlled execution order for parallel operations
Version-locked model weights, tokenizers, and inference code

When deterministic execution is achieved, any party with access to the input can independently verify the output by re-executing the inference. The execution receipt provides the reference against which re-execution results can be compared.

Execution Receipts as Evidence

With an execution receipt, the semantics of AI citation change. A citation can include:

The output being cited
The execution receipt attesting to the output's provenance
A commitment to provide the input for verification upon request

This structure mirrors how experimental evidence is cited in science. A paper reports results and describes methods. Reviewers can request raw data. Replication attempts can verify the methodology.

The execution receipt establishes that a particular input produced a particular output. The receipt is independently verifiable. Any party with access to the input can re-execute and compare results.

This does not mean that all AI citations require re-execution. Most citations are accepted on trust, as they are in experimental science. But the possibility of verification changes the epistemic status of the claim. It moves from bare assertion toward verifiable evidence.

Limitations and Open Questions

Execution receipts address specific problems in AI provenance. They do not solve all problems related to AI trustworthiness. The following limitations should be clearly understood.

Receipts Attest to Execution, Not Correctness

An execution receipt proves that a particular input produced a particular output. It does not prove that the output is correct, useful, or safe.

A model that consistently produces incorrect outputs will produce receipts for those incorrect outputs. The receipt attests to provenance, not quality. Verification confirms that the claimed execution occurred; it does not validate the content.

Deterministic Execution Has Costs

Achieving deterministic execution typically requires performance tradeoffs. Deterministic algorithms may be slower than their nondeterministic counterparts. Single-threaded execution forfeits parallelism benefits. Version-locking constrains deployment flexibility.

The tradeoffs are application-specific. Some contexts justify the costs; others do not. Execution receipts are most valuable where verification requirements are high enough to warrant the overhead.

Key Management and Infrastructure

The trustworthiness of a signature depends on the trustworthiness of the signing key. If the signing key is compromised, forged receipts become possible. Hardware security modules, trusted execution environments, and attestation protocols provide partial solutions, but comprehensive key management for AI execution environments remains an emerging problem.

Execution receipts also require infrastructure that does not currently exist at scale. Model providers must generate receipts. Verification services must validate them. Citation standards must accommodate receipt metadata. Institutions must update policies. This is a coordination problem as much as a technical one.

Open Questions

Several questions remain open:

Standards convergence: Will a single receipt format emerge, or will fragmentation persist?
Multi-model pipelines: How should receipts handle outputs that involve multiple models or retrieval-augmented generation?
Institutional acceptance: Will academic publishers and regulatory bodies accept receipts as evidence of provenance?
Adversarial robustness: How resistant are receipt systems to sophisticated attacks?

These questions require further work. This document describes the concept and its potential; it does not claim to have resolved all implementation challenges.

Current State and Next Steps

AI citations fail under scrutiny because they lack verifiable provenance. Outputs are nondeterministic, execution context is often unrecorded, and there is no cryptographic linkage between input, model, and output. Watermarks address authenticity, not provenance.

Execution receipts provide a path forward. By recording execution conditions and signing the record, receipts create a verifiable chain from input to output. Any party with access to the input can re-execute and compare.

This changes the status of AI outputs. They become evidence that can be cited, verified, and audited, reducing reliance on trust alone.

The infrastructure does not yet exist at scale. Standards are still developing. Institutional acceptance is still incomplete. But the technical components are understood, and the need is documented. The EU AI Act already mandates traceability for high-risk AI systems; execution receipts provide a mechanism that can satisfy those requirements.

Execution receipts do not solve all problems with AI trustworthiness. They solve one problem: the absence of verifiable provenance. Model providers should implement receipt generation. Standards bodies should define interoperable formats. Publishers should specify receipt requirements for AI-assisted submissions. These are tractable engineering and policy problems. The alternative—continuing to treat AI outputs as fundamentally uncitable—constrains their legitimate use without meaningfully reducing their misuse.

Execution Receipts and the Problem of Citable AI