What machines see when they read this site.

Open any page here and you are reading sentences. A heading, a paragraph, a link, arranged so that the meaning arrives in a particular order and each part is colored by the part before it. A model retrieving the same page is not reading it that way. It is looking for facts it can lift out cleanly without having to interpret the prose wrapped around them: what this organization is called, what it sells, who it serves, what it published and when.

Both readings come out of the same file. The visible one is written. The machine-readable one is engineered, and it is a separate deliberate act. A page can read beautifully to a person and still hand a retrieval almost nothing it can use. That is the ordinary case, not the exception, and it is the gap the work sits in.

The panel below is not a diagram of somebody else's site. The fields on the right are the ones this page is serving you as you read it.

Structured data restates facts a page already makes in prose as labeled fields, in a form built for parsing rather than for reading. It sits alongside the visible page instead of replacing it. Four such records and one plain-language map are published across this site, and each one settles a different question that a machine would otherwise have to guess at.

The service record carries no prices and no figures of any kind. That is not an oversight, and it is worth explaining because it shows where this work goes wrong quietly.

This site publishes no prices, and the service record does not escape that rule. Three checks reach it, not one: the guard that scans this repository's source, the guard that scans the page as rendered, and a test that pins the record's exact set of fields. The first reads the file the record is built in directly; the second reads the same record again, because it is printed into a script tag on every route; the third would still catch a price arriving under a field name neither guard's pattern recognizes. What survives all three is narrow: a bare figure with no currency symbol, sitting inside a field the record is already allowed to hold, would pass every one of them.

That asymmetry is general. The machine-readable layer is where a claim can be made without anyone noticing it was made, which is exactly why it needs governing as tightly as the copy does, and why the guard on this page checks the fields rather than the sentences.

One field in our own entity record is empty, and it happens to be the one that would matter most.

There is a field whose entire purpose is to list the other places on the internet that are demonstrably the same organization. It is how a machine tells two similarly named entities apart. Ours is empty.

We ran our own method on ourselves the day this site launched and published the result. The finding was that our name does not resolve to us: an older set of firms and one long-established product hold it, and a search for the name as written returns them instead. That is precisely the problem this field exists to solve, and we cannot use it, because the field takes corroboration and we have nothing yet to point it at.

A firm that sells structured data has an obvious incentive to imply that structured data fixes this. It does not. Markup states a claim; it does not corroborate one. An entity is only disambiguated when independent sources agree about it, and nothing we add to our own site counts as an independent source about our own site. The remedy is being cited somewhere that is not here, which is slower and harder to sell and is nevertheless what the finding says.

So the field stays empty, and it stays printed on this page rather than left out of the specimen. On the day it fills, this section stops being true, and a test in this repository is written to fail at that moment, deliberately, so that the copy gets rewritten instead of quietly aging into a false claim.

Engineering the layer is half the job. The other half is finding out whether it changed anything, and that means measuring the answers themselves rather than admiring the markup that was supposed to influence them.

Each engagement gets its own bank of questions, written for that client: the things a prospect would actually type, and the things they would actually ask out loud, before deciding anything. Those questions are put to search results and to assistant answers alike, live rather than read out of a pre-aggregated database, and every raw result is kept.

Every one of those measurements is made by a person. Nothing on that side is automated, and that is a constraint we chose rather than one we have not got round to lifting. Scoring an assistant answer means deciding what the answer actually said about you (whether being described as an alternative to somebody else counts as being named), and that decision is not a step on the way to the measurement. It is the measurement.

A single run tells you a position and nothing about direction. Both channels drift underneath you: rankings move on their own, and model answers change as providers update them, so a result read once is indistinguishable from a result that was about to change anyway.

The questions are therefore frozen at the start and asked again unchanged. Two runs of the same bank can be compared. Two runs of differently worded banks can only be reconciled, which is a much weaker thing and tends to produce a story rather than a measurement.

As each week's run lands it joins the record instead of replacing it. That accumulation is the actual asset, and it is why a later month is worth more than the first one, not because the reporting improves, but because by then there is something to compare against that came from you rather than from an industry average.