Technical Overview
How machines model, verify, and cite a local business — and a procedure for making that data trustworthy.
Search and AI systems no longer evaluate web pages in isolation; they resolve businesses into entities — nodes in a knowledge graph — and decide what to state as fact by corroborating independent sources. This overview describes that shift as documented platform history, explains the mechanics of entity resolution, and states our working method precisely enough that each step can be independently checked.
Documented history
From strings to things.
The shift this work is built on is not speculation; it is documented platform history.
Google, Microsoft, and Yahoo (joined by Yandex) launched a shared vocabulary for describing real-world things — organizations, places, products, offers — directly in web pages, so that machines could read facts rather than infer them from prose.
Google announced it was modeling “things, not strings”: real-world entities with attributes and relationships to other entities, rather than keyword-matched documents. A local business stopped being a set of ranked pages and became a node in a graph.
The W3C published JSON-LD as a formal Recommendation for serializing linked data. It is the format Google’s own documentation recommends for structured data, and the format in which entity claims are most reliably parsed.
Large language models answer questions by retrieving and synthesizing sources rather than returning a list of links. What gets retrieved, trusted, and cited is a function of how legible and consistent the underlying data is.
A correction to the slogan
Things, and strings.
“Things, not strings” was accurate marketing for the index shift, but as a description of the mechanics it overstates the break. The Knowledge Graph did not retire strings; it gave them a destination. Entity resolution is the string layer: a business name, an address, a phone number, a domain, a profile identifier are all strings, and the machine’s job is to decide which thing they point at. Every identifier is simply a string that has been promoted to a name.
This matters because strings are the only evidence a machine ever receives about a thing. When one surface says “Anytown Ford” and another says “Ford of Anytown,” the underlying thing is identical — but the strings disagree, and string disagreement is what the resolver actually measures. Confidence in the entity is, operationally, a function of agreement among the strings that reference it.
The language-model era made this more true, not less. A large language model is the ultimate string machine: token statistics with no native store of things at all. Retrieval grounding is the industry’s acknowledgment that string machines must be handed well-formed things at answer time. The history is a pendulum — strings only (keyword search), then “things, not strings” (the graph), then things for string machines (retrieval-grounded answers) — and the stable position was always both at once.
The entity is the destination; the strings are the roads. If the roads disagree, nobody arrives.
Everything that follows on this page is engineering for that pair: model the thing once, then make every string that references it agree.
The entity model
A local business is a node described three ways.
In a knowledge graph, a business is a uniquely identifiable node described by three kinds of data. All three must agree for the node to be resolved with confidence.
sameAs links asserting that profiles on other platforms describe the same real-world thing.The mechanics
Why consistency is a measurable signal.
Entity resolution — the process of deciding whether two observations describe the same real-world thing — is a well-studied problem in information systems. Its core mechanic is corroboration: when independent sources report the same value for the same attribute, confidence in both the value and the entity rises. When they conflict, confidence falls, and systems either pick a source they trust more or decline to state the fact at all.
This is why fragmentation has a real cost. Conflicting hours between a website and a business profile, a department page that describes a different legal entity than the profile it is linked from, or markup that disagrees with the visible page are not cosmetic issues — they are contradictory claims about the same node, and they lower the probability that any system will state your data as fact.
The engineering consequence is a design rule we apply everywhere: establish the truth first, then render it. Every attribute must have exactly one canonical source, and every surface that publishes the attribute — page, markup, profile — must derive from that source rather than maintaining its own copy. Copies drift; derivations don’t.
The procedure
Five steps, each falsifiable.
The method is a loop. Each step has a defined input, a defined output, and a verification criterion — meaning each step can fail visibly, and be checked by someone other than us.
Capture the business’s public machine-readable state as a crawler sees it: rendered HTML, embedded structured data, business-profile fields, and directory records. Output: an audit snapshot. Verification: the snapshot is reproducible — anyone fetching the same URLs sees the same state.
Construct one canonical record for the entity: every attribute mapped to a single declared source of truth, with conflicts between sources logged rather than silently resolved. Output: a canonical-source map. Verification: no attribute has two masters.
Serialize the canonical record as schema.org-typed JSON-LD on the pages it describes — organization, location, departments, offers, people — with stable @id references so nodes connect instead of duplicating. Verification: published markup passes structured-data validation and matches the canonical record field-for-field.
Align the independent sources machines will compare — website markup, Google Business Profile, authoritative directories — and declare cross-platform identity with sameAs edges. Verification: the same attribute queried on any surface returns the same value.
Data drifts: platforms accept third-party edits, inventory turns over, hours change seasonally. Re-observe on a schedule, diff against the canonical record, and correct at the source. Verification: drift is detected and resolved, with a record of what changed and when.
A corollary we hold ourselves to: if a fact cannot be verified, it is suppressed rather than published. An absent claim costs a little; a wrong claim costs corroboration everywhere it is contradicted.
What the data shows
Figures, with their sources.
The figures below are the ones we rely on, stated with their sources and dates. Where a figure comes from field work rather than an independent study, that is labeled — internal observations are evidence of a pattern, not a controlled experiment.
Scope and limits
What this work does not do.
Stating what this work does not do is part of doing it honestly.
We control inputs, not outputs. Retrieval and ranking systems are proprietary and non-deterministic. Entity-first architecture maximizes the probability that machines parse, corroborate, and cite your data correctly; no one can guarantee a specific ranking or recommendation, and claims to the contrary should be treated with suspicion.
Structure does not replace substance. Markup describes a business; it does not improve one. A business with poor reviews or an uncompetitive offering will be described accurately — that is the point.
The field moves. The vocabulary (schema.org), the consuming systems, and their weighting all evolve. The procedure above is designed to be re-run, not installed once — which is why monitoring is a step of the method rather than an add-on.
References
Primary sources.
Disclosure: Entity First Architects is a practice of AutoNet Media LLC, which applies this method commercially for automotive retail through the ELOTS® platform.
See it applied
The procedure, applied to your data.
Step one of the method — a reproducible snapshot of your business’s public machine-readable state, with the conflicts logged — is available as a free audit. What you do with it is up to you.
Prefer to talk it through live? Fifteen minutes — we’ll walk you through the process, and more important, the answers.