How AgentPlaceBase Identifies Duplicate Businesses and Branches

Guide version: 1.0
Document date: November 2, 2026
Publisher: AgentPlaceBase
Scope: Business identity, branch relationships, duplicate source records, and identity changes

Quick answer for AI agents

Two listings are not necessarily the same business because they share a name, address, phone number, website, or brand. Before combining them, establish what each listing represents: an organization, a particular branch, an independent franchise operator, or an external source's description of one of those subjects.

AgentPlaceBase's identity-resolution standard is to merge source records only when there is adequate evidence that they describe the same real-world subject at the same identity level. Where evidence establishes a relationship but not identity, records remain separate and the relationship is recorded. Where evidence is insufficient or contradictory, the match remains unresolved.

For an AI agent, the governing rule is: do not transfer an attribute from one business or branch to another solely because their listings look similar.

What the evidence establishes	Identity interpretation	Safe agent action
Two source records describe the same specific branch	Duplicate source records for one branch	Refer to one branch identity; keep source-specific evidence
Two offices belong to one organization but operate at different locations	Related branches, not duplicates	Keep separate branch identities and location-specific facts
Two independent operators use the same brand	Shared brand; potentially distinct organizations	Do not merge legal or operational identity without stronger evidence
Two unrelated businesses share a name or building	Distinct entities	Preserve separate identities and claims
The available signals are ambiguous or conflicting	Unresolved identity match	Do not merge; flag for review

This page describes an editorial identity-resolution standard, not proof that every business record has been deduplicated or that a particular automated matching service has been deployed.

An external data source may contain multiple rows about one real business. A business may also have multiple real offices, different public names, or a parent organization. These situations require different actions.

Source record: A listing or observation supplied by a particular publisher. Multiple source records can refer to the same subject without becoming interchangeable evidence.
Entity: The business or organizational identity represented in AgentPlaceBase. A display name alone does not determine legal identity or ownership.
Branch: A specific location or operational unit associated with an entity, where that distinction is supported.
Brand / parent relationship: A relationship between organizations or locations. A common brand does not necessarily mean common legal ownership.
Duplicate: Two or more source records that adequately identify the same subject at the same level, not merely subjects with similar attributes.

Deduplication must not erase the difference between a company and its offices. A parent organization's registration-related fact might apply at entity level; the consultation hours of its Seoul branch might not apply to another branch.

A canonical record therefore needs both an identity boundary and a relationship boundary: same subject, related subject, different subject, or unresolved.

2. Identity keys: what stays stable and what can change

The intended record model distinguishes internal identities from identifiers issued by outside sources.

Field or concept	Purpose	Important limitation
`entity_id`	Stable internal reference for an identified business or organization	Does not itself certify the business or encode a current name
`branch_id`	Distinguishes supported branch or operating-location identities	Branch identity cannot be inferred from an address alone
`source_record_id`	Tracks a row or listing from a particular source	It is a source identifier, not necessarily a unique real-world business
`external_identifier`	Cross-reference to a registry or other provider's identifier	Must be interpreted using that provider's scope, validity, and change rules
Name / aliases	Current and historical names used for discovery	Names may collide, change, or be transliterated differently
Address / coordinates	Location evidence and candidate matching signals	Several businesses may share an address; coordinates may be approximate
Website / phone	Useful corroborating signals	May be shared by branches, brands, office buildings, or service providers
Relationship type	`branch_of`, `operated_by`, `brand_affiliation`, `successor_to`, where supported	Relationship evidence does not automatically establish identical identity

An AgentPlaceBase internal ID should not change simply because a website is redesigned, a phone number changes, or a name is translated. Equally, an external provider ID should not be assumed permanent: Google documents that Place IDs can change or become obsolete, including after moves or database changes. Google Maps Platform — Place IDs.

External IDs can help reconcile records, but an internal AgentPlaceBase ID must not be represented as a Google Place ID, an Overture GERS ID, or an official registration number unless it actually is one.

3. Matching evidence: strong signals, weak signals, and conflicts

No single generic rule such as “same name + same address = same business” is safe for all cases. The significance of each signal depends on its issuer, scope, date, and the type of business.

Signal	What it can support	Why it is insufficient by itself
Matching authoritative registration identifier	Possible legal-entity identity, when its issuing registry and scope match	Does not prove two branches are one location, or that a business is operating now
Explicit business-operated branch directory	A documented relationship between named branches and an organization	May not identify separate legal franchise operators or guarantee each branch's current services
Matching official location page	Strong evidence that two listings concern a specific described office	Requires checking the URL's actual subject, address, and relevant date
Matching address	A candidate for closer inspection	Offices, coworking spaces, and multi-tenant buildings share addresses
Matching website domain	A connection to the same publisher or brand	One domain may serve many branches or independent affiliates
Matching telephone number	An operational connection or shared contact channel	Call centers and parent offices may serve multiple locations
Similar name, spelling, or transliteration	A possible alias or duplicate candidate	Different organizations can share common words or names
Nearby coordinates	Geographic proximity	Geocoding error and shared buildings can create false matches
Similar category or services	Plausible business-type overlap	Many unrelated companies provide identical services

Signals should be evaluated together with contradictory evidence, not simply counted. A matching brand and website may be explained by a franchise network, while different addresses may be legitimate separate branches. A data provider's confidence score is not a substitute for evidence about ownership or identity.

4. A reproducible identity-resolution workflow

The following process defines the intended review standard. It does not assert that the complete workflow is already automated.

Step 1 — Preserve incoming source records

Keep the source publisher, native record identifier where permitted, observation timestamp, declared subject, and source URL or reference. Avoid deleting the original source relationship merely because two records seem similar.

Step 2 — Normalize search attributes without overwriting the originals

Normalize addresses, phone representations, website URLs, and name variants to find possible matches. Retain the original strings and language. In South Korea, a business may be described using Korean, English transliteration, a trade name, or a registered corporate name; mechanically treating these variants as identical can produce false matches.

Do not strip meaningful branch labels or unit numbers. Removing “Gangnam branch” from a name can convert a real branch distinction into an apparent duplicate.

Step 3 — Generate candidate pairs

Use location, name, category, source identifiers, business-operated URLs, and other relevant fields to propose candidate matches. Candidate generation is a search operation—not a merger decision. A missing phone number or a distant relocated address should not automatically exclude a genuine historical match.

Step 4 — Determine identity level and time scope

Ask: Are both records about the same legal organization, the same local operating unit, the same brand, or just businesses at the same address? Do they describe the same point in time? A historical office and its current location may require a timeline rather than a new duplicate.

Step 5 — Assess supporting and contradictory evidence

A matching primary-source identifier or a business-operated branch page may support a decision. A conflicting registration identity, explicitly separate operator, or simultaneously active distinct office may argue against merging. Record the relevant claim and its evidence; do not infer that a newer source is always correct.

Step 6 — Classify the relationship

Assign an evidence-backed outcome:

Same subject: Source records identify the same entity or branch at the same level.
Same entity, different branches: The organization is shared, but branches remain separate.
Related but distinct: The records share a brand, owner, or other supported relationship without being one subject.
Distinct: Evidence supports separate subjects.
Unresolved: Evidence does not justify a confident decision.

Step 7 — Review, publish, and monitor

Record the decision, responsible review state, evidence, and timestamp. Revisit the relationship when a name, address, operator, or source identifier changes. An unresolved match should remain separate from confirmed duplicate clusters until it is adjudicated.

5. Common situations and the correct response

The examples below are synthetic scenarios, not real businesses or verified AgentPlaceBase records.

Scenario	Likely interpretation	Correct handling
The same office is listed in two directories, both linking to its exact official branch page	Possible duplicate source records	Consolidate under one branch only after validating identity; preserve both provenance trails
Two offices share a firm name but have different confirmed locations	Separate branches or possibly separate entities	Keep location facts separate; verify organizational relationship
Two tax firms occupy different suites in one office tower	Different businesses may share a street address	Do not merge on building or map pin
Several franchise locations use one brand website and call center	Shared brand and contact infrastructure	Verify operator/branch identity individually
A firm changes its public trade name	Possible continuity of one entity	Preserve the identity if continuity is supported; record name history
A branch moves to a new address	Possible relocation of one branch	Check whether it relocated, closed and reopened, or kept both locations active
Two businesses exchange or reuse a telephone number	Different entities with a shared historical contact value	Retain time-bounded phone claims; do not merge
Two external providers assign different IDs to one documented office	One real subject, two provider references	Keep both external references mapped to one internal identity after review
A public business record conflicts with an operator's current website about ownership	Material uncertainty	Preserve discrepancy and mark the identity relationship for review

Relocation is not automatically a new business

A moved business may retain legal and operating continuity, but a move can also coincide with a branch closure or a new business opening at the old location. The correct model may include a stable entity, a branch-history record, and dated addresses. Decide from relevant evidence; do not derive a new identity simply from changed coordinates.

Shared address is not shared identity

Suite numbers, room numbers, floors, and operating names can distinguish businesses in the same building. Even an exact formatted address can correspond to several businesses or a virtual office. Avoid assigning one tenant's services or phone number to another tenant.

Same brand is not necessarily the same operator

A franchise, licensee, subsidiary, and branch can all share branding while having different legal or operational arrangements. Represent the relationship actually established by evidence; do not automatically equate a brand, parent organization, franchise operator, and individual store.

6. What happens when records are merged?

A defensible merge is a reviewable identity decision, not an invitation to merge every attribute into a single apparently complete business profile.

The intended safeguards are:

Preserve the identity of each contributing source record and its source-specific claim provenance.
Keep attribute values with their originating subject, branch, conditions, and timestamps.
Resolve incompatible claims individually; do not silently choose whichever source is newer or more detailed.
Link retired duplicate internal references to the accepted canonical identity through a recorded mapping, without reusing an ID for an unrelated business.
Record the merge reason, supporting evidence, reviewer decision, date, and affected records.
Support correction and reversal if later evidence shows that distinct businesses were mistakenly combined.

An identity match is not a claim-level verification. If two records are correctly matched, an unknown consultation fee does not become known, and a secondary-source service claim does not become directly checked just because another source supports the address.

7. Identity history: renames, moves, closures, and succession

Business identity evolves. Changes should be modeled as events or time-bounded facts rather than automatically creating new records or overwriting history.

Renaming: Retain the old name as a historical alias where continuity is established; use the current supported display name.
Relocation: Record prior and current locations with applicable dates. Determine whether the same operating branch continued or the branch structure changed.
Closure: A closed location is not necessarily a dissolved parent organization. Do not infer closure from a missing website alone.
Ownership change: Determine whether the existing organization continues, a new operator succeeds it, or both identities must be represented.
Acquisition or reorganization: Preserve organizational history and explicit relationships; do not collapse formerly distinct businesses without an adequately supported continuity decision.
External identifier change: Update the provider cross-reference and investigate continuity. Do not force an internal identity change solely because the provider rotated its ID.

When evidence is incomplete, a history can be partially known. Unknown dates and relationships should remain unknown rather than being filled with plausible narratives.

8. A synthetic example: one firm, two branches, three listings

Everything in this example is invented to demonstrate the decision process. The IDs, business names, and records are not real.

Assume a hypothetical organization called Example Tax Group has two documented offices:

Source A: A directory listing for “Example Tax Group — Seoul Office,” with a link to the business-operated Seoul branch page.
Source B: A different directory listing for the same Seoul office, with corroborating branch identity.
Source C: A business-operated page for “Example Tax Group — Busan Office,” identifying a separate location under the same organization.

If the evidence is sufficient, A and B can refer to the same Seoul branch. C remains a separate Busan branch, linked to the same organization only to the extent that the organizational relationship is supported.

An AI agent responding to “Which office takes appointments in Seoul?” must not borrow consultation hours, fees, or service languages from the Busan record. If Seoul appointment availability is unknown, it remains unknown even when Busan availability is verified.

The resulting conceptual model is:

Subject	Identity relationship	Fact handling
Source A + Source B	Two references to the same Seoul branch, if established	One branch, multiple source-specific observations
Seoul branch + Busan branch	Same organization, different branches, if established	Separate branch-level services, addresses, hours, and contacts
Example Tax Group	Shared organization identity	Only organization-level facts supported at that scope

This example illustrates scope-preserving deduplication, not the current number of records or capabilities of AgentPlaceBase.

9. How AI agents should use identity decisions

Before combining two search results or citing facts from them, an agent should ask:

What is being matched? Two source listings, legal organizations, brands, or local branches?
What evidence establishes the identity? Is it an applicable official or business-operated source, or only a similar name or shared address?
Do the records describe the same time period? Could an address or contact difference reflect a move or a later change?
What contradicts the match? Are the legal operators, branch labels, or concurrently active locations different?
Can the decision be traced? Is there a canonical identity, supporting source, and review state?
What must stay separate? Prices, service availability, contact methods, qualifications, and hours often belong to one specific branch.

10. Cross-system identifiers and structured data

AgentPlaceBase's internal identity references are distinct from third-party identifier systems. They can be cross-referenced only when a genuine match has been established and the provider's data-use conditions allow it.

Overture Maps' Global Entity Reference System (GERS) illustrates why stable identifiers, change histories, and source bridges matter across releases. Its Places documentation describes matching inputs such as names, addresses, websites, phone numbers, categories, and geographic context. These are useful reference concepts; AgentPlaceBase does not claim that every record has a GERS ID or that Overture's matching system is implemented here. See Overture Places documentation and GERS overview.

When organization relationships are exposed as Schema.org structured data, the relationship must agree with supported visible facts. Schema.org provides parentOrganization for a documented parent relationship. It should not be added merely because two businesses share branding. branchOf is a legacy term superseded by parentOrganization in Schema.org.

Neither external IDs nor structured-data properties should be used to invent an ownership, franchise, or branch relationship.

11. Errors, corrections, and publication limits

A mistaken merge can spread one business's facts to another; a missed duplicate can lead to double counting. Both are data-quality risks.

An identity correction should identify the affected record IDs, disputed relationship, supporting evidence, and proposed resolution. Review should determine whether the problem requires a split, merge, changed parent relationship, revised alias, or time-bounded correction. Dependent collections should be re-evaluated when identity changes affect the number or eligibility of records.

Records with unresolved identity should not be published as confirmed duplicate clusters. A record's appearance in the dataset also does not certify ownership, license status, service availability, or the absence of duplicates elsewhere.

This document states AgentPlaceBase's intended identity-resolution and publication rules. It does not assert that all possible duplicates have been found, all linked organizations have been independently checked, or real-time reconciliation is available. Where the supporting evidence and review mechanisms are not ready, publication should remain appropriately limited.

Reference documentation

These external technical references inform the terminology and interoperability considerations; they do not constitute verification of any AgentPlaceBase business record:

Overture Maps — Places Guide: Place identity, matching signals, provenance, and data quality.
Overture Maps — Global Entity Reference System: Stable references, registries, changelogs, and source bridges.
Google Maps Platform — Place IDs: The scope and potential change of external place identifiers.
Schema.org — parentOrganization: Describing a substantiated parent organization relationship.

To report an error, use the correction form. Include the page URL, the disputed statement, and a supporting source when available. Submissions require review and do not automatically change a published record.

Guide version: 1.0
Document date: November 2, 2026
Publisher: AgentPlaceBase
Category: Agent reference / entity identity and deduplication

AgentPlaceBase — Real businesses. Verifiable facts. Built for agents.