The Legibility Sprint
A published protocol for measuring, diagnosing and improving how AI systems retrieve, understand and select a person or company. Published in full, free to run.
Search used to index pages. AI systems reconstruct you from fragments, and if the fragments are thin, stale or tangled with someone else's, the answer gets built without you. Not because you are worse than the person named instead. Because you are harder to read.
This is the protocol I ran on myself before I ran it for anyone else. It was a paid PDF until August 2026. It is now published in full, for a plain reason: a method that models cannot read is a poor advertisement for legibility work.
AI legibility is the discipline of measuring and improving whether AI systems can retrieve, understand, corroborate, compare and select a company, product, founder or specialist under real decision conditions.
AI Search and GEO, technical SEO, digital PR, entity and brand authority, and measurement each address a different part of that evidence chain. AI legibility is not a synonym for any one of them. The method is Measure → Diagnose → Fix → Measure again. Scope and follow-up conditions are agreed before work begins.
Visibility is how often you are mentioned. It is one observation inside the broader measurement, not a substitute for legibility.
Measure Record the starting observations
- Set the prompt sample, repetitions and follow-up window for the decision, baseline variability and available budget. Keep product surface, language, market and test conditions comparable. Report counts, unknown results and limitations.
- Choose the AI products and accessible surfaces before testing. Record consumer-app observations and API results separately, including personalization and retrieval settings where observable.
- Save the exact questions, raw answers, dates, product and model information where available, sources and capture artifacts.
- Record identification, retrieval, citation, shortlist and recommendation as different outcomes. State the number of accepted comparable observations and keep failures and exclusions visible.
- Preserve this baseline and its limitations; do not rewrite earlier observations to fit a later result.
Caveat. Choose comparison or negative controls when they address the question. Without a suitable comparison, before-and-after findings remain descriptive.
Diagnose Choose changes from the evidence
- Identify the problem supported by the observations: unclear identity, inaccessible information, contradictions, missing support, query fit or a broken next step. Label uncertain explanations as hypotheses.
- Choose interventions after diagnosing a specific problem. Structured data, an llms.txt summary or an eligible public entity record may help particular uses; none is universally required or guarantees AI visibility. Document the client and observed behavior when claiming support.
- Prioritize the proposed changes and agree scope, ownership and approval before implementation.
- An llms.txt file may provide a concise public summary, but its presence does not establish that a particular crawler or AI product reads it.
- My summary is available at katyashalel.com/llms.txt as an example, not a required template.
Caveat. The following implementation options are selected by diagnosis. They are not a mandatory checklist for every entity.
Fix Use relevant structured data
- When appropriate for the page and intended consumer, describe public facts with valid structured data.
- Choose types that match the actual content, such as Person, Organization or Article. Do not add entities, claims or a fixed schema bundle simply to complete a checklist.
- Use identifiers and profile links only for the correct entity. Review ambiguous name variants and relationships.
- Keep structured claims consistent with visible facts; equivalent wording is acceptable when the meaning and identity remain clear.
- Validate syntax, identifiers and visible-text agreement. Valid markup does not guarantee extraction, eligibility, citation or recommendation.
Fix Correct relevant public records
- Assess source independence and whether a source actually supports the claim. Repetition alone is not corroboration.
- Consider an eligible public entity record only when it suits the diagnosed problem and meets that service’s policies. Do not create profiles or records without approval.
- Explain name variants where useful without inventing relationships or treating every spelling difference as a separate person.
- Correct outdated public facts on approved surfaces and keep an inspectable record of what changed.
Caveat. A public graph entry is optional. If eligibility or adequate sources are missing, record that limit and choose a supported alternative.
Fix Make important facts accessible
- Correct the specific missing or misleading information identified by diagnosis. Answer relevant questions in context.
- Keep important conditions near each claim so an extracted passage remains understandable.
- Define unfamiliar terms accurately and link useful sources without inventing evidence or attribution.
- Check the permitted public route and extraction behavior. Respect existing privacy, login, consent, training-policy and payment restrictions.
Fix Keep approved sources consistent
- Choose relevant publication routes for the intended audience and document what is observable about discovery.
- Keep underlying facts consistent while allowing useful wording, language and format differences.
- Link original definitions where appropriate; a link does not guarantee indexing or attribution.
- Evaluate each source against the claim it supports. There is no universal numerical exchange rate between independent sources and your own pages.
Measure again Repeat comparable observations
- Use the agreed follow-up window, allowing for the relevant publication and retrieval routes. There is no universal day-21 requirement.
- Repeat the core questions with comparable product surfaces, languages, markets and settings. Record material differences rather than silently pooling them.
- Report outcome counts with their denominators, failures, unknowns and limitations. An illustrative count is not a client result.
- Keep the approved change log and consider alternative explanations, including product, model and retrieval changes.
- Agree further checks according to the stakes, observed change and available budget. A technical correction and an improvement in recommendations are separate findings.
What you have at the end
- A scoped, dated record of raw observations and available evidence for each tested product surface.
- A diagnosis that separates confirmed problems, hypotheses and unresolved questions.
- Prioritized implementation options with agreed ownership and approval.
- An inspectable record of approved changes and technical checks.
- Comparable baseline and follow-up observations within an agreed window, with counts and limitations.
- A decision about useful next steps; further checks are agreed rather than automatically quarterly.
What this protocol cannot do
- No one can guarantee a position in an AI answer. Anyone who does is selling astrology.
- Model answers are not deterministic. The same question can return different answers in the same hour, which is exactly why the protocol asks for repeated runs and a fixed question set.
- Results are specific to the markets, languages and questions you tested. A gain in Russian-language queries says nothing about English-language ones, and vice versa.
- Structure amplifies substance, it does not replace it. If there is nothing verifiable to find about you, legibility work makes the absence easier to read.
Questions
Why is this free?
Because a method that models cannot read is a bad advertisement for legibility work. Published in full, the protocol is citable, checkable and repeatable by anyone, which is worth more to me than the price of a PDF.
Do I need to write code?
Not always. The work may involve public facts, settings, content or code depending on the diagnosis and agreed scope. The owner approves factual claims and external changes; an AI assistant does not replace that responsibility.
How long does it really take?
Agree the prompt sample, repetitions and follow-up window for the decision, baseline variability, publication routes and available budget. There is no universal seven-session, day-21 or quarterly requirement.
What if I have several companies or brands?
Then the ordering matters more than any single step. You have to decide which entity carries the authority and which ones inherit it, and get that wrong and you spend a quarter reinforcing the weakest one. That is the case where people usually ask me to run it with them.
Is llms.txt an official standard?
No. It is an optional convention whose usefulness depends on the client and use case. Record the tested client and observed behavior before claiming support; the file does not guarantee AI visibility.
Want this done for you
The protocol above is the whole method, free, and plenty of people run it themselves. If you would rather not, or your setup has several connected entities and the ordering matters, tell me what you are working with. I read every inquiry myself and reply within one business day.