FRE 902(13) and 902(14) admissibility for AI-generated content

What FRE 902(13) and (14) actually say

Federal Rule of Evidence 902 lists categories of evidence that are self-authenticating, meaning the proponent does not need to call a witness to lay foundation. Subsections (13) and (14) were added in 2017 to address electronic evidence:

• FRE 902(13), A record generated by an electronic process or system that produces an accurate result, as shown by a certification of a qualified person.
• FRE 902(14), Data copied from an electronic device, storage medium, or file, if authenticated by a process of digital identification, as shown by a certification of a qualified person.

Both subsections require advance notice to the adverse party (FRE 902(11) procedure) and an opportunity to challenge the foundation. They lower the procedural bar for admissibility, not the substantive bar for credibility. A judge can still exclude self-authenticating evidence on other grounds (relevance, hearsay, prejudice, authenticity disputes raised in good faith).

Why AI-generated content needs this

AI output without provenance is unstable evidence. The opposing counsel argues:

• "You could have edited the output after generation."
• "You could have changed the prompt or the model after the fact."
• "Your database timestamp is your own claim, there is no third-party witness."
• "How do we know the model produced this and not a human?"

Without independent cryptographic evidence, those arguments are hard to defeat. The court doesn't need to believe the opposing counsel; the court needs the proponent to prove authenticity. If you can't, the evidence may be excluded or weighted down.

How CertNode receipts align

A CertNode receipt produces a record that satisfies the structural requirements of 902(13) and 902(14):

Three-layer cryptographic chain

1. ES256 JWS signature over a canonical payload. Verifiable against CertNode's public JWKS without contacting CertNode. Standard cryptographic primitive (NIST P-256, SHA-256).
2. RFC 3161 timestamp issued by FreeTSA, an independent Time Stamping Authority operating under the established RFC 3161 standard. Verifiable against FreeTSA's CA cert with no CertNode involvement.
3. Bitcoin anchor via OpenTimestamps. Hash committed to a Bitcoin block. Cannot be altered without invalidating the anchor across the entire Bitcoin chain history.

What that gives the court

For 902(13): the system that produces the receipt is well-documented (CertNode's signing pipeline + FreeTSA's TSA + OpenTimestamps' Bitcoin anchor). Each layer is publicly auditable. A qualified person can certify that the system produces accurate timestamps and signatures.

For 902(14): the digital identification process is the cryptographic chain itself. The receipt's signatures are the digital identification. A qualified person can certify the verification procedure (which is publicly documented at /docs/cryptographic-stack).

What a CertNode receipt actually proves

A CertNode receipt establishes:

• Specific content existed at the moment the receipt was issued (timestamp from independent TSA).
• The content has not been modified since (any modification produces a different SHA-256 hash, breaking verification).
• The content was submitted to CertNode by an account holding a specific API key (CertNode internal record).
• The metadata (model, provider, optional prompt hash) was attested by the API key holder at the moment of signing.

What a CertNode receipt does NOT prove

Be honest about the limits. A receipt does not establish:

• That the content was actually generated by the named model. The metadata is attested by the API key holder, not independently verified by the model provider. If the API key holder lies about the model, CertNode cannot detect it. The receipt proves they claimed model X, not model X was used.
• That the content is true, accurate, or non-defamatory. Cryptographic provenance is about authenticity of attribution, not factual content.
• That the API key holder had authority to sign the content. A compromised key produces valid signatures.
• That the prompt was not subsequently modified before storage (unless prompt hash was included at signing time).

Courts will scrutinize each of these. A confident litigation strategy supplements the receipt with operational evidence: model provider invoices showing the API call, logs from the generation pipeline, internal access controls on the API key, and (where required) testimony from the engineer who configured the integration.

Practical retention guidance for legal teams

For each AI-generated artifact you may need to defend:

1. Retain the original output content. CertNode stores the hash, not the content.
2. Retain the receipt ID and the receipt JSON. The verify URL and three-layer timestamp data are part of the chain of custody.
3. Retain operational logs showing the API call to the model provider (Claude, OpenAI, etc.), request, response, time, billing record.
4. Retain documentation of API key access controls (who holds the key, when it was issued, when it last rotated).
5. For high-stakes content (legal advice, medical summaries, regulated communications), include the prompt hash in the receipt at signing time. Then retain the prompt content separately.

Comparable standards outside the US

CertNode's three-layer timestamp design is built to align with multiple standards simultaneously:

• EU eIDAS, qualified electronic timestamps. RFC 3161 from FreeTSA aligns with the underlying technical standard.
• EU AI Act Article 50, machine-readable AI content marking, enforces August 2026.
• ISO/IEC 18014, international time-stamping framework.
• UNCITRAL Model Law on Electronic Signatures, adopted by ~30 jurisdictions.

When to consult counsel

CertNode is an evidentiary tool, not a legal strategy. Engage qualified counsel before relying on receipts in any of these situations:

• Active litigation or anticipated litigation where AI content authenticity is a material question.
• Regulatory inquiries about AI usage (FTC, FDA, FINRA, state AGs).
• Cross-border evidence questions (different jurisdictions weight digital signatures differently).
• Criminal proceedings involving AI-generated content (deepfakes, fraudulent documents, synthetic media).
• Class actions where the AI content is the operative fact.

See also

• The CertNode cryptographic stack (technical docs)
• EU AI Act Article 50 for developers
• AI provenance vs AI detection