This is the central lesson of the chapter. Everything else is detail. If your practice cannot be confidently resolved as a single real entity, assistants will leave you out, and no amount of content will fix it.
What an entity is
To a machine, your practice is not a website. It is an entity: a thing in the world with attributes, assembled from many records. Systems build that picture by clustering everything they find and deciding which records describe the same thing.
Your name, address, and phone are the keys used for that clustering. So entity resolution is chapter one NAP lesson, seen from the machine side.
Why assistants are unforgiving
This is the point that changes priorities. A traditional results page can include ten links and let the user decide. An assistant naming three practices has made an assertion, and it is accountable for it.
So when resolution is uncertain, the incentives differ sharply:
- A search engine can rank you lower and still show you.
- An assistant has to either assert something it is unsure of, or name a practice it can verify.
It picks the second. This is why practices with contradictory data do not appear in position four of an AI answer. There is no position four. They simply are not mentioned, and the practice never learns why.
In health topics the caution is stronger still, because a wrong medical recommendation is a serious failure. Expect less tolerance for ambiguity here than in any other category.
What creates ambiguity
- Different phone numbers across sources, usually old call tracking numbers.
- Address variants, especially a missing suite number.
- Practice name variants after a rebrand, or names with keywords appended in some places.
- Duplicate listings for one office.
- Orphaned provider profiles for departed clinicians.
- A closed location still listed as open.
- Conflicting hours.
- Conflicting service claims, where one directory lists treatments you no longer provide.
- An old address persisting in NPI or credentialing data.
Notice that every item is something covered in chapters two, three, and four. Nothing here is new work. The point of this lesson is that the AI stakes are higher than the search stakes, so the same errors cost more than they used to.
How to build a resolvable entity
- Define one canonical record per office, as in chapter three. Without this you cannot be consistent, only lucky.
- Propagate it upstream first: aggregators, NPI, credentialing, then platforms, then the long tail.
- Eliminate duplicates. One office, one profile.
- State the same facts on your own site, in text, matching character for character.
- Add structured data so the facts are explicit rather than inferred. The next lesson covers which types.
- Link your profiles and your site together, so the connection between records is stated rather than guessed.
- Keep it aligned over time. Consistency is a maintenance property, not a project.
How to tell whether you are resolvable
Three quick tests:
- Ask an assistant for your address, phone, and hours. If it hesitates, gives variants, or gets it wrong, resolution is failing.
- Use a citation-first engine and read which sources describe you. Contradictions between them are your work list.
- Search each phone number and address variant in quotes and see how many versions of your practice exist in public.
The reframe
Most practices think of data accuracy as hygiene, a tidy-up job with no upside. That was arguably true when search results tolerated ambiguity. It is not true now.
Consistency has become the entry requirement for the fastest-growing discovery channel. It is the least glamorous work in this course and the highest-leverage, and it is why chapter three sits where it does.
Next, the structured data that makes your facts explicit.