Technical Overview

Entity-first architecture.

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.

2011
schema.org

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.

2012
The Knowledge Graph

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.

2014–20
JSON-LD standardization

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.

2023–
Retrieval-grounded answer engines

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.

Layer 1 / who it is
Identity
Stable identifiers that let independent observations be merged into one record: the legal and trade name, canonical domain, physical coordinates, and platform identifiers such as a Google Business Profile and Knowledge Graph ID. Ambiguous identity means observations fragment into multiple weak entities instead of one strong one.
Layer 2 / what is true of it
Attributes
The facts attached to the node: hours, address, phone, departments, services, inventory, staff, pricing. Each attribute has potentially many independent sources — website markup, business profile, directories — and machines compare them.
Layer 3 / how it connects
Relationships
Typed edges to other entities: a location’s parent organization, its departments, the brands it carries, the offers it makes, and 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.

1
Observe

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.

2
Model

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.

3
Publish

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.

4
Corroborate

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.

5
Monitor

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.

68.01%
of all Google searches end without a click to any external website
SparkToro · 2026
44%
of car shoppers already use AI search tools
Cars.com / Cox Automotive · 2026
95%
of the GBPs we audit are fundamentally disconnected and poorly optimized for AI search
ELOTS field audits (dozens of GBP audits weekly) · 2026

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.

·
Singhal, A. Introducing the Knowledge Graph: things, not strings. Google Official Blog, May 2012.
·
Schema.org. About Schema.org — collaborative vocabulary founded by Google, Microsoft, Yahoo, and Yandex, 2011.
·
W3C. JSON-LD 1.1: A JSON-based Serialization for Linked Data. W3C Recommendation, July 2020.
·
Google Search Central. Introduction to structured data markup and Local Business structured data — developer documentation.

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.

Request an Audit📅 Book a Google Meet →

Prefer to talk it through live? Fifteen minutes — we’ll walk you through the process, and more important, the answers.