machinewitness

One day in the archive

How a day enters the record, and why it cannot be edited afterwards.

Every 24 hours the same sequence runs. It ends with a single value that anyone can recompute, and that was placed beyond our reach on the day itself. This page draws that sequence, and then draws it backwards, the way an expert would walk it years later.

The daily sequence

The daily recording pipeline At 03:00 UTC the crawler reads the machine-readable declaration files from each domain in the ring: the EU-suffix list below, the core ring, and domains observed since earlier lists. The four declaration files are read daily for every domain; since 3 August 2026 the homepage is read weekly in the broad ring, so a reservation stated only there is recorded precise to the week, not to the day. Each response is stored with its headers, TLS fingerprint and a cryptographic hash. At 23:50 UTC all observations of the day are folded into a single Merkle root, which is anchored with three independent external parties. 03:00 UTC The web, as machines see it spiegel.de lemonde.fr elpais.com thousands more European domains. Declaration files daily, homepage weekly (broad) What is read robots.txt crawler rules ai.txt AI training permission tdmrep.json rights reservation llms.txt guidance for LLMs Small public files no human ever reads Stored, unaltered exact bytes served response headers TLS fingerprint time, in UTC sha256 a3f9c1… one observation We record. We do not interpret or judge. 274,303 observations on 2 Aug 2026, folded into one value 23:50 UTC · the daily seal Merkle root · one value for the whole day 08c2ae22ad98caa5…a16dd256 RFC 3161 OpenTimestamps qualified eIDAS token held here confirmed in Bitcoin token held here Change one byte anywhere in the day and this value no longer matches.

recording & sealing (ours) anchoring (third parties, not ours)

On the Bitcoin anchor. OpenTimestamps works in two stages: the root is submitted the same day, and the receipt becomes self-contained once the Bitcoin confirmation is fetched back into it. That second step was carried out for every sealed day on 7 August 2026, and a daily job has performed it since, so the receipts stored here reference Bitcoin block headers rather than calendar servers. The RFC 3161 and qualified eIDAS anchors return their proof at once and stand on their own. The current state of each anchor, in full.

The three anchors, and what each one is for

Sealing and anchoring are two different acts, and the difference decides what a record from a given day can be used to prove. Sealing is ours: it commits us to a day's contents. Anchoring is not ours: it fixes when that commitment existed, in systems we cannot rewrite. Each term below is what a court would need explained.

The daily seal: one Merkle root

Shortly before midnight UTC every observation of that day is folded into a single value, the Merkle root. Each observation is first reduced to a fingerprint; fingerprints are then combined in pairs, level by level, until one value remains that depends on every observation beneath it. Change one byte in one record and the root no longer matches. That single value is the seal: publishing it commits us irreversibly to everything recorded that day, while revealing nothing about the contents.

A day with no observations at all is not sealed. A witness that observed never has zero records, so zero means it did not observe, and a seal over it would assert a day that never happened. The run stops and reports instead.

RFC 3161: a time-stamping authority

A time-stamping authority (TSA) is an independent service that receives a fingerprint, adds the current time, signs both, and returns the result as a token. RFC 3161 is the internet standard describing that exchange. We send the day's root to a public TSA (freetsa.org) and store the signed token it returns. Anyone can check the signature against that authority's published certificate, without asking us. The token arrives within seconds, which is why this anchor is the one that never lags.

The qualified eIDAS time-stamp: the same act, with legal effect

Technically this is a second RFC 3161 token. Legally it is a different thing. A qualified electronic time-stamp is issued by a provider that appears on the EU Trusted List and is supervised under the eIDAS Regulation; ours comes from GLOBALTRUST (e-commerce monitoring GmbH, Austria) and has been taken for every root since 31 July 2026. Under Article 41(2) of Regulation (EU) No 910/2014 (eIDAS), such a time-stamp enjoys a presumption of the accuracy of the date and time it indicates and of the integrity of the data it is linked to, in every EU member state. Article 41(1) says something much narrower, namely that a time-stamp may not be denied legal effect merely because it is electronic; the two paragraphs are routinely confused, and the one that matters here is the second. A court does not have to be convinced that the clock was right; the other side has to show it was wrong.

Note carefully what it is not. A qualified time-stamp says when. A qualified electronic seal would say who. We hold time-stamps and, deliberately, no seal: the identity of the recorder is the weak half of any archive kept by an interested party, and no certificate we buy would fix that. What answers it instead is the second independent witness and a method any third party can repeat.

OpenTimestamps and Bitcoin: a clock nobody can turn back

OpenTimestamps is a free, open protocol that works in two stages. First, the root is sent to public calendar servers, which collect fingerprints from all over the world during a time window and combine them into one tree, exactly as we combine our own day. Only that tree's single top value is written into a Bitcoin transaction, so one entry in the blockchain carries thousands of unrelated documents at once. Second, once the transaction has been included in a block, the proof connecting our root to that block is fetched back into the receipt file. From then on the receipt stands alone: it can be checked against the Bitcoin block headers, and neither we nor the calendar servers need to exist.

There is no wallet here and no money changes hands. Bitcoin is used for one property only: its block sequence cannot be rewritten after the fact, which makes it a public clock that cannot be backdated. Because a block takes time to appear, this anchor confirms hours to days after the day it attests, and a daily job carries out that second stage. Every sealed day to date has completed it.

Why three and not one. They fail in different ways, which is the point. The two free anchors cost nothing and can be checked by anyone, but one depends on a single authority staying reachable and the other confirms only after a delay. The qualified stamp carries legal weight in the EU but rests on one supervised provider. Bitcoin cannot be rewritten but says nothing about who submitted what. An objection that defeats one of them leaves the other two standing.

The same chain, walked backwards

This is the part that gives the record its value: every step can be repeated by a third party from public data. Nothing below requires our cooperation, our servers, or our continued existence.

How an expert verifies a record without our help Four steps: take the stored observation, recompute its hash, recompute the day's Merkle root from the published log, and check that root against the external time-stamps. Every input is public. Step 1 The record The bytes that domain X served on day Y. Step 2 Recompute the hash Standard SHA-256. Must match what we filed. Step 3 Rebuild the day Fold the public log into that day's Merkle root. Step 4 Check the anchors Three independent parties, not us. Everything above is public If any single step fails to reproduce, the record is worthless, and that is the point: the archive is built so it can be checked against us, not only with us.

the step that does not depend on us at all

Which part of the web is covered

The broad ring is every domain in the Tranco top-1M list that carries an EU-27 country code or .eu: 28 endings in all. The list was exhausted rather than capped: these are all of them, not a round number chosen for convenience.

The counts above are the EU-suffix list itself, tallied by country. The ring adds to that list a small hand-curated core of dispute-relevant domains observed at a higher cadence, plus a residue of domains carried over from earlier lists that no longer appear in the current one. Each domain in the ring is read for its four declaration files every day; the homepage follows the weekly broad-ring cadence. A domain is not dropped from the ring merely because a source list changed: a gap in the record would be indistinguishable from a domain that stopped answering. Recording does stop when the operator of a domain objects. See what we store.

What an ending does and does not tell you. A country-code ending is a proxy for where a site belongs, not proof of it. A German company publishing under .com is not in this list, and a .de domain may be operated from anywhere. We state the criterion rather than claim to cover “the European web”: what is observed is what the criterion selects, and it is written down so anyone can judge the gap for themselves.

Where to go from here

What we store about a domain walks the same ground field by field, on one worked example. The glossary defines each evidentiary term, including what it does not prove. The public root log lists every sealed day and its anchors. The coverage check answers whether a given domain is observed at all. All four cost nothing and need no account.

What a domain actually served on a given day is not on any public page. It is issued as an evidence extract, on request, under published terms and at a published fee.