AI Entity Resolution: Link the Right Business Record

A service request arrives from “Northstar Services.” Your register contains two companies with similar names, a former trading name, and a shared accounts mailbox. An AI assistant can produce a plausible customer ID for any of them. The difficult question is whether the evidence supports that particular association.

An AI entity resolution workflow compares incoming information with existing records to identify the same real-world person or organization. For operational intake, the useful output is an approved source-to-target link—not a polished explanation, an automatic master-record merge, or permission to act for that entity.

This guide presents a recommended design for organization and customer matching. The fields, states and example are illustrative implementation choices, not a description of a deployed customer system.

Separate matching from merging and authorization

Three decisions need different authority:

• Match: do these records describe the same entity?
• Associate: may this incoming request reference that existing record for this business purpose?
• Merge or act: may someone combine master records, change account data, disclose information or start work?

A positive match does not establish the latter permissions. A request can belong to an existing customer while still lacking an authorized requester, approved scope or required documents. Keep record association separate from payment-detail changes and identity verification.

AWS Entity Resolution documentation describes rule-based exact or fuzzy matching and machine-learning comparison of records with variations or missing fields. These are matching techniques; your process must still define what evidence permits an operational association.

Use the broader AI data validation workflow for surrounding input and business-rule checks. The specific design here fills the gap between “validate the customer” and selecting one of several plausible customer records.

Give the model a bounded comparison task

Start with an authoritative register, a declared entity type and an authorized account or tenant boundary. Preserve the incoming source and the original values. Create normalized comparison fields without overwriting the evidence: for example, a normalized company name alongside its source spelling.

Do not remove distinctions simply because they complicate matching. Legal suffixes, branch identifiers and regional account scopes may matter. A shared telephone number or mailbox is a possible relationship, not necessarily a unique identifier.

Divide responsibilities explicitly

• AI: extract name variants and relevant evidence, compare supplied candidates and identify agreements, contradictions and unknowns. Require source references for its observations.
• Rules and retrieval: enforce access scope, generate eligible candidates, validate candidate IDs and source references, and apply explicit hard-stop conditions.
• Data steward: decide ambiguous cases, obtain missing evidence and authorize exceptions within an assigned remit.
• Authoritative application: persist the approved association and enforce permissions, version checks and duplicate-operation controls.

Supply only the necessary authorized attributes to the model. Do not expose a larger register to improve its guessing. Require its selected ID to belong to the supplied candidate set; a well-formed but invented ID must fail validation. A structured output contract helps make the comparison machine-readable, but does not establish that the match is correct.

Keep candidate coverage visible

Record the retrieval method, scope, filters and known coverage gaps. A nearest-name result is not proof that the right entity was considered. An empty result is not permission to create a new customer; apply the separate search-completeness gate before relying on a negative finding.

For positive decisions, inspect competing candidates and contradictions, not just the first high-scoring name. Adding a newly discovered candidate should invalidate a pending decision when it could materially change the comparison.

Use an evidence matrix, not one confidence cutoff

Define eligible automatic associations using tested business rules. Leave that lane disabled until representative cases support it. A model’s self-reported certainty is not sufficient evidence, and a matching service’s score should be interpreted using that service’s documented meaning.

OpenRefine’s reconciliation manual distinguishes suggested candidates from matching judgments and notes that services use different scoring methods and ranges. Do not turn an arbitrary similarity score into a universal probability of correctness.

Choose discriminating evidence appropriate to the task and privacy constraints. Do not collect sensitive identifiers merely to make matching easier. Where evidence remains insufficient, “unresolved” is a valid outcome, not a failure the model should repair through inference.

Preserve a match-decision record

Keep the comparison outside the conversational summary. The following is a reusable specification for your implementation, not a promise that any particular product automatically stores every field.

Reference sensitive evidence in its approved store rather than copying it into every task or log. Show reviewers enough to compare candidates without revealing unrelated records or another team’s restricted data.

Run the decision through explicit states

A practical state model is received → candidates ready → review required or rule qualified → association authorized → commit pending → linked. Evidence holds, rejection and correction review are separate states with named owners.

Hold and resume deliberately

Invalid model output returns to validation handling; it must not create an association. Missing or conflicting evidence creates a steward task. An unavailable register creates a retrieval hold. Human rejection closes the proposed match, not the original service request; return that request to its appropriate intake route.

A read-only retry may be eligible after a transient source failure under your connector’s documented policy. Preserve the decision ID and reason. Re-run the comparison when evidence changes; do not endlessly regenerate the same explanation while calling the uncertainty resolved.

Commit only the approved association

Before writing, the authoritative application must recheck the approved source, target and relevant versions. Bind the authorization to that association. If a customer record was replaced or the incoming request changed materially during review, return to assessment rather than silently reusing the approval.

Use an application-supported conditional update or equivalent coordination mechanism to prevent another worker from overwriting a different association. Reuse one stable operation identity for a retry of the same approved link. If the write times out, read the actual association and operation receipt before repeating it. A confirmed identical link can complete reconciliation; an unresolved outcome remains pending.

Where the destination cannot enforce the required coordination or version check, use a controlled manual association step. Do not describe a workflow status change as proof that an external record was updated.

Correct without erasing the incident

A wrong link enters correction review. Identify dependent tasks, restrict further processing where authorized, obtain approval for the corrected association, and verify each affected system’s actual state. Do not delete the original comparison or assume unlinking reverses disclosures, messages or completed work. Close the correction only after the affected owners acknowledge the disposition of those consequences.

Worked example: two similar companies

Constructed example: a request says “Northstar Services” and provides a shared accounting mailbox. Candidate A is Northstar Services Ltd; candidate B is Northstar Service Operations Ltd. The sender’s wording resembles A, but the mailbox appears on both records. No verified account reference is present.

The AI lists both candidates and marks the mailbox as nondiscriminating. Rules block automatic association. A steward requests the approved customer reference through the existing verification channel; the response identifies B and agrees with its service location. The steward records why A was rejected and authorizes association to B only.

Before commit, the application verifies that B remains active and that the request is still unlinked. It writes the association with the preserved operation identity, then reads it back. The request proceeds to its normal scope and requester-authorization checks. No company records are merged and no bank details are changed.

If the reference instead conflicts with both candidates, the outcome stays unresolved. If the write response is lost, the application reconciles the existing link rather than creating a replacement customer.

Test false links, missed links and operational closure

ONS guidance on linkage quality distinguishes false links from missed links and explains that clerical review is constrained by the available matching evidence. Treat a reviewer decision as evidence to assess, not infallible ground truth.

• Precision: correct proposed or accepted links divided by evaluated links in that defined cohort. Report the labeling method and review coverage.
• Recall: recovered true links divided by known true links in a labeled test set. Reviewing accepted matches alone cannot establish missed-link performance.
• Operational measures: unresolved-case age, reviewer disagreement, time to approved association, correction rate and downstream wrong-record incidents.

Test same-name companies, shared contact details, aliases, renamed organizations, inactive records, conflicting identifiers, missing candidates and unauthorized scopes. Include stale approvals, simultaneous workers, write timeouts and rejected matches. Evaluate both individual links and affected clusters if your matcher groups records; one bad association can contaminate a larger group.

Set acceptance criteria from the consequence of a wrong association and the quality of representative evidence. Do not copy an arbitrary percentage from another process, or report only easy automatic matches while excluding held cases.

Where Workhint fits

The Workhint Workflow Engine describes approval routing to defined roles and requiring information before work progresses. Those building blocks are relevant to assigning a steward and collecting the information needed for a match decision.

The workflow automation software solution describes structured forms, conditional routing, review stages and roles. It provides a useful starting point for mapping the human review around an ambiguous association.

Validate the proposed review flow and required evidence fields during configuration. The matching algorithm, authoritative register, external write, conditional-update guarantee and correction mechanism need separate capability checks; these pages do not establish them. Keep unsupported execution steps in their authoritative systems rather than assuming an approval workflow supplies a native entity matcher.

Frequently asked questions

Is entity resolution the same as duplicate detection?

They overlap, but the task here is linking an incoming request to an existing entity. Detecting potentially duplicate master records does not authorize merging them or consolidating the requests attached to them.

Can a high similarity score authorize an automatic link?

Not by itself. Verify what the score represents, test the qualifying policy on representative data, check contradictions and apply the separate permission rules. Keep ambiguous or consequential cases in review.

Should the LLM search the entire customer database?

Only use the authorized retrieval scope and necessary attributes. Candidate generation and access controls belong in the application boundary. A model should not expand access to compensate for missing evidence.

What happens when none of the candidates fits?

Record whether the search was adequate and why candidates were rejected. Keep unresolved evidence distinct from a supported no-match finding, then use a separately authorized new-record process if appropriate.