Compliance

FRE 902(13) — Electronic records generated by a process

Rule 902(13) makes a record self-authenticating if it was generated by an electronic process producing accurate results, certified by a qualified person. Receipts are structured to satisfy this:

• — Each receipt is generated by deterministic cryptographic code (ES256 JWS over a stable schema). Verification reproduces the result.
• — The signing process can be described in one paragraph: hash the content, sign the hash, countersign with RFC 3161, anchor to Bitcoin.
• — A qualified person (e.g., your CTO, or CertNode's CTO via affidavit) can certify that the system produced this receipt for this content at this time.

No court has ruled specifically on a CertNode receipt's 902(13) admissibility. The underlying primitives (RFC 3161, ECDSA, sha256) are well-precedented; admissibility ultimately is the court's call. Document your verification process so opposing counsel can run it independently — that's the strongest defense.

FRE 902(14) — Electronic records authenticated by digital signature

Rule 902(14) authenticates records via digital signatures from a process producing accurate results. Receipts include:

• — ES256 JWS signature over a payload containing the content hash and signing metadata. Open standard (RFC 7515).
• — RFC 3161 timestamp from an independent Time Stamp Authority. The TSA isn't CertNode — independence cuts the "you signed your own evidence" argument.
• — Optional Bitcoin OpenTimestamps anchor for non-revocable proof-of-existence.

EU AI Act Article 50 — AI content disclosure

Article 50 (in force August 2026) requires AI system providers generating synthetic content (text, image, audio, video) to mark the content as artificially generated in a machine-readable format. CertNode receipts satisfy the marking requirement cryptographically — every signed output carries verifiable model + provider + timestamp metadata.

What this gets you: the machine-readable marker the regulation requires. Receipt + public verify URL = disclosure surface.

What you still need: Article 50 also requires human-perceptible disclosure (e.g., a visible "AI-generated" label) for some content types. CertNode doesn't render UI on your behalf — surface the receipt info on your own product, then point users to the verify URL.

HIPAA-compatible patterns

CertNode does NOT sign Business Associate Agreements. Instead, use the privacy-preserving prompt-hash pattern so PHI never leaves your infrastructure:

• — Hash PHI client-side before signing. The hash is one-way; CertNode receives only the hash, not the underlying content.
• — For the AI output itself, redact PHI before signing OR sign a sealed-content sentinel referenced by salted hashes (see the privacy-preserving recipe).
• — Receipt becomes a binding ledger entry; raw PHI stays in your encrypted storage under your HIPAA controls.

This pattern is defensible because hashes are not "personal data" under HIPAA when the underlying content can't be recovered from them. Salted hashes are stronger still (defeat rainbow-table attacks). Confirm with your HIPAA compliance counsel.

GDPR / CCPA — personal data handling

CertNode stores: receipt UUIDs, content hashes, model/provider strings, timestamps, signatures. CertNode does NOT store: the raw content you sign (only its hash). Implications:

• — Receipts don't contain personal data per GDPR/CCPA when content is hashed before signing.
• — The hash itself is computationally infeasible to reverse — it's not "personal data."
• — If you sign raw content that contains personal data, CertNode stores the hash and metadata. The signed content lives in your infrastructure under your controls.
• — Right-to-be-forgotten: you can stop using a receipt at any time. The receipt itself stays cryptographically valid until you reveal the underlying content (or hash) to a third party.

SOC 2 — current state

CertNode is in SOC 2 Type 1 prep (Vanta integration + 3-month audit calendar). Type 1 report expected within ~3 months of operator commitment. Enterprise customers evaluating procurement should email contact@certnode.io for the current state of the audit + access to in-flight policy docs.

ISO 27001 — current state

Not certified yet. Follow-on to SOC 2 Type 2. Track in the AI Provenance Phase 3 roadmap; not gating any current customer integrations.

Court cases on FRE 902(13)/(14)

Rule 902(13)/(14) were added in 2017 specifically to streamline admissibility of electronic records. Federal courts have admitted records under both rules in criminal + civil cases since enactment. No published opinion has ruled specifically on a CertNode receipt — the rule is too new + the technology too specific for dispositive case law to exist yet.

The defensive argument that holds today: the underlying primitives (RFC 3161, ECDSA P-256, sha256, Bitcoin OpenTimestamps) are standardized + reproducible. An opposing expert can independently verify any CertNode receipt without contacting CertNode. That's the foundation for 902(13) admissibility — "process producing accurate results" + "anyone can audit the process."