Reference
For lawyers, data-protection officers, courts, and journalists. Every entry: a plain explanation, a courtroom analogy, and why it matters for evidence.
Every day, MachineWitness visits a large, fixed list of European websites and records what they tell machines: whether a site reserves its content against AI training (robots.txt, ai.txt, tdmrep.json, llms.txt, and reservations in homepage headers and meta tags). Each recording is sealed cryptographically the same day, anchored outside our control, and — since 4 August 2026 — recorded in parallel by a second independent witness. Years later, the archive answers exactly one question: "What did X serve to machines on date Y?" We record. We do not interpret, accuse, or judge.
This is what the archive records today, and it is the whole of it. Snapshots of published AI-crawler identities and of AI providers' terms of service are provided for in the design and are not yet being collected; when a record of them begins, the date it began will be stated here. We would rather describe less than we hold than more.
For the complete contents of a single record, field by field on a worked example, see What we store about a domain.
A single recording of a single web resource at a single point in time: the exact bytes the server delivered, plus when, to whom, and how.
Analogy: one page in a notary's daybook.
Disputes are always about a specific date, not "what does the file say", but "what did it say on 14 August 2027".
A fingerprint of digital content: a short fixed-length code computed from the exact bytes. Change one character and the fingerprint changes completely; it is practically impossible to craft a different document with the same one.
Analogy: a fingerprint that identifies one specific document version, not just the document.
Every snapshot's fingerprint is what gets sealed and anchored; comparing fingerprints later proves the content is unaltered.
Every payload is filed under its own fingerprint: the fingerprint is the filing number. Identical content, even across days or sites, is stored once and referenced many times.
Analogy: an evidence locker where the label on the box is the fingerprint of what is inside: nothing can be swapped in without the label ceasing to match.
Retrieval by fingerprint makes tampering self-evident.
With every snapshot we seal the circumstances of delivery: the full HTTP response headers, the fingerprint of the server's TLS certificate together with five parsed fields from it, the observing server's IP address, and the timestamp: all hashed into the same sealed record as the content. We record the fingerprint, not the certificate itself and not the chain of intermediates above it; where the certificate is needed, it can generally be retrieved from the public Certificate Transparency logs (RFC 6962). See what a record contains.
Analogy: chain-of-custody notes stapled to the evidence bag: who collected it, where, when, from whom.
It ties content to source: not merely "this file existed", but "this server delivered this file".
A method of sealing thousands of records with a single master fingerprint. Each snapshot's fingerprint is combined pairwise, level by level, until one root remains that depends on every record beneath it. That daily root is what we anchor and publish.
Analogy: a bound, numbered evidence volume with one wax seal on the cover: the seal vouches for every page at once.
We follow the construction style of RFC 6962, the standard behind the public logs browsers use to audit TLS certificates. One short code per day commits us, irreversibly, to everything we recorded that day.
A short mathematical receipt showing that one specific snapshot is contained in a given daily root. Anyone can check it, without trusting us and without access to the rest of the archive.
Analogy: proving one page belongs to the sealed volume by matching its position against the cover seal, without reopening every other page.
This is what makes a single evidence extract independently verifiable.
Depositing each daily root outside our own control, the same day, with three independent parties: an RFC 3161 time-stamping authority, which returns a signed token immediately; a qualified electronic time-stamp under eIDAS, issued since the root of 31 July 2026 by a qualified trust service provider on the EU Trusted List; and OpenTimestamps, which aggregates the root towards the Bitcoin blockchain. The Bitcoin confirmation follows hours to days later and is fetched back into the receipt by a daily job; see the current state of each anchor.
Analogy: depositing a sealed copy with a notary the day it was written.
A hash in our own database proves nothing: we could recompute it. An anchor in systems we cannot rewrite proves the seal existed no later than that day.
A qualified electronic time-stamp proves when a piece of data existed. A qualified electronic seal proves who it came from. MachineWitness holds the former and deliberately not the latter.
Analogy: the post office's date stamp on an envelope proves when it was posted, not who wrote the letter.
We say so plainly because the weaker half of any archive is its keeper: we are an interested party, and no stamp we buy can change that. The answer to "who recorded this" is not a seal but the second independent witness and a method anyone can repeat without us. Under Art. 41 eIDAS a qualified time-stamp enjoys a presumption of accuracy as to the date, and that is exactly the part we rely on.
A second recording system, on different infrastructure with a different operator key, observes the same targets independently and seals its own daily root. Operating since 4 August 2026; earlier days rest on the first witness alone. Both roots are published side by side in the public log. They are not identical and are not expected to be: each witness crawls on its own schedule, so a reconciliation compares individual observations, not the roots themselves.
Analogy: two witnesses who kept their own notes and are examined separately. Their accounts will not read word for word alike — each saw the day from where he stood — and that is precisely what makes two accounts worth more than one witness repeating himself.
This addresses the strongest objection against any single archive operator: "you could have fabricated your own records."
Each day our public root log is additionally captured by systems we do not control (the Internet Archive's Wayback Machine; a public git repository with provider timestamps).
Analogy: the newspaper archive that happens to have printed the notice: nobody claims the newspaper conspired.
When a justified erasure request under the GDPR concerns archived content, we delete the plaintext payload and leave a marked "tombstone" in its place. The fingerprint, the seals, and all proofs remain intact and verifiable.
Analogy: a redacted page in the evidence volume: the page is blacked out, but the binding, page number, and cover seal prove the volume was never rebound.
It reconciles two duties that seem to conflict: the right to erasure and the integrity of evidence.
The technical ways a website tells machines "do not use my content". Under Art. 4 of the EU DSM Directive, a rights-holder's reservation against text-and-data-mining must be machine-readable to be effective; the Hamburg Higher Regional Court confirmed in December 2025 that natural-language terms alone are insufficient. These files change silently and leave no trace: recording them daily is the core of this archive.
The deliverable: for a given resource and date range, a package containing the raw payload (or its tombstone), the sealed provenance, the fingerprints, the inclusion proof, the daily root, and the external anchor receipts, with step-by-step verification instructions any technical expert can follow independently.
Stating limits precisely is part of being a credible witness:
We are the flight recorder, not the investigator.