How Superintelligence Works | Agent Entity Resolution — Durable IDs, False Merges and Safe Decisions

An AI-assisted agent should resolve identities by comparing permitted source records against a clearly defined notion of “the same entity”, using durable identifiers where possible and reserving uncertain cases for human review. Similar names, identical addresses and a confident model explanation are not sufficient to merge sensitive accounts or act on behalf of someone. A safe resolver returns a traceable match, a defensible nonmatch or an explicit unresolved result, and keeps that decision separate from permission to update a record.

This specialist guide explains how to build that boundary: create candidate pairs without silently losing genuine matches, compare independent evidence, interpret false matches and misses with honest denominators, restrict automatic merges, and preserve the source records needed to correct a mistake. The worked examples are hypothetical teaching data, not measured deployments. Entity resolution belongs to present-day data systems and AI-assisted applications; it does not imply that artificial superintelligence exists.

Choose a learning route

Start with the entity and error-cost definition if you are new. Builders can go to candidate generation, scoring and the abstain band. Reviewers can study the 120-pair confusion matrix and the three-supplier exercise. Readers transferring the method to study and research can start with the six-record practice and document-version challenge.

Contents

• 1. The real task: decide which records name the same entity
• 2. Name the entity type and the cost of a false match
• 3. Make durable identity different from names and labels
• 4. Define a resolution contract before applying a model
• 5. Candidate generation is a recall-versus-workload decision
• 6. Normalise carefully without manufacturing identity
• 7. Score evidence without mistaking a probability for a fact
• 8. Introduce an explicit abstain band
• 9. A complete worked example: 120 proposed pairs
• 10. Use denominators and cost to avoid a misleading victory
• 11. Pairwise scores are not automatically a coherent identity graph
• 12. A second worked case: three similar supplier names
• 13. Preserve provenance, consent and least privilege
• 14. Diagnose common failure patterns before choosing a repair
• 15. Measure production behaviour without circular ground truth
• 16. Design a safe implementation and release sequence
• 17. Independent practice: six records and three questions
• 18. Changed-context transfer: matching publications, not people
• 19. Useful limits and responsible next steps

1. The real task: decide which records name the same entity

Entity resolution asks whether two records refer to the same person, organisation, document, transaction or other entity. An AI agent may suggest that two names look alike, but a consequential merge needs stronger evidence: the record type, its provenance, durable identifiers, the population being compared and a reversible review path. A similarity score does not grant authority to merge accounts, pay invoices or overwrite someone’s details. The workflow should distinguish a candidate link, a reviewed assertion that two records match, and a permitted change to a source system. These are different decisions with different owners.

The problem appears in ordinary situations. A school office receives a parent email with a shortened student name, a customer service system encounters two similar businesses, and a research assistant downloads the same paper under two filenames. In each case, matching creates convenience; merging incorrectly can create a much larger problem. The student may receive another child’s information, a payment could be sent to a similarly named supplier, or a citation may appear to support a document it never described. The safest general rule is to identify the entity first and act only after the evidence supports the exact action.

Do not confuse entity resolution with finding similar text. Search is allowed to return several potentially useful results. A merge, disclosure or irreversible edit generally requires one correct referent or an explicit decision to abstain. Resolution is therefore a controlled inference step between retrieval and action, not a decorative classifier placed at the end of an agent chain.

2. Name the entity type and the cost of a false match

Start by writing down what the candidate records are about. A person, a legal organisation, a physical location, a purchased product and a document version are different entity types. Even within one type, identity can change over time: a school student can change a preferred name; a business can change its registered name; one physical shop can move; an academic paper can be revised. Decide whether the task requires the same legal entity, the same physical premises, the same account, or a close textual description. A matching algorithm cannot solve a question that the application has not defined.

Make the two mistakes explicit. A false merge occurs when different entities are declared identical. A missed match occurs when two records of the same entity remain separate. The harms are often asymmetric. Failing to recognise two duplicate public articles may waste editorial effort; joining two families’ private profiles may disclose sensitive data. Because error costs differ by use, no universal similarity threshold is appropriate. A search suggestion can tolerate more uncertainty than a bank-account change, an enrolment correction or a medical record update.

A robust contract states who may view suggestions, who may confirm identity, what evidence is necessary, whether the outcome is reversible and how disputes are resolved. In education and everyday work, this encourages a useful habit: ask which person or thing an answer refers to before trusting the answer. An agent should not treat every plausible name as permission to open the matching record.

3. Make durable identity different from names and labels

A stable internal identifier is the cleanest link when the same source system already assigns one. A school roster might use a student record ID, while a customer system uses a customer ID. The system should normally join on those source-controlled identifiers only when their scope and issuer match. The number 4321 in database A need not represent the same person as 4321 in database B. Carry an issuer or namespace alongside the value; otherwise an apparently exact match can be one of the most dangerous false positives.

Names are descriptors, not identity proofs. They can be shared, abbreviated, transliterated, misspelled, changed or reordered. A document title does not reliably distinguish two editions. A postal address may house several residents or businesses, and contact details can be reused. A phone number that once belonged to one customer can later belong to another. The right data model stores these fields as dated observations with sources rather than promoting them to permanent immutable keys.

Construct a canonical entity record with a local stable ID and an evidence graph. Preserve source records, dates, confidence or disposition labels, and reviewer decisions. The canonical record is not permission to erase the originals. If a later disagreement appears, the system should recover the path that produced the link and be able to detach a mistaken edge. An alias table can represent alternate names without making every alias a separate person; an unresolved candidate can remain an unresolved candidate.

4. Define a resolution contract before applying a model

A practical contract says what input fields are allowed, which source systems are in scope, the types of candidate pairs that may be produced, and the only dispositions permitted: matched, distinct or unresolved. It should also describe a maximum number of candidates per input, any mandated manual review, and the action boundary. When the consumer needs one authorised customer account, returning the top three candidates is not the same as completing the task. The output should say that the task is unresolved and ask for the evidence needed to proceed.

Include a rule against using confidential information that the requester is not entitled to access. An agent should not search every tenant’s private records merely to improve linkage accuracy. First apply access constraints, then compare only permitted records. If a user has permission to identify a public supplier but not access confidential payment records, a positive identity suggestion must not silently expand the query scope. This is a security property separate from matching quality.

The contract also needs a version. If the comparison features or thresholds change, a historical decision should remain interpretable: which version produced this candidate, with what input evidence, and who approved any downstream action? Without versioning, a reviewer cannot explain why yesterday’s record was joined while the same pair is refused today.

5. Candidate generation is a recall-versus-workload decision

Comparing every record in file A with every record in file B becomes expensive quickly. If file A contains 1,000 records and file B contains 2,000, the full Cartesian comparison contains 2,000,000 candidate pairs. Blocking limits comparisons to plausible pairs, for example records sharing a verified organisation registration prefix, an issuer-scoped identifier, or a normalised surname and a broad year range. This is not proof of identity; it is only a cheap way of producing a manageable shortlist for the stronger comparison stage.

Imagine that blocking reduces those 2,000,000 potential pairs to 12,000. Candidate reduction is 1 – 12,000 / 2,000,000 = 0.994, or 99.4%. That is a computational saving, not evidence of 99.4% matching accuracy. If the blocking rule excluded true cross-language name variants, the system might never get a chance to recover those matches. Measure candidate recall on labelled pairs separately from later decision accuracy. A system can have an excellent final classifier and still fail because candidate generation hid the correct entity.

Use multiple defensible blocking passes when needed: exact stable ID when available; a second pass for permitted name-and-date agreement; a third for carefully normalised alias and location fields. Deduplicate the generated pair IDs so one pair found by three passes is still one candidate. Set a bounded candidate count and escalate unusually broad matches rather than silently selecting the nearest neighbour.

6. Normalise carefully without manufacturing identity

Text normalisation can reduce accidental differences. Trimming unimportant surrounding spaces, treating consistent punctuation according to a documented policy, or applying Unicode canonical normalisation may help. Yet overzealous cleaning can turn distinct things into the same string. Removing all diacritics can conflate genuine names; collapsing all apartment numbers can join different households; dropping company suffixes may alter legal meaning. Each transformation should have a narrow purpose, be versioned, preserve original text and be reversible for audit.

Unicode normalisation and visual confusable detection are not interchangeable. The Unicode Consortium distinguishes canonical equivalence from lookalike characters across scripts. Two visually similar strings can remain genuinely different identifiers. When identity matters, compare the source-controlled identifier, not a display spelling guessed from an image or transliteration. If scripts, accents or fonts are uncertain, preserve that uncertainty as a feature and a reason for review, not as proof of a match.

Dates and numbers need explicit types. A string written as 04/05 may mean different dates in different locales. Leading zeros may be meaningful in account identifiers even though they are irrelevant in arithmetic. A house number is not a numeric magnitude that can be rounded, and a ten-digit phone field may contain country and area structure. The correct question is not whether two field strings resemble each other, but whether the comparison respects what that field represents.

7. Score evidence without mistaking a probability for a fact

A simple deterministic rule might require agreement on the same issuer-scoped stable ID and no recorded conflict in an independent field. When that identifier is unavailable, a probabilistic model can combine several weak comparisons. The Fellegi–Sunter record-linkage framework, studied by national statistical agencies, compares how likely an observed agreement pattern is under the same-entity versus different-entity hypotheses. This is more principled than assigning an arbitrary number of points for a matching surname, but it still depends on assumptions and data quality.

For a simplified classroom illustration, suppose a rare verified identifier agreement occurs in 90% of true matches but only 0.5% of nonmatches. Its likelihood ratio is 0.90 / 0.005 = 180. A common city agreement might occur in 80% of matches and 40% of nonmatches, giving a likelihood ratio of 2. They should not contribute equal evidential weight. These are invented teaching probabilities, not measurements of any school or company dataset. They should be learned or validated on a suitable population before deployment.

Do not multiply likelihood ratios blindly when fields are dependent. A surname, email local part and account username may all derive from the same original entry; three agreements may be one observation repeated three times. Likewise, a model’s confident explanation of why two names match is not an independent identity source. Use field provenance, conditional dependence checks and real labelled pairs. Keep both the score and the underlying comparisons visible so a reviewer can challenge the reasoning.

8. Introduce an explicit abstain band

A safer resolver often uses two thresholds rather than forcing a binary decision. Pairs with overwhelming permitted evidence enter an automatic match bucket only if automatic matching is authorised for that task; weak pairs enter a nonmatch bucket; ambiguous pairs enter manual review. A review band makes uncertainty operational. It prevents a system from treating its largest score as certainty when several candidates are nearly tied. It can also hold cases where a stable identifier conflicts with an apparently persuasive name comparison.

Illustratively, a programme might provisionally label pairs scoring at least 0.98 as high-confidence matches, below 0.20 as unlikely, and between them as unresolved. Those numbers are not generally appropriate probabilities or recommendations. A score might not be calibrated; the class prevalence and the consequences of error may differ sharply. Choose thresholds from task-specific validation and observed review capacity, then change them through a controlled policy decision.

Escalation should report why a pair is unresolved. A reviewer needs the conflicting source names, field scopes, dates, alternate candidates and what decision would change if the match were wrong. Showing a green confidence bar alone turns uncertainty into a persuasive-looking decoration. A useful agent can say: two vendor names are similar, but the verified registration identifiers differ, so do not combine payment instructions.

9. A complete worked example: 120 proposed pairs

Consider a fictional linkage exercise with 120 candidate record pairs that have independent adjudicated ground-truth labels. Exactly 20 pairs refer to the same entity and 100 refer to different entities. The new resolver automatically matches 16, rejects 94 and sends 10 to review. Within the 16 automatic matches, 14 are genuinely the same and two are false merges. Within the 94 automatic nonmatches, 93 are correctly separated and one is a missed match. The remaining ten review cases contain five genuine matches and five nonmatches. The totals reconcile: 16 + 94 + 10 = 120; 14 + 1 + 5 = 20 true pairs; and 2 + 93 + 5 = 100 different pairs.

Before the review queue is resolved, automatic-match precision equals 14 correct auto-matches divided by 16 automatic matches, or 87.5%. Automatic-match recall relative to all 20 true pairs equals 14 / 20 = 70%. These numbers answer different questions. Precision measures contamination of the auto-match bucket; recall measures how much of the truly matchable population was captured there. The automatic decision coverage is (16 + 94) / 120 = 91.67%, while 10 / 120 = 8.33% of pairs are held. High coverage is not automatically high accuracy or safe behaviour.

Suppose qualified reviewers correctly resolve all ten held cases, accepting the five genuine matches and rejecting the five others. The final accepted set contains 21 pairs: 19 true matches and two false matches. Its precision is 19 / 21 = 90.48% and recall is 19 / 20 = 95%. The two false merges remain even after perfect review of the ambiguous bucket. A team cannot truthfully claim zero false merges by reporting only reviewer accuracy; it must audit the supposedly obvious automatic decisions as well.

10. Use denominators and cost to avoid a misleading victory

The same fictional matrix supports a false-positive rate measured among different-entity candidates: 2 / 100 = 2%. The missed-match rate after review, measured among true matches, is 1 / 20 = 5%. They have different denominators. A statement such as “98% safe” would hide which mistake it describes. Because this dataset was deliberately selected for instruction, those numbers are not a field estimate, and the true match prevalence of 20 / 120 = 16.67% is not transferable to another site.

For a consequence illustration, suppose an incorrect automatic merge costs an organisation an estimated 500 units of staff remediation, notification and reversal work, whereas leaving one true duplicate unresolved costs 20 units. Under these fictional costs, two false merges account for 1,000 units and one missed match accounts for 20, before considering privacy or human harm. An apparently modest false-positive rate may dominate the loss. Actual human consequences cannot always be reduced to currency, so high-stakes identity work may require a hard no-automatic-merge rule rather than a weighted cost optimisation.

To compare policies fairly, hold the same labelled reference set fixed and show the number of true matches, nonmatches, reviewed cases and unresolved outcomes under each threshold. Report confidence intervals when sampling permits, separate precision from review throughput and inspect errors by language, common-name frequency, missing data and source system. Without those conditions, a single quality score provides no defensible basis for wider deployment.

11. Pairwise scores are not automatically a coherent identity graph

Suppose A is likely to match B, and B is likely to match C. It does not follow that A, B and C represent one entity. Similarity is not transitive, and missing or contradictory attributes can create a chain of plausible pairwise links through distinct people. Unrestricted connected-component clustering turns one mistaken bridge into a multi-record false merge. A resolver should distinguish a candidate-link graph from a validated same-identity equivalence relation.

Entity constraints can help. In a roster where each person has at most one active record per source file, a one-to-one matching rule prevents the same external row being assigned to two separate canonical people. In another domain, one-to-many may be legitimate: a legal organisation may have several trading names and premises. The constraint comes from the business model, not from a convenient algorithmic default. Write it down, test it and make conflicts visible.

A merge graph also needs a split operation. If later evidence reveals that two canonical clusters were incorrectly joined, the system must reconstruct source provenance and any downstream disclosures or changes. Deleting one edge may not be sufficient if generated reports, access decisions and notification lists already used the false cluster. Record the decision lineage and limit irreversible side effects until identity certainty is suitable for the action.

12. A second worked case: three similar supplier names

A fictional procurement system receives an invoice headed “Harbour Tools Pte Ltd”. Its supplier directory holds record S17, “Harbour Tools Private Limited”, registration key R-400; record S44, “Harbour Tooling Pte Ltd”, registration key R-901; and record S81, a former trading name attached to S17. The invoice contains a verified registration key R-901 but uses a description closer to S17. A name-only algorithm would rank S17 first; an identity-aware resolver should treat the verified key as stronger evidence and compare the invoice with S44, while recording the naming inconsistency for human review.

The action question remains separate. Matching the invoice to S44 does not authorise paying it. A payment instruction may name a different bank account, and the supplier master may require a second-person confirmation for account changes. The resolver should return “candidate S44; registration key agrees; trade name differs; payment instruction not validated”, not “pay S44”. If the key has not been independently verified, the appropriate result is even weaker: several candidates, unresolved, obtain a trusted source.

Now remove the registration key. With only the common words “Harbour”, “Tool” and “Pte Ltd”, none of the three candidates has sufficient unique evidence. An agent that picks the highest similarity score fabricates certainty. The correct useful outcome is an explicit request for an existing purchase order ID or registered company identifier, with no irreversible update in the meantime. This is a complete answer to the task even though no automatic merge occurs.

13. Preserve provenance, consent and least privilege

For each linkage assertion, store the original source record IDs, the comparison features actually used, the source timestamps, the algorithm or rule version, the disposition, the reviewer if applicable, and the authorised downstream actions. A source citation should point to the exact record scope, not a broad page that happened to contain a matching string. If one field was derived from another, note their common origin rather than pretending they are independent witnesses.

The system must also minimise unnecessary processing. Identity resolution can involve personal information, and extra attributes are not automatically justified because they improve a score. Use the least data necessary to meet the reader’s real task, restrict access to permitted records and define retention and deletion treatment before collecting new fields. Protect the separate record-link map: even when source documents are public, the fact that two identifiers refer to the same person may be sensitive.

This is the boundary with adjacent reading. The existing agent evidence-ledgers guide explains reconstructing decisions and sources. Entity resolution addresses the distinct prior question: which record a claim or action is about. The data erasure guide addresses later lifecycle handling, while data consistency addresses whether the selected record’s state is current.

14. Diagnose common failure patterns before choosing a repair

Failure one is the name-only merge: two people share a name, so the resolver joins their profiles. Repair it by requiring issuer-scoped identifiers or independent evidence appropriate to the action, introducing an abstain band and prohibiting automatic sensitive merges. Failure two is the stale-alias mismatch: a legitimate name change makes two records appear different. Repair it by retaining dated aliases and checking trusted change histories rather than editing away conflicting evidence. Failure three is the recycled-contact collision: an old phone or email is assigned to a new user. Repair it by recording observation date, source authority and verified control rather than treating contact possession as enduring identity.

Failure four is accidental cross-tenant linkage: the model retrieves a near-exact match from a customer account the current user cannot access. Repair access scope before candidate search and test that private fields never leak through scores, suggestions or explanations. Failure five is evidence duplication: a customer name, username and email local-part all derive from the same form, and a model counts them as three independent sources. Repair the feature provenance and the statistical dependence assumptions.

Failure six is a successful-looking dashboard that hides exclusions. A blocker discards records with non-Latin names before scoring; the remaining evaluated pairs look highly accurate. Repair evaluation by counting the full eligible input population, auditing blocked-out genuine matches and reporting coverage by source and language. The important question is not only whether a decision is correct once a pair reaches the classifier, but whether the right pair could ever be considered.

15. Measure production behaviour without circular ground truth

A feedback loop can corrupt the resolver’s evaluation. If reviewers see the model’s preferred match before independently inspecting evidence, their labels may become anchored to it. If the team treats already-merged records as proof that the merge was right, it trains on its own decisions rather than external truth. For a credible audit, draw a stratified sample of automatic matches, rejections and ambiguous cases. Provide adjudicators the original evidence and a blinded review route when feasible. Record disagreement and a resolution procedure.

Monitor quality over time by source system, time period, language and candidate rarity. Precision calculated only on auto-matched items says nothing about hidden genuine links in the nonmatch bucket. Recall estimated only from reviewed ambiguous cases is biased because those cases were selected precisely for difficulty. A careful audit can sample across all three buckets and use sampling weights if the review fractions differ. Keep denominators visible and state where an estimate is too uncertain to support automation.

Use separate operational measures: time per candidate, size of the review queue, proportion unresolved, number of merges reversed, age of source observations, and number of downstream actions held for consent. Improvement means fewer harmful errors and more correctly completed authorised tasks, not just greater automation percentage. A resolver that abstains more often may be a better system when its work controls sensitive identity.

16. Design a safe implementation and release sequence

Begin with a written use-case register: one line for the entity type, permissible data sources, identifiers, error costs, downstream action authority and human review requirement. Gather representative labelled examples with provenance, including common names, rare names, scripts, missing fields and genuine aliases. Validate blocking separately from scoring. Then validate automatic match and rejection thresholds on a held-out set. This ordering prevents a score from hiding systematic candidate-generation failures.

Build a dry-run that writes suggestions to a review table without changing master records. Each suggestion should include candidate IDs, field-level agreement and disagreement, a rule version, a bounded expiry and a clear “no action taken” label. Add an explicit reconciliation path for corrected or disputed links. For high-risk merges, require a second approval and an independently checked stable identifier even if a model reports high confidence. For low-risk discovery, suggestions may be acceptable without final identity assignment.

Release incrementally. Start with a limited source and measure the audit outcomes against the declared thresholds. Document what would cause a pause: for example a confirmed cross-account disclosure, unexpected many-to-one merge, unrecognised identifier issuer, or a rise in unresolved cases after a data import. When the policy or matching model changes, retain old decisions with their versions and re-evaluate only through an authorised repair process, not a silent global rewrite.

17. Independent practice: six records and three questions

Try this fictional exercise without a model. Records A1 and A2 share the exact name “R Lim” but have different independently verified employee IDs issued by the same organisation. Records B1 and B2 have different display names but share one verified employee ID from that issuer, with a documented name-change event. Records C1 and C2 share a postal address but have different verified company registration numbers. Which pairs are matches, nonmatches or unresolved for purposes of approving an internal payroll amendment? State what you would need before acting.

A1 and A2 must not be merged merely because of a name. Different concurrently valid issuer-controlled employee IDs indicate distinct accounts or a data problem; the correct safe action is to hold the payroll amendment and investigate the conflict. B1 and B2 are good candidates for the same employee because their verified issuer-controlled ID agrees and the change event explains the name difference, but a payroll amendment still needs appropriate permission and validation of the requested amount. C1 and C2 are distinct companies as registered, despite their shared address; address co-location does not transform legal identity.

Add a twist: suppose B2’s employee ID was typed into an email rather than verified from the HR system. The apparent “verified ID” is no longer verified, and the answer changes to unresolved until the HR record is consulted. What looked like a change in confidence is actually a change in evidence origin. This is why origin and scope belong in the data structure, not merely in the final prose explanation.

18. Changed-context transfer: matching publications, not people

Now move the same method to an educational research library. Four files have titles: “Fieldwork Guide 2025”, “Fieldwork Guide (reprint)”, “Fieldwork Guide 2026” and “Fieldwork Guide 2025 – corrected tables”. An assistant must remove duplicate downloads while preserving editions that differ in content. A naive title normaliser strips years and parenthetical words, then merges all four into a single document. Identify why this is wrong and design an identity rule.

The entity of interest is an exact document version, not merely the intellectual work or the file’s similar topic. Use a trusted document identifier if available, an issuer’s edition or revision marker, the actual file hash for exact-byte duplicates, and source metadata. Two files with equal cryptographic hashes are the same bytes under the chosen hash algorithm; different hashes mean different bytes but do not alone prove substantively different contents. A reprint may be identical in content but have different packaging or metadata. The corrected-table version must remain distinct until a reviewer establishes the exact intended version relationship.

Assume the 2025 file and the reprint have identical byte hashes, while the corrected-table and 2026 files have different hashes. You may link the first two as exact byte duplicates if the files were captured correctly. Preserve both source references and make the de-duplication reversible. Do not merge the corrected-table document or 2026 revision into the same version record; represent them as related editions and direct the reader to the appropriate current publication. Notice how the broad identity reasoning transfers while the defining features change completely.

19. Useful limits and responsible next steps

Entity resolution cannot manufacture missing ground truth. Some pairs remain undecidable with the permitted evidence, and ordinary probability scores cannot eliminate the trade-off between false merges and missed links. An impressive language model can help explain record similarities or propose review questions, but its generated text is not a substitute for issuer verification, access rights or an auditable final decision. Historical records may contradict one another without any source being intentionally deceptive. A sound workflow preserves uncertainty until stronger evidence arrives.

Methods can also drift as records, conventions and populations change. Names may be represented differently across languages; identifiers may be migrated between systems; organisations can merge while legal records retain previous names; time-limited identities such as addresses or phone numbers can be reassigned. A rule validated on clean modern procurement data might not apply to historical family records or multilingual school lists. Each changed context needs a fresh task definition and representative validation, not automatic re-use of an attractive metric.

The practical learning route is to begin with small transparent pair comparisons, learn to draw a confusion matrix and state its denominators, then design the blocking and reviewer steps. A student gains a transferable habit of separating surface resemblance from proof. A researcher learns what false matches do to data analysis. A software or security engineer learns to enforce identity boundaries before tool actions. A manager learns why an unresolved record can be an honest and successful outcome.

Frequently asked questions

Can a language model decide that two people are the same?

It can suggest candidates and describe evidence. For consequential identity decisions, require appropriately authoritative identifiers or qualified review; a model’s confidence is not verification or permission.

Is a 99% similarity score enough?

Not by itself. The scale may be uncalibrated and the relevant error is different for a search suggestion, document deduplication and financial account merge. Measure false merges and missed matches on appropriate labelled examples.

Why not just match every record with the highest score?

The correct entity may not be among retrieved candidates. Even if it is, several similar records can remain unresolved. Ranking produces an ordering, not a proof that the top item is correct.

What is the difference between blocking and matching?

Blocking makes an economical candidate shortlist; matching assesses those candidates. Poor blocking can hide genuine matches before the scorer gets a chance to evaluate them.

What must be stored after an identity decision?

Keep original record IDs, source and issuer scope, relevant timestamps, compared features, disposition, policy or algorithm version, reviewer authority and downstream actions necessary for audit and correction.

Can a wrong merge be fully undone?

Sometimes the record mapping can be split, but disclosures and earlier actions may persist. Track derived outputs and notifications and plan recovery before allowing irreversible changes.

Authoritative sources and further reading

The U.S. Census Bureau’s Overview of Record Linkage and Current Research Directions explains the statistical and data-cleaning problem; its false-match-rate working paper cautions against assuming easy error estimation without ground truth. The original Fellegi–Sunter theory can be located through A Theory for Record Linkage (1969). Unicode’s Normalization Forms and Security Mechanisms distinguish canonical normalisation from visual confusability. These references support mechanisms, not the fictional counts used above.

Keep learning

Return to the How Super Intelligence Works curriculum, widen the lens through the How X Works master hub, and connect careful identity work to the Gold Standard of Education: learning that transfers into life. The related agent conflicting-evidence specialist explores how to disagree with an attractive but unsupported conclusion.