Three classes of proof, in order
A domain can offer three kinds of proof that it is the organization it describes. They are ordered. Strengthening an earlier class does not produce a later one.
Assertion. The site states a legal name, an address, a parent, a product family, a set of other domains. The statement can be well written and internally consistent. It still originates on the property being evaluated.
Repetition. The same statement appears across the domain’s own pages, profiles, and properties. Repetition shows control of a message. It does not show that anyone outside that control agrees.
Record. An independent public artifact repeats the binding: the same organization, the same domain, without taking the homepage as its source. Until that class exists, the first two are a story the domain is telling about itself.
Repetition shows control of a message. It does not show that anyone outside that control agrees.
The industry spends on the first class
Schema, entity pages, and “about” rewrites increase assertion. Cross-linking brand properties increases repetition. Both are visible to the team that commissioned them. Neither answers whether a record exists.
Citation software cannot separate the classes. A domain that never appears in an answer looks the same whether the failure was retrieval, readability, missing credit, or a lost bake-off among sources that already had credit. The report records an absence. It does not name which proof class was missing.
What the wrong order costs
A specialist manufacturer publishes a precise product library, adds organization markup, and aligns every owned property to one legal name. Two quarters of AEO work later, the citation count is unchanged.
The pages are better. The proof class is not. The public record still does not bind that name to that domain, or it binds a different name, or it binds the name to a different property. Further copy cannot close that gap. The budget reads as unfinished optimization because the only instrument in use measures the last gate in a longer sequence.
Credit is a record problem
Reach is infrastructure. Read is delivery. Cite is selection among sources that already cleared the earlier gates. Credit is the gate that asks whether the domain matches a record of the organization it claims to be.
That match is not produced by restating the claim. A domain with thin inbound references can still sit inside a documented organization. A domain with busy cross-links can still have no record outside its own footprint. Treating those as one “authority” problem sends the first team into link theater and the second team into another entity page.
The question that comes first
Before another page is written to explain the organization, the framework asks one diagnostic, in order: what does the domain assert, what does it merely repeat, and what record exists that did not originate there.
A team that cannot answer the third question has no basis for interpreting a missing citation. The absence in the report is real. Whether the domain offered a record, or only a claim, is a different measurement — and it is a precondition, not a ranking promise.