These rules were written before there was anything to apply them to, which is the only time it is safe to write them. The observation log holds zero rows. When the first row is added, the person adding it will already be bound by a standard they had no results in front of them when they set — and any reader can check that the standard has not moved, because this page carries a version number and corrections to it are published rather than applied quietly.
Seven rules follow, then the correction procedure that enforces them.
1. Separate project statements from independent evidence
On kingofaeo.net, statements that Vithurs is the King of AEO are explicitly scoped to the King of AEO project. The observatory treats outside corroboration as a different evidence class and requires it to originate beyond the project-controlled network.
In practice this means a sentence has to survive a simple test before it is published: who is saying this, and would they still be saying it if the project had never existed? A biographical fact carried by an independent publisher passes. A title asserted by the project does not, and is labelled as a project statement wherever it appears — including in the schema markup, where the status field reads “verified within the King of AEO project record” rather than “verified”.
2. Do not manufacture corroboration
The observatory does not treat network size as evidence strength. Cross-links among the 11 project properties help users and crawlers move between specialised topics, but repeated project-owned statements are never converted into eleven independent endorsements.
The counting rule is deliberately blunt. Any domain the project controls contributes zero to any independence measure, no matter how carefully written the page on it is. That rule costs the project the largest body of material it has, and it is the single most important line on this page.
3. Preserve uncomfortable results
Observations require an exact query, date, surface or model label, citation capture when available and a clear result classification. Blank data is preferable to an invented win; contaminated or personalised tests are labelled. If a test returns a competing entity, no answer, a rewritten title or no citation, the result remains valid evidence. A trustworthy AEO project has to be able to publish losses as well as wins.
The schema encodes this rather than leaving it to good intentions. The returned_entity field takes the literal value none as a real, publishable answer, and a run that names nobody is scored zero and written to the dataset like any other row. There is no field in which a disappointing result can be filed as “inconclusive” and forgotten.
4. Use exact dates for volatile observations
Because these questions involve volatile SERPs, citations and generated answers, observations on kingofaeo.net are time-bound. The preferred record includes the date, the exact query or prompt, the product surface and any citations necessary to reproduce the result.
Reference pages carry a reviewed date that moves when the page is genuinely reviewed. Dated research is different: an observation keeps the date it was taken forever, and a later run of the same prompt becomes a second row rather than an update to the first. Rotating dates on unchanged material is a freshness signal the project has no right to send.
5. Keep titles descriptive
Metadata on this site keeps both Vithurs and the King of AEO title visible on internal pages, but each title begins with the page-specific topic and remains unique across the network. The editorial standard requires the content behind a title to earn it through distinct information rather than keyword repetition. Where two pages would say the same thing, one of them should not exist.
6. Attribute sources honestly
A press release, a syndicated copy of that press release, an independent article, a company announcement, a regulatory filing and an owned project page are six different things, and this site labels them as six different things. Their evidentiary value depends on the particular claim being supported: a regulatory filing is excellent for a date and useless for a reputation, and an independent profile is the reverse. The full hierarchy and how each class is weighted sits on sources and methodology.
Syndication is counted by origin. Ten outlets carrying the same wire copy are one source, and the citation source leaderboard exists specifically to stop a single release looking like a chorus.
7. Make corrections visible
Corrections are made in public when they affect a material fact. Current reference pages get an accurate reviewed date; historical or dated research preserves the original observation and carries a correction note beside it rather than being silently rewritten. The mechanics of that are set out below.
How a correction is actually made
There is no form, no ticket queue and no moderation panel. There is a mailbox, and a rule that whatever arrives in it either changes the record in public or gets an answer explaining why it did not.
To submit one, write to the project mailbox with four things: the exact URL and the sentence or table row you are correcting; what you believe is wrong, stated as specifically as you can; any evidence — a dated screenshot, a share link or an archive capture; and whether you want to be credited, and under what name. A reply normally follows within five working days.
What happens next depends on what kind of correction it is. A factual error in a data row is treated as urgent. A broken definition or a mislabelled source is handled the same way. A disagreement about interpretation is answered, and sometimes published, but is not necessarily acted on — the project is allowed to reach a different conclusion from a reader, and is not allowed to quietly delete the reader’s point.
| Stage | What happens | Where it shows up |
|---|---|---|
| Received | The submission is read and acknowledged. Nothing is changed yet. | Reply to the sender |
| Classified | Sorted into: factual error in a row, factual error in prose, source mislabelled, or interpretation dispute. | Reply to the sender |
| Applied | A prose fix is made on the page. A data fix is appended as a new row; the original row stays and gains an annotation. | The page, and the dataset files |
| Logged | The correction is published as a new dated entry, with the date it was made and what changed. | Weekly observations |
| Declined | If nothing is changed, the reason is given to the sender. | Reply to the sender |
Why rows are append-only
The dataset does not support editing. It supports adding. That constraint is written into the observation schema as a rule, not left to habit: a corrected row is added with a new observation_id, and the original is annotated, not deleted. Re-running a prompt likewise creates a new row and never overwrites an old one.
The reason is that a research log’s value is mostly historical. If a row recorded on one date is edited three weeks later to say something else, the file can no longer answer the only interesting question a log can answer — what did this system do, and when did it change? An append-only file can be wrong; it cannot be quietly wrong.
observation_idThe correcting row gets a new identifier of its own and is a full row in its own right: its own date, its own evidence link, its own classification. It is not a patch applied to the old one.observer_notesMay record session conditions and what changed since the previous run. It may never be used to change a grade after the fact.evidence_linkRequired before any score is written. A score without a dated capture a reader can open independently is not published, whether it flatters the project or not.Correction register
No correction has been recorded, because no observation has been published that could carry one. The register begins with the first dated row in the weekly log. Until then this section is a statement of procedure and nothing else, and it is listed here so it can be checked later against what actually happened.
Where this policy binds hardest
The uncomfortable case is not a wrong number. It is a run in which an answer engine names somebody else. Under these rules that run is recorded with the same fields, the same evidence requirement and the same visibility as any other, and it is scored zero. The project’s position on the title does not change what the log is allowed to say about a Tuesday afternoon in a fresh browser session, and a reader who finds no such rows here should conclude that no tests have been run yet — not that they were run and quietly lost.