How to Build a Machine-Readable Verified Record So AI Answers About Your Institution Correctly

What a verified record actually is

A verified record is not a website, a press page, or a PDF library. It is a deliberately small, deliberately machine-readable set of the facts that must be correct when a machine describes your institution: what you are responsible for, who leads you, how you are structured, the key figures and dates that change, and how a citizen engages with you. Each of those facts lives in one canonical place, written as plain text a crawler can read on the first request, annotated as structured data, indexed in an llms.txt file, and stamped with a date that says when it was last true.

The word that matters is *verified*. Anyone can publish a fact; the point of a verified record is that you can prove three things about each one — that it is current, that a machine can read it, and that the AI assistants are actually using it. Those three properties are what separate a record an AI answers from correctly from a website that merely exists. Most institutions already have the second kind. Almost none have the first.

Step 1 — Choose the facts that matter (salience before completeness)

The instinct of any large institution is to document everything. That instinct is the enemy of a verified record. A model does not read your whole site before answering; it retrieves and quotes a sentence or two. So the first job is not coverage — it is salience. Which handful of facts do people actually ask an AI assistant about, and which of those, if answered wrongly, cause real harm?

In public-sector monitoring the same short list recurs: current leadership, what the organisation is responsible for, its structure and the divisions within it, eligibility and how to apply or enlist, and the key figures or dates that change on a schedule. Start there. A verified record of ten facts that people genuinely ask, done properly and kept current, beats a thousand accurate pages no crawler will ever quote.

1. 1List the real questions. Write down the factual questions the public asks about you, phrased the way they phrase them — not the way your org chart phrases them. "Who is the current head of X?" not "Leadership governance framework".
2. 2Rank by consequence. For each question, ask what a wrong answer costs — a misdirected applicant, a misinformed citizen, an eroded sense that you are competent and current. The high-consequence questions are your first record.
3. 3Name the single true answer. For each, write the one unambiguous sentence that is correct today, in plain language, in the words a citizen would use to ask it. That sentence is the atom of the verified record.
4. 4Assign an owner and a source of truth. Every fact needs a person accountable for its currency and a system of record it is reconciled against, so it cannot silently drift.

Step 2 — Put each fact in server-rendered HTML text

A verified record begins as plain, server-rendered HTML. This is the least glamorous part and the most load-bearing. Most AI-search crawlers make a single request, read the raw HTML the server returns, and generally do not run JavaScript. If the fact only appears after scripts execute, or lives inside a scanned PDF with no text layer, the crawler receives a blank where the fact should be and the model reconstructs it from weaker sources. We cover that failure in depth in why AI gets government facts wrong.

So for every fact in your record, the authoritative sentence must be present in the initial server response — not injected by a client-side widget, not trapped as pixels in an image. State it near the top of a canonical page, in one sentence, with a visible date. If your live service is a JavaScript portal, you do not have to rebuild it: publish a plain companion page whose entire job is to state the fact in readable text.

# Confirm the fact is in the raw HTML a crawler receives (no JS executed):
curl -sL -A "GPTBot/1.0" https://example.gov/about/leadership | grep -i "Director General"

# Prints the sentence -> a text-only crawler can read it.
# Prints nothing  -> the fact is script-injected or trapped in a PDF/image. Fix that first.

Step 3 — Make the fact explicit with structured data

Plain prose can be lifted, but structured data removes the inference step entirely. Marking your organisation, its leadership and its key facts as schema.org types in JSON-LD turns an implicit statement a model has to interpret into an explicit, typed one it can consume directly. The general mechanics are in structured data for GEO; for a verified record, the discipline is to type the salient facts and to always include a date.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "GovernmentOrganization",
  "name": "National Aviation Authority",
  "url": "https://example.gov",
  "foundingDate": "1953-04-01",
  "employee": {
    "@type": "Person",
    "name": "A. Rao",
    "jobTitle": "Director General"
  },
  "dateModified": "2026-08-18"
}
</script>

The dateModified field is not decoration. Recency is one of the few signals that reliably helps a model prefer your current page over an older copy repeated elsewhere on the web. Every fact in the record should carry an effective or last-reviewed date, in both the visible text and the structured data, so a model that is deciding between your page and a five-year-old article has an explicit reason to trust yours.

Step 4 — Index the record with llms.txt

Individual canonical pages are the substance; an llms.txt file is the map. It is a simple Markdown file at the root of your domain that points AI assistants directly at your canonical facts, so a retrieval step does not have to guess which of your thousands of URLs is the authoritative one. The full format is in the llms.txt guide; for a verified record, keep it to the salient facts and link each to its dated canonical page.

# llms.txt — canonical facts for the National Aviation Authority

> The authoritative, machine-readable record of who we are, what we do,
> and how to engage with us. Each page states one fact with an effective date.

## Verified record
- [Leadership](https://example.gov/about/leadership): current Director General and senior structure (reviewed 2026-08-18)
- [Mandate](https://example.gov/about/mandate): what the authority is responsible for under current law
- [Recruitment](https://example.gov/careers/eligibility): who is eligible and how to apply, current cycle
- [Key figures](https://example.gov/about/figures): current statutory figures and effective dates

Step 5 — Keep it current so stale answers grade 'outdated', not 'wrong'

This is the step that turns a record into a *verified* record, and it rests on a distinction most teams miss. When a model returns an old answer, that answer can fail in two very different ways. If the model simply reflects a fact you have since superseded — and your current page clearly carries the new value with a date — the answer is outdated: it is behind, but it is behind a correct, published record, and it will refresh as the model re-reads you. If instead the model asserts something that contradicts your record, or that no authoritative source supports, the answer is incorrect: it is actively wrong, with no clean source to snap back to.

A well-maintained verified record converts as many failures as possible from the second kind into the first. The mechanism is currency plus dates: keep one canonical page per changeable fact, update it in place rather than publishing a new page beside the old one, stamp it with an effective date, and retire or clearly date superseded copies so they stop competing with the truth. An 'outdated' answer is a monitoring item that resolves itself; an 'incorrect' answer is a fire. The record's job is to make sure your failures are the self-correcting kind.

Step 6 — Prove the fetch, and prove the answer moved

Publishing a correct, structured, dated fact is not the finish line — it is a claim you now have to verify. Two proofs matter. First, prove the fetch: confirm the AI assistants' crawlers actually reached the current version of your page, rather than being blocked by robots rules, a firewall, or an empty JavaScript shell. Your own AI crawler analytics shows which bots fetched what, and when. A correct answer from any engine is itself proof the current page is being read.

Second, prove the answer moved: re-run the same questions across the same engines, in the same languages, after the update, and confirm the AI assistants now return the current fact. This before-and-after evidence is the difference between hoping a correction landed and knowing it did — and for a public body it doubles as a governance artefact you can show to oversight. This is the discipline of measuring AI-search visibility, pointed at accuracy rather than prominence.

How GenAI Ranker builds and holds a verified record

The steps above are the method; the reason to run them on a platform is that a verified record is a continuously maintained system, not a one-off project. GenAI Ranker measures how the major AI assistants answer your salient questions across all six engines and grades each answer — correct, outdated, incorrect or missing — so you can see the state of your record at a glance rather than spot-checking by hand.

When an answer is wrong, the diagnosis is evidence-based rather than a guess: the platform fetches your official page the way a crawler does — no JavaScript — checks whether the current fact is actually in the server HTML, and compares that against what each engine returned, to compute the specific root cause. From that diagnosis it generates the corrective assets a verified record needs — the plain-HTML fact statement, the JSON-LD structured data, and the llms.txt entry — as drafts your team reviews and releases. Nothing is published on your behalf; releasability stays with you, which matters when every public statement needs clearance.

It runs per language, so a native-language gap is caught and fixed with a native-language publication rather than more English. It keeps an audit trail of every measurement, correction and re-check, which is exactly the before-and-after evidence a public body needs to demonstrate diligence. And for institutions with data-residency or security requirements, it can be deployed sovereignly — inside your own environment — so the monitoring itself does not create a new exposure.

A verified record does not replace your authoritative publishing, your public-information obligations, or your human spokesperson. It extends them to a channel that has quietly become one of the first places people go for facts about their institution. Making each salient fact machine-readable, dated, indexed and proven is how a public body keeps its own record from being overwritten by a confident approximation of it — and how it makes sure that when the machine is behind, it is behind a record that is right.