Every paid FidesBeacon deliverable is sealed with an RFC 3161 cryptographic timestamp from a third-party Time-Stamping Authority. The mechanism is older than the AI moment, well established in financial and regulatory practice, and almost never applied to litigation work product. It should be. This is what RFC 3161 does, why it matters in a case file, and how to make use of it when authentication or chain-of-custody questions arise.
What RFC 3161 is
RFC 3161 is the Internet Engineering Task Force's Time-Stamp Protocol — a published standard for proving that a particular digital document existed in a particular form at a particular instant. The mechanism is straightforward. A SHA-256 hash of the document is computed; the hash is sent to a Time-Stamping Authority over HTTPS; the TSA signs the hash with its private key and returns a timestamp token that includes the hash, the time, and the TSA's signature. Anyone who later has the document and the token can verify two things: that the document existed in exactly this form at the timestamped moment, and that no party (including FidesBeacon) could have produced the token without the TSA's cooperation at that moment.
The TSA is the third-party trust anchor. Its signature is the part that makes the timestamp evidence rather than assertion. FidesBeacon uses FreeTSA for Standard-quality engagements and DigiCert for Pro and Premium-quality engagements; both publish their root certificates and audit reports, and both are acceptable under the major commercial standards that build on RFC 3161.
Why this matters in litigation
Three concrete situations in which the timestamp earns its keep:
Authentication challenges to AI-assisted work. Opposing counsel objects to a deliverable on the ground that the AI vendor produced or modified it after the fact — that the analysis was retro-fitted to support trial-eve framing. The timestamp answers cleanly. The hash, the TSA signature, and the publicly verifiable time stamp the deliverable to the moment of its production, before the supposedly retro-fitted change could have happened. No vendor-side affidavit is needed; the math establishes the timeline.
Spoliation and chain-of-custody questions. A party challenges whether a particular document existed in its cited form on the relevant date. FidesBeacon timestamps the analytical work product, not the underlying production documents, but the deliverable's source index records the documents' identifiers and hashes as they were at the moment of analysis. A timestamp on the deliverable carries the source-index snapshot forward as a verifiable point of reference for what the documentary record looked like then.
Long-running matters with personnel turnover. A deliverable produced in year one of a five-year matter is read in year four by counsel who did not commission it. The timestamp removes any question about when the analysis was performed, against which version of the production set, and under which operating discipline. It substitutes evidence for institutional memory.
How the verification works in practice
The verification path is symmetric to the production path. The
receiving party recomputes the SHA-256 hash of the deliverable
file, fetches the TSA's public certificate from the TSA's
published location, and uses standard tooling (OpenSSL's
ts subcommand, or any RFC 3161 verifier
library) to confirm that the timestamp token contains the same
hash, the asserted time, and a signature valid under the TSA's
certificate. The whole process takes seconds and produces a
yes-or-no answer. FidesBeacon ships a verify
command-line utility with each Pro and Premium engagement so the
receiving firm can run the check without depending on us.
What the timestamp does not do
The timestamp proves that the deliverable existed in this form at this moment. It does not prove the deliverable is correct. Citation accuracy is enforced by the citation verifier (0.95 pass-rate threshold). Reasoning quality is enforced by founder review and, on Trial-tier work, by Two-AI Adversarial Review. The timestamp is one of four orthogonal disciplines, not a substitute for the others.
What we recommend doing with the token
Keep it. The token is small (under 5KB), self-contained, and
separable from the deliverable file. We deliver each engagement's
token in a dedicated rfc3161/ subdirectory alongside
the QC log and the source index. If your matter management system
preserves engagement artifacts, the token is one of them. If a
challenge arises later, the token is the answer; without it, the
math the timestamp protects against can no longer be performed.