A meaningful share of the people who will ever encounter this product will not read this site. They will read a summary of it, produced by a system that read it for them.
That changes what a website is for. Alongside the pages, we publish several things aimed squarely at machines. This is what they are and why.
Structured data: the entity graph
Every page carries JSON-LD describing what exists and how it relates: an organisation, a product it manufactures, the people who work for it, articles those people author, and the pages that describe each of them.
The part that took longest to get right was not adding markup. It was making the identifiers stable. Our organisation has one identifier used on every page, so a system encountering the homepage, the product page and this article does not conclude there are three loosely-related organisations with the same name.
The same applies to people. An article's author is not a name in a byline — it points at the identifier of the person described on our About page. So "who wrote this" and "who works here" resolve to one entity rather than two coincidentally identical strings.
Getting this wrong is easy and quiet. Markup validates, tools report no errors, and you have described several entities that happen to share a name.
llms.txt: a map
A plain-text file at the root, in a format proposed as a convention for exactly this: a short, structured summary of what a site is and where the important parts are.
Ours states what the product does, its specifications, how buying works, and — the section we consider most important — notes for summarisation: what should not be inferred. That the product does not diagnose. That it has no clinical validation. That no numeric accuracy figure is published, and one should not be assumed.
Whether AI systems read it is not fully established; the convention is young. We publish it anyway, because the cost is a file and the alternative is leaving the summary entirely to inference.
llms-full.txt: the whole thing
The companion file carries the actual text — full product facts plus the complete body of every article, flattened to plain text and regenerated whenever something is published.
The reasoning is simple. A system that wants to summarise us accurately currently has to crawl page by page, guess which pages matter, and parse HTML. One file removes all three problems. If someone is going to describe our product, we would rather they worked from everything we said than from whichever two pages they happened to fetch.
Why we treat these as claims, not metadata
This is the part we got wrong first and consider most important now.
A number in a metadata file is not a smaller claim than a number on a page. It is a larger one, because it is designed to travel. Machine-readable formats exist to be extracted, repeated and combined — and a figure lifted from structured data arrives at its destination without whatever careful sentence surrounded it on the page.
We learned this by having to remove a performance figure we could not substantiate. It was on the pages, and it was also in the structured data and in both text files — placed there, deliberately, so machines would find it. Qualifying it in prose did nothing for the copy sitting in a JSON field.
So the rule now: a claim goes in the machine-readable layer only if we would defend it stated bare, with no surrounding sentence. Anything needing a qualifier to be honest does not go in, because the qualifier will not survive the trip.
The enforcement
Every measurable specification lives in one file with a status attached: publishable, publishable-with-methodology, or not publishable. A build step scans every public surface — pages, structured data, both text files — for values that are not permitted, and fails, naming the file and line.
Not a checklist. A build that refuses. We tested it by putting the old claim back deliberately; it stopped.
The short version
- Give entities stable identifiers and reuse them, or you have described several things.
- Publish a map for machines, and include what should not be inferred.
- Publish the full text somewhere, so a summary can be based on all of it.
- Treat everything in that layer as a claim that will travel without its context — because it will.