Multiple retrieved chunks refer to the same entity using different names. How would you avoid combining facts from the wrong entity?

Production incident (illustrative): An enterprise finance RAG assistant is asked, “What was Orion Mobility India Pvt Ltd's FY2026 service revenue, and did the Orion Mobility European parent guarantee its lease?” Search retrieves a company registry record for Indian subsidiary IN-CIN-001, a 2026 filing from the European parent EU-LEI-002, and an older logistics business called Orion Mobility Services IN-CIN-003. A retrieved subsidiary note uses the shorthand “Orion,” while the parent filing calls itself “Orion Group.” The assistant merges the subsidiary's revenue with a different company's lease guarantee because all chunks share the phrase “Orion Mobility.” Each sentence appears grounded in *some* cited document, but the entity joins are wrong.

Core principle: Name similarity is not identity. Entity resolution must distinguish aliases of the same legal/entity identity, parent/subsidiary and predecessor/successor relationships, and different organizations with overlapping names. A model may use retrieved facts only after every factual subject is linked to the correct, authorized, time-valid canonical entity. Similar embeddings, shared names and even a company-group relationship are insufficient to merge financial facts.

1. Contain the incident and establish correct identity

• Suspend or qualify answers that combine numbers, liabilities or permissions from ambiguously identified organizations. For high-impact financial or legal questions, ask the user to choose an entity or state the unresolved entity ambiguity rather than inventing a consolidated answer.
• Capture a privacy-protected trace: raw query, source IDs, retrieved chunk IDs, source document titles, publisher, dates, entity strings, surrounding context, entity-linker outputs, canonical IDs, relation types, scores, filters, reranker outputs, packed evidence and final per-claim citations.
• Obtain authoritative identifiers from the right registry or internal master-data service: company_registration_number, LEI, vendor_id, legal_entity_id and any verified source_record_id. A human-readable label is a display attribute, not a reliable join key.
• Establish whether the question seeks one legal entity, a consolidated group, a named subsidiary, or a comparison of related entities. These are distinct tasks. An answer about a subsidiary should not automatically use parent-company totals or obligations.
• Confirm every candidate chunk is authorized under the user's tenant, ACL and document effective date. Never use an external registry match to bypass a source's access controls.

2. Diagnose the first entity-mixing boundary

• A. Source extraction: review original documents, headings, legal names, internal cross-references and named entities. OCR or document parsing may strip a legal suffix, table header, registration code or a footnote identifying the true subject.
• B. Ingestion metadata: validate source IDs, document version, tenant, publication date, issuer entity, subject entity and canonical entity ID. A report *authored by* a parent may contain facts *about* a subsidiary. Store these as separate roles.
• C. Entity detection: inspect mention spans such as “Orion,” “Orion Mobility,” “OM India,” or “the Company”; preserve their local sentences and table headers. Coreference is contextual: “it” may mean a subsidiary in one section and the group in another.
• D. Candidate linking: show the top possible canonical entities with match evidence, not just the winning display name. Compare legal registration identifiers, issuer, country, entity type, period, address, organization hierarchy, and source-document role.
• E. Alias graph: an alternate name should be a *verified alias edge* with source and valid-from/valid-to timestamps, not an unconditional global synonym. A name shared across brands or jurisdictions can have many possible entities.
• F. Relationship semantics: distinguish SAME_AS, ALIAS_OF, PARENT_OF, SUBSIDIARY_OF, ACQUIRED_BY and PREDECESSOR_OF. Parent-of is not same-as; ownership does not automatically transfer revenue, contractual guarantees or policy applicability.
• G. Retrieval selection: inspect whether query routing and metadata filters restrict to the intended canonical subject, and whether dense/hybrid retrieval pulls nearby names or parent reports. Retrieval can include candidates from several entities for disambiguation, but answer synthesis must not treat them as one.
• H. Fusion/context packing: check whether source headers, issuer metadata and section labels are dropped when adjacent chunks are packed. If entity IDs are removed, the generator can no longer distinguish superficially similar paragraphs.
• I. Answer composition: represent each extracted fact as (subject_entity_id, predicate, value, unit, period, source_span, relationship_scope). Reject a generated claim whose subject ID does not match the intended entity or an explicitly authorized relationship path.
• J. Citation audit: a citation supporting a revenue number for IN-CIN-003 does not support a revenue claim about IN-CIN-001. Citation correctness requires entity applicability, not only textual entailment. This is separate from #268's general support verification.

3. Root-cause decision tree

• Two names, same stable registration/entity ID, compatible time: likely aliases or a legal rename; verify issuer records and time ranges. Link as the same canonical identity only if authoritative evidence supports it.
• Same trading name but distinct registration IDs: different entities. Do not merge even if semantic similarity is high. Ask for location, legal suffix, account, product or another discriminator if unresolved.
• Parent and subsidiary have different IDs: represent PARENT_OF, preserving ownership percentage, effective dates and consolidation scope; never rewrite it to SAME_AS.
• Historical merger or rename: model predecessor/successor and valid-time relationship; financial statements can belong to different legal entities before/after an event. Document evidence must determine whether an event creates legal continuity.
• Entity ID present at retrieval but missing in final prompt: context serializer/metadata-loss bug. Retain canonical subject and issuer labels in every included chunk and citation.
• Names correctly linked yet claims cross-contaminated: generator-level subject binding failure. Require typed fact extraction and constrain answer synthesis to entity-specific evidence bundles.
• Low-confidence match / conflicting evidence: preserve multiple hypotheses, abstain or ask a targeted clarification. Do not choose an alias because the LLM “recognizes” the company.
• Same entity name reused in different tenants: canonical keys need namespace/tenant scope. Enforce ACLs before matching and after citation; never leak another tenant's entity existence.
• Multiple entity types: Orion could denote a company, product line or legal group. Use document type, local syntax and query intent, not generic name-only similarity.
• Entity and financial period both vary: check IDs here and periods separately; Q271 handles temporal consistency across reporting periods.

4. Worked numerical example

• An illustrative evaluation contains 200 multi-source questions whose correct answers require matching a mentioned organization to a specific canonical legal entity. There are 120 clear ID-backed mentions, 50 aliases/renames and 30 ambiguous parent-subsidiary or same-name cases.
• Baseline raw-name matching attributes facts to the right entity for 112/120 clear, 30/50 aliases, and 10/30 ambiguous, totaling 152/200 = 76% entity-attribution accuracy. The other 48 are entity mixing or unresolved wrongly guessed identities.
• Consider an answer requiring subsidiary revenue and a parent guarantee. Baseline retrieves 8 passages: 3 from subsidiary ID A, 3 from parent ID B, 2 from unrelated same-name company ID C. A similarity-only merger groups all 8 under the same display label and falsely attaches C's revenue to A.
• Introduce verified canonical IDs and relation-aware grouping: A's facts remain with A, B's with B, and C's are excluded from claims about A. A parent guarantee is only reported when an actual guarantee relation or explicit contract span supports it, not merely because B owns A.
• On the same labelled set, a versioned entity resolution + evidence gate correctly attributes 118/120 clear, 46/50 aliases, 25/30 ambiguous, totaling 189/200 = 94.5%. This improves attribution by 18.5 percentage points, leaving 11 errors requiring audit.
• For claim mixing, suppose the baseline produces 32 answers with at least one wrong-entity citation out of 200 (16%). The guarded pipeline reduces these to 5/200 = 2.5%, but another 9 answers request clarification. Clarifications must be measured separately rather than treated as fully correct answers.
• Mean entity-linker candidate checks rise from 1.0 to 2.4 per query and p95 retrieval-plus-linking latency from 160 ms to 235 ms. These hypothetical values show quality/cost/abstention trade-offs; they are not observed MachinoAI production metrics.
• A critical additional check is false merge rate: for labelled distinct-entity pairs, count how often the linker incorrectly declares identity. A high true-alias recall cannot justify merging unrelated legal entities.

5. Engineering solution: entity-aware evidence assembly

• Canonical registry: maintain stable, issuer- or business-authoritative IDs, namespace, legal name, aliases, verified registration attributes, entity type, jurisdiction, and relationships. Store valid_from/valid_to and a provenance ID on every alias or relationship edge.
• Typed matching: prioritize exact trustworthy identifiers; then apply configurable multi-attribute rules; finally use probabilistic/fuzzy matching only to propose candidates. AWS Entity Resolution documents rule-based and ML-based workflows, stable match IDs and the need to order precise rules before broad rules.
• Don't assume transitivity: two weak edges through the same name can form a false giant cluster. A~B and B~C by fuzzy aliases does not prove A=C. Require a strong equivalence witness or review before transitive closure, particularly for legal entities.
• Model issuer versus subject: source_publisher_entity_id and fact_subject_entity_id can differ. A group annual report may mention subsidiaries; each statement must be linked to its own subject rather than automatically tagged with the publisher's name.
• Per-chunk provenance: include document_id, version, section, subject_entity_id, issuer_entity_id, source_span, period, tenant, acl, entity_resolution_version and confidence/evidence. Allow a chunk to contain multiple entities with mention-specific spans rather than one misleading global label.
• Query disambiguation: resolve requested entity from explicit IDs, legal suffix, jurisdiction, product context and conversation information; do not invent missing constraints. Ask for a single discriminating attribute if ambiguity is material.
• Entity-scoped retrieval: query authorized corpora using candidate entity IDs, but include controlled cross-entity evidence when the task asks for comparisons or relationships. Keep each candidate's subject identity and score independently.
• Fact ledger: extract subject_id → fact → value → units → time → supporting span, then reason about joins. Allow joins between A and B only with a typed, supported relationship, not an untyped shared alias.
• Answer verification: check every factual claim's subject ID matches its cited passage; verify relationship edges, current source versions and financial periods. Q268 checks general claim support; add entity-identity entailment.
• Rollout: ship a versioned registry/linker, run shadow comparisons on audited entity pairs, canary on high-risk financial queries, and gate on false merges, wrong-entity citations, entity precision/recall, abstentions, cost and latency. Preserve ACL and deletion restrictions in all fallback paths.

6. Trade-offs and common mistakes

• Exact IDs: excellent precision but often absent from informal user queries; propose candidate matches without silently joining them.
• Name normalization: punctuation/case/legal suffix standardization can help recall but must not erase disambiguating country, suffix, generation or product version. Keep raw names.
• Fuzzy similarity: helps spelling and aliases but can merge distinct companies or people; use domain-specific thresholds and authoritative attributes.
• Knowledge graph aliases: useful for cross-document linking; uncontrolled synonyms and transitive unions cause cascading false merges. Audit edge provenance.
• Single entity per chunk: simple to index but incorrect when tables, comparative reports and footnotes mention multiple subjects. Use mention/span-level identities.
• Aggressive entity filtering: reduces noise but can suppress genuine cross-company questions, acquisition histories, or subsidiary-specific clauses. Make relation-aware retrieval selective.
• LLM-based entity linker: flexible but may hallucinate familiar names, assume parent==subsidiary or ignore negative evidence. Calibrate on annotated namesakes and use explicit IDs.
• Document title as identity: a company group title does not imply every passage describes the group totals; a report publisher may describe several subsidiaries.
• Temporal changes: names, ownership and legal status can change; aliases and relationship validity need effective dates and source versions. Distinguish temporal consistency (#271).
• Privacy and tenant boundaries: linking external or other-tenant records can reveal sensitive entities or relationships. Apply authorization to matching candidates and all evidence returned.
• Abstention: reduces harmful false mergers but can lower answer rate; measure correct disambiguation requests separately and improve registry coverage.

7. Prevent recurrence

• Maintain an entity collision golden suite: identical names in distinct jurisdictions, subsidiaries versus parents, old/new legal names, acronyms, shared brands, multiple issuers, product/company ambiguity, renamed businesses, and historical acquisitions.
• Require negative-pair tests showing closely named *distinct* entities remain separate. Measure pairwise precision, false merge rate, false split rate, entity-attribution accuracy, and wrong-entity citation frequency.
• Test multi-entity documents whose title belongs to a parent but passages refer to a subsidiary, joint venture or separate product; assert issuer and subject are not conflated.
• Add numeric checks that company revenues, units, currencies, fiscal periods and entity IDs align with each cited fact. A correctly copied number attached to the wrong entity is a correctness failure.
• Log entity-candidate alternatives, selected canonical IDs, match-rule/version, confidence, supporting attributes, source span, relationship graph path and final claim subject under access-controlled retention.
• On new aliases, mergers or registry data feeds, run differential linking tests and verify the effect on all indexed chunks and cached answers. Use stable entity IDs to prevent renamed entities from being re-created as duplicates.
• Alert on rising wrong-entity citations, large clusters formed from fuzzy edges, rapid changes in entity linkage after a registry update, cross-tenant linkage attempts, and unusually low disambiguation rates on ambiguous queries.
• When no trustworthy identity is established, return an explicit clarification or separate attributed facts rather than an unsupported combined conclusion.
• Review sampled high-risk failures with domain owners and keep a record of corrected relationships and source evidence.

Interview takeaway: The right retrieval candidates can still yield a wrong answer if the system joins facts using a shared name instead of canonical identity. Link mentions to stable, time-valid entity IDs; distinguish alias from parent/subsidiary relationships; keep entity-specific provenance with every extracted fact; verify that claims and citations refer to the same entity; and abstain when identity cannot be resolved reliably.

Research references

• AWS, Entity Resolution matching workflows and stable match IDs: https://docs.aws.amazon.com/entityresolution/latest/userguide/create-matching-workflow.html
• AWS, Rule-based matching and match-rule auditability: https://docs.aws.amazon.com/entityresolution/latest/userguide/creating-matching-workflow-rule-based.html
• AWS, Transitive matching and overmatching: https://docs.aws.amazon.com/entityresolution/latest/userguide/transitive-matching.html
• Scharpf et al., *Entity Linking with Wikidata: A Systematic Literature Review* (ACM Computing Surveys, 2026): https://doi.org/10.1145/3795134
• AWS, Entity Resolution input schema and unique IDs: https://docs.aws.amazon.com/entityresolution/latest/userguide/create-schema-mapping.html