Entity disambiguation: repair one identity graph
Entity disambiguation repairs a directly evidenced set of contradictory or missing identity relationships across visible copy, metadata, and matching JSON-LD. Freeze the supported reference, change only the listed locators, retain self-canonicals and unrelated content, validate the deployed values, and preserve rollback. The patch makes the owned publication internally consistent; it does not guarantee provider ingestion or an answer outcome. Site traffic is a separate outcome and is not required.
What evidence is required before an identity patch?
Start with a frozen reference record and reproducible contradiction or missing relationship. A missing mention, citation, or recommendation alone does not select this fix.
The synthetic handoff contains six actionable rows from the Find ledger. The other nine assertions already align and remain outside the patch.
What does the worked synthetic identity patch change?
SYNTHETIC EXAMPLE — Harborlight, Harborlight Systems, Inc., Harborlight Atlas, every URL, prompt, surface, assertion, patch, and outcome below are fictional; this is not RankEcho data, customer data, provider evidence, or a benchmark.
C01–C06 contain two visible-copy changes, two metadata changes, and two JSON-LD changes. Each row retains the before value, deployed value, acceptance state, and rollback pointer.
| Change | Layer and locator | Before | After | Acceptance and rollback |
|---|---|---|---|---|
| C01 · I02 | metadata · meta[property='og:site_name'] | Harbor Light | Harborlight | accepted; rollback ready |
| C02 · I04 | visible-copy · main h1 | Atlas AI | Harborlight Atlas | accepted; rollback ready |
| C03 · I07 | visible-copy · main p[data-operator] | Atlas is operated by Harborlight Analytics LLC. | Harborlight Atlas is operated by Harborlight Systems, Inc. | accepted; rollback ready |
| C04 · I09 | json-ld · Organization.legalName | Harborlight Analytics LLC | Harborlight Systems, Inc. | accepted; rollback ready |
| C05 · I14 | metadata · meta[property='og:url'] | https://harborlight.example/platform/atlas | https://harborlight.example/atlas | accepted; rollback ready |
| C06 · I15 | json-ld · SoftwareApplication.url | Missing | https://harborlight.example/atlas | accepted; rollback ready |
How do visible copy, metadata, and JSON-LD stay in parity?
Visible statements remain the human-readable source of truth. Metadata must describe those statements, and JSON-LD must represent the same named organization, product, operator, category, and URL relationships without adding hidden claims.
Google's guidelines support visible-markup parity and documented Organization or site-name fields. They do not establish a special AI schema or an identity-based citation mechanism.
Which URL and canonical boundaries remain fixed?
C05 repairs an incorrect og:url value and C06 supplies the matching product-node URL. Every page keeps its existing 200 response, public role, route, and self-canonical; no redirect or canonical consolidation is part of this patch.
Do not use sameAs for a merely related company, publication, founder, or product. Do not guess external profiles or add a URL that the operator cannot verify.
Which deterministic validation and parity checks accept the patch?
Acceptance is deterministic and operator-controlled. All six changes must align, all five parity checks must pass, every surface must retain useful initial HTML and a self-canonical, and all rollback records must exist.
| Check | Pass condition | State | Evidence |
|---|---|---|---|
| P01 · Visible identity parity | Brand, product, operator, and category wording match the five frozen relationships. | passed | synthetic-evidence/entity/acceptance/P01 |
| P02 · Metadata parity | Title, description, site name, and canonical agree with visible identity and registered URLs. | passed | synthetic-evidence/entity/acceptance/P02 |
| P03 · JSON-LD parse and parity | Organization and SoftwareApplication nodes parse and match the visible names, operator, category, and URLs. | passed | synthetic-evidence/entity/acceptance/P03 |
| P04 · Identity URL references | Every visible, metadata, and JSON-LD URL resolves to the intended fictional entity record; no guessed profile is added. | passed | synthetic-evidence/entity/acceptance/P04 |
| P05 · Scope and rollback | Only C01–C06 changed, each saved before value can be restored, and unrelated content remains byte-identical. | passed | synthetic-evidence/entity/acceptance/P05 |
How is deployed delivery checked?
Fetch each exact URL after deployment, parse the initial HTML and JSON-LD, and compare the visible and machine-readable values with the frozen relationships. A browser-only value does not satisfy the initial-HTML check.
| Surface | Response | Initial HTML | Self-canonical | JSON-LD |
|---|---|---|---|---|
| S01 · homepage | 200 | present | retained | parses |
| S02 · about-page | 200 | present | retained | parses |
| S03 · product-page | 200 | present | retained | parses |
| S04 · documentation-page | 200 | present | retained | parses |
What causes acceptance to fail or roll back?
Fail acceptance when a value still disagrees, JSON-LD does not parse, markup introduces a hidden claim, an unrelated byte changes, a URL points to the wrong entity, a self-canonical changes, or any required capture is unavailable.
Restore the saved before version when the patch broadens scope or breaks page delivery. A later answer outcome is recorded in Prove and never substitutes for deployment acceptance.
What does the fix establish about AI outcomes?
It establishes only that the six owned-publication defects are corrected under the frozen reference. Google notes that normal eligibility and structured data do not guarantee appearance in Search AI features.
The patch does not establish provider ingestion, entity confidence, ranking, mention, citation, recommendation, referral, conversion, or causation.
How does Fix hand off to the outcome classification?
Prepare the bounded patch in Fix Engine, preserve the accepted shipment time, and carry the unchanged prompt, context, mention, citation-role, owned-host, and recommendation rules into Prove.
The next route classifies the complete fixed panel. It reports unavailable and failed cells separately and does not calculate a rate.
Who maintains this guide?
Written and maintained by Abiot Y. Derbie. Published 2026-09-07; sources checked 2026-09-07; last updated 2026-09-07. The patch is synthetic.
Recheck visible content, metadata, markup requirements, and effective identity records before applying the method. Send material corrections through the contact page.
Sources reviewed
Material technical claims below were checked against primary provider documentation. The sources support the documented control or signal, not a guarantee of indexing, ranking, an AI impression, or a citation.
5 claim-level source records
| Claim reviewed | Official source | Review record |
|---|---|---|
| Google's Organization structured-data documentation defines properties including name, alternateName, legalName, url, logo, and sameAs, and advises using the same organization name and alternate name used for the site name. | Google Search: Organization structured data | Checked 2026-09-07 · Current Google Search Organization documentation · Primary-source Search documentation; it supports a bounded consistency check, not a universal entity graph, an AI-system identity verdict, or a citation mechanism. · Confidence: High |
| Google's general structured-data guidelines say markup should represent visible page content, be complete for the represented item, and avoid misleading information; correct markup does not guarantee a search feature will appear. | Google Search: structured-data general guidelines | Checked 2026-09-07 · Current Google Search structured-data guidelines · Primary-source Search guidance; visible-markup parity is a deterministic acceptance check, not evidence of AI retrieval, ranking, mention, citation, or recommendation. · Confidence: High |
| Google's site-name documentation recommends WebSite structured data on the home page and defines name, alternateName, and url properties for expressing a preferred site name. | Google Search: site names | Checked 2026-09-07 · Current Google Search site-name documentation · Search-specific documentation; it does not define a universal brand identity graph, provider confidence, or an answer-system ingestion or selection mechanism. · Confidence: High |
| Google says normal Search eligibility applies to AI Overviews and AI Mode, no special AI markup is required, responses and links may vary, and eligibility does not guarantee crawling, indexing, serving, or appearance. | Google Search: AI features and your website | Checked 2026-09-07 · Google Search documentation last updated December 10, 2025 · Primary-source Search guidance; it does not say that an identity-field correction causes an AI mention, citation, recommendation, or other answer outcome. · Confidence: High |
| The Open Graph protocol defines og:site_name as the overall site name and og:url as the page object's canonical or permanent graph identifier. | Open Graph protocol | Checked 2026-09-07 · Current Open Graph protocol vocabulary · Protocol-field semantics only; the vocabulary does not establish provider consumption, entity resolution, ranking, mention, citation, recommendation, or another outcome effect. · Confidence: High |
Frequently asked questions
Only when a frozen supported reference and exact deployed captures establish contradictory or missing identity relationships the operator controls.
No. The represented identity and material relationships should match visible content and the applicable structured-data guidance.
No. This bounded example keeps every route and self-canonical. It repairs visible wording, metadata, and matching JSON-LD only.
No. Consistency is a deterministic publication check, not evidence of provider ingestion, ranking, citation, or recommendation.
Roll back when scope broadens, a value remains unsupported, markup no longer matches visible content, delivery breaks, or the saved acceptance evidence cannot be reproduced.