machinewitness

Services & fees · Endpoint record

Endpoint record

A public endpoint tells software agents which operations it offers, what each one does and what it expects. Those declarations change quietly and leave no trace of what they said before. This records them, daily, as the bytes that were served.

If this is the first product page you have opened: this archive has recorded, every day since 22 July 2026, what around 128,000 EU domains serve to machines, sealing each day so nobody can alter it afterwards. Everything else here records what a site serves to a browser or a crawler. This records what a service tells autonomous software: the layer on which agents now act, and the one nobody keeps a copy of.

Starting date. An endpoint is asked what it offers, which is a different kind of request from fetching a page. The date on which daily retrieval starts for your endpoint is confirmed to you in writing before anything is charged.

Where this is used

Case 1An agent did something, and the question is what it was told

Software acting for a customer calls a service and something goes wrong: an order is placed that nobody intended, a limit is exceeded, an operation turns out to do more than its name suggested. The argument that follows is about the declaration, what the endpoint said the operation did, what parameters it announced, whether the description invited what happened.

The operator can show the current declaration, but the current one is not the one that was read. Where the endpoint stood under this record, the declaration as served on the day in question exists as bytes, sealed that night, with no version in between that anyone could have quietly adjusted.

Liability for autonomous systems · service operators · company counsel

Case 2A declaration that changed after it was approved

An organisation reviews an external endpoint before connecting its agents to it: the operations are read, assessed, approved. Nothing prevents the declaration from being altered afterwards, and the alteration is invisible to everyone who already trusted it. There is no version history, because the endpoint publishes a current state and nothing else.

A daily record gives the reviewing side what the protocol does not: the declaration on the day of approval, and every day after it, so that a later difference is a matter of record rather than of memory. This archive states the difference exists; whether it mattered is not its business.

Supplier review · security and procurement · in-house counsel

Case 3An operator showing what was never offered

The accusation runs the other way just as often: an agent is said to have used an operation, and the operator’s position is that no such operation was ever published. Proving that something did not exist is notoriously harder than proving that it did, and an operator’s own deployment history is again an internal record.

A daily third-party record of the full declaration covers both directions equally. That is the ordinary consequence of an archive that takes no side: the same file answers the operator and the customer, and neither had to be trusted for it to exist.

Service operators · defence · contract disputes

What an endpoint declares is fetched the way an agent would fetch it, and kept as the bytes that were served. YOU NAME IT One public endpoint The address agents are told to use. EVERY NIGHT Its declarations are read Operations offered, what each expects, the agent card beside them. SAME NIGHT The day is sealed A quiet change to a declaration now leaves a dated trace. YOU HOLD What it promised, per day The version an agent acted on, on the day it acted.
What an endpoint declares is fetched the way an agent would fetch it, and kept as the bytes that were served.

What you can use it for

For the endpoint, and for every day from the admission onwards:

  • Which operations did it declare on that day, with which names and descriptions?
  • What parameters did each one announce, and what did it say they were for?
  • On which days did any of that change, and what did it say before?
  • Did an operation exist at all on a given day, or had it not yet been published?
  • Can that day be checked against a public seal without us?
  1. You name the endpointPublic, reachable without signing in. Yours or another’s.
  2. Both witnesses ask it dailyWhat it offers, and what its published card says, each storing its own copy.
  3. The day is sealedEvery observation of the day is reduced to one fingerprint.
  4. The root is anchored outside this archiveHanded out of the house the same day, so it cannot be corrected later.

What is kept is the answer as delivered, not a summary of it. A format that changes over the years changes how easily a later reader parses the file, not what the file was, which is why this archive stores bytes and leaves meaning to the reader.

Typical use: filed as an extract for the day in dispute, or as a twelve-month record when the question is when a declaration changed.

What is recorded, field by field

The endpoint’s own answer to the two questions any agent asks it first: what it is, and what it offers. Stored as the exact bytes it returned, with the request that produced them, so a later reader can see the question as well as the answer, the fingerprint, the complete response headers, the certificate chain, and the moment of retrieval in UTC.

The published card at its well-known address, where the service publishes one, and any accompanying declaration files, on the same daily footing.

The domain comes with it. The domain carrying the endpoint is admitted to the core at no extra charge, with its front page and the four machine-readable files at its root.

Where the endpoint does not answer, or answers with a refusal, that is recorded as the fact it is. An endpoint that was unreachable on a given day is part of its history.

Full field-by-field schema, with a worked example: what we store.

What is not recorded

Public endpoints only. Anything that requires a key or a sign-in is a closed area, and this archive stays out of closed areas as a matter of principle, not of capability. If the declaration cannot be read by anyone who asks, it cannot be witnessed here.

The declaration, not the traffic. What the endpoint says it offers, not what any agent actually did with it. Calls made by others are their business and are not observable from outside; nothing here reconstructs them.

No judgement of any declaration. Whether an operation is dangerous, whether a description is misleading, whether a change was suspicious: none of that appears, in any form. The bytes are the statement, and the argument belongs to the parties.

And no notification: if a declaration changes you will not hear from us, because a witness that alerts one side is no longer a witness to both.

Diagram: a captured file is hashed (SHA-256), the hash is placed on a Merkle path to that day's root, the root is checked against the public log, and outside anchors confirm the date, independently of MachineWitness.
The chain behind “sealed,” explained in the block below.

What sealed means here

This block is the same on every page of this site, and it is repeated on purpose: it is the part you need in order to judge everything else.

  1. One fingerprint for the whole day. Every observation made that day, yours among hundreds of thousands, is reduced to a single hash through a Merkle tree. One changed byte anywhere in that day, and the fingerprint no longer matches. There is no version that could be quietly corrected.
  2. Published where anyone can see it. The fingerprint goes into the public log the same night, under a fixed, citable URL, together with the instructions for recomputing it.
  3. Handed out of the house three times on the same day. An RFC 3161 time-stamp service, a decentralised OpenTimestamps anchor in the Bitcoin blockchain, and a qualified eIDAS time-stamp from GLOBALTRUST (e-commerce monitoring GmbH, Austria), a qualified trust service provider listed on the EU Trusted List. The third of these is paid for and supervised, and it is worth saying so plainly: only the qualified time-stamp carries the presumption laid down in Article 41(2) eIDAS. A free anchor establishes that the data existed and has not changed, but it carries no presumption laid down by law.
  4. Twice over, by two witnesses that cannot write to each other. Two machines at two providers in two countries, with separate keys. Each seals its own day and takes its own anchors.

In plain words, two sentences. We cannot change a byte afterwards, because the day's fingerprint would no longer match. And we cannot backdate one, because that fingerprint has been in other people's hands since the night it was made. No one has to believe us: every step can be repeated with standard tools.

Further: how it works · what we store · glossary.

Does this stand up in court?

We cannot promise that, and nobody can promise it honestly: what a court accepts is for the court to decide. What we can tell you is what the document is made of, and each of the four facts below can be checked before you buy anything.

  1. It comes from a third party, not from you. Not your screenshot, not your server log. The bytes were fetched and stored by a third party that did not know your matter existed, on a day chosen by the calendar and not by the case. That is the difference between a record and an account of events.
  2. A presumption laid down by law. Every sealed day since 31 July 2026 carries a qualified electronic time-stamp from a qualified trust service provider on the EU Trusted List. 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. 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; the one that matters here is the second.
  3. Two independent witnesses. Two machines, two providers, two countries, separate keys. Each one seals its own day and anchors it externally on its own. Neither can write to the other, so neither can be corrected to match the other after the fact.
  4. Verifiable without us. An appointed expert repeats every step with standard tools: recompute the hash of the file, rebuild the path from that hash to the day's root, check the root against the public log and against the external anchors. We do not have to be believed, and that is the point of the whole construction.

What follows from this in your particular matter is for your lawyer to say. We do not advise, do not rate and do not take a side, and the other side can order the same document on the same published terms. That is not a weakness of the document. It is the reason it is worth anything.

How to order

  1. By e-mail to contact@machinewitness.eu, or through the form on this site. Name the endpoint, and your billing address with a VAT number if you have one. We do not ask what the matter is.
  2. We confirm in writing what we received and name the fee for your request. Nothing is charged before you have that in writing.
  3. You receive a payment link.
  4. Nothing is delivered at this stage, because what you are buying is the record itself. Extracts drawn from it later arrive within five working days; where a court deadline is running, say so when you order and we handle it within 48–72 hours instead, ahead of the normal queue.
  5. We name the date from which the daily record can start, in writing, before anything is charged; from that date the endpoint is entered in the public record and asked daily.

We answer in German, English or Spanish.

Fee

150 € per year per endpoint, charged yearly in advance, as set out in the fee table. The admission of the domain carrying it is included. Nothing is charged before the starting date is agreed in writing. If the year is not renewed, the days already recorded stay sealed and remain available as extracts.

Form of the result

The admission itself: a dated entry in the public record, on both witnesses, checkable at any time through the coverage check. There is no document at this stage, because the document is the extract or the twelve-month record drawn later from the days that were recorded.

The method sheet is included. Every extract comes with the general method sheet at no extra charge, including the one covering a single day. It describes how this archive observes, seals and anchors, and it carries a version and a date. It is not written for your matter, and it does not have to be: it is the same for everyone, which is precisely what makes it checkable.

The technical procedure statement is a different document, written for this particular observation, signed and addressed to a court or an appointed expert. You do not need it in order to file the extract. It becomes relevant when the other side disputes the method rather than the content. See the fee table.

What becomes public, and what does not

Visible to anyone

  • that the domain or URL is observed, and from which date
  • the dated entry in the public record of admissions
  • the daily roots and anchors, as for every other observation

Never published

  • who applied, in no document
  • why: we do not ask what the matter is
  • what the files said: content is issued only as an extract, at the published fee, to anyone

The other side can see that the URL is observed, and since when. That is the price of a witness that belongs to no party, and it belongs here, before the purchase, not in the small print. Where a look-alike domain is observed as a precaution, an opponent may infer that someone is preparing. Whoever does not want that buys a capture of a single day instead of a standing observation.

Neutrality. This archive records; it does not rate, rank or advise. Three conditions hold for everything on this page: it is visible to everyone in the same way; the fee is published and depends neither on who asks nor on how a matter ends; and whoever pays receives nothing a third party would not also receive, which means no notification, no mention as the applicant, no priority, and no content without an extract that anyone else could order too.

Further reading: how it works · evidence extract · terms, section 5.