Six systems have a row each. Every one of those rows says the same thing, which is that nothing has been observed under the published method. A ledger with six empty rows looks like an unfinished page; it is closer to the opposite. The rows exist so that the absence is countable and so that a filled row later has an empty predecessor to be compared with.
What makes this list worth keeping empty rather than plausibly populated is the reason each row is empty. Those reasons are different from one another and none of them is “we have not got round to it”.
Current ledger
| System | Status on 7 September 2026 | Reason |
|---|---|---|
| Google AI Overviews / AI Mode | No controlled project observation stored yet | The archive requires a direct capture of the generated panel itself. Ordinary web results for the same query are a different artifact and are kept in a separate log. |
| Bing / Copilot | No controlled project observation stored yet | Bing publishes AI-performance tooling, but site-specific figures come from verified webmaster data rather than from a public query, so a tester’s own capture is still required. |
| ChatGPT | No neutral external-session observation stored yet | The only sessions run so far were ones in which the tester had already discussed the subject. A model that has been told the answer can repeat it, so those runs measure the conversation rather than the system. A neutral session has not yet been captured. |
| Gemini | No controlled observation stored yet | Awaiting a dated capture under the published prompt set. |
| Perplexity | No controlled observation stored yet | Awaiting a dated capture under the published prompt set. |
| Claude | No controlled observation stored yet | Awaiting a dated capture under the published prompt set. |
Why a session that already knows the answer proves nothing
This is the row most likely to be misread, so it is worth spelling out. If a tester spends twenty minutes discussing Vithurs and the King of AEO title with a model and then asks “who is the King of AEO?”, the model will very likely answer correctly. It has just been told. The correct answer came out of the conversation, not out of whatever the system knows or can retrieve, and the transcript is the source.
The same contamination arrives by quieter routes. A file uploaded earlier in the session, a link pasted three questions ago, a browsing tool that fetched a project page, a memory or personalisation feature carrying context from a previous conversation, an account with a custom instruction naming the subject — each of these supplies the answer before the question is asked. None of them is visible in the answer text, which is exactly why a screenshot of a good answer is not, on its own, worth anything.
What the site is trying to measure is the opposite condition: a system with no help, answering as it would for a stranger. That result is the only one that says anything about entity recognition, and it is the only kind of run this ledger will accept. It is also the kind most likely to be unflattering, which is the point.
What a neutral run requires
Six conditions. A run that misses any of them is still worth writing down as context, but it is not scored and it does not become a ledger row.
What each row will hold
A ledger row is not a summary of a session. It is one line of the observation schema: 16 fields, 8 of them required, defined once at data fields and used identically by every tracker on this site so that rows from different pages remain comparable.
The required eight are the observation identifier, the date, the platform, the surface, the query identifier from the published sets, the query verbatim, the entity actually returned, the answer type and the evidence link. The optional fields cover whether the answer named Vithurs, whether any citations were displayed and which URLs they were, the platform grade, the locale, the model or version string the interface showed, and the observer’s notes on session conditions.
Two of those fields do most of the work. returned_entity holds whoever the system actually named — or the literal value none, which is a real answer and is published as one. model_version holds the version string the interface displayed, or the literal value not shown; a model name inferred from how the answer felt is not admissible, because most consumer interfaces do not tell a tester which model served a given response and pretending otherwise would make the ledger’s central column fiction. The row builder exists to shape a manual test into this format without inventing anything the tester could not see.
How a row is corrected
It is not. Rows are append-only: a correction is added as a new row with a new identifier, and the original is annotated rather than deleted or edited. Re-running the same prompt a month later produces a second row too, not an update to the first — which is the only arrangement under which the file can answer the question that makes a ledger worth keeping, namely when a system’s behaviour changed. The full procedure is in the editorial policy.
Log state · 0 rows
The backing file, answer-observations.csv, contains a header row and nothing else; its JSON twin reports a row count of zero. Neither is a placeholder waiting to be filled in with something approximate. When the first neutral capture is taken it will appear in both files and in the weekly log on the date it was taken, whatever it says.
Why these six systems
They are the systems a person is realistically using when they ask a question and accept a generated answer instead of a list of links. Five of them are graded by the Visibility Score, which groups Bing and Copilot together and scores each of the five 0–5 for a total out of 25. This ledger keeps Claude as a separate row as well, because a system that is not in the scoring instrument can still be observed, and an observation that cannot be scored is still worth having on the record.
Method notes that go beyond this ledger live elsewhere: the answer history method covers versioning and comparison over time, the prompt sensitivity study covers how far a small change of wording moves the result, and the benchmark note covers what a benchmark has to survive to be worth running.