Short answer: Identity resolution decides when different memories concern the same real-world entity and whether to merge them into one object.
Deduplication asks if two memories say the same thing. Identity asks if different facts still refer to the same person, place, or thing under inconsistent names. Merging consolidates a record; wrong merges conflate distinct entities, and missed matches leave fragmented histories. Recognition uses shared identifiers and flexible matching, not exact string equality. Engram handles this during extract and transform for cases like multi-name alumni records.
Deduplication, covered earlier in this Part, catches near-identical restatements of the same fact. A related but distinct problem shows up when two memories clearly describe different facts, yet both facts genuinely concern the exact same underlying person, place, or thing. Deciding whether that shared identity should pull separate memories together into one object, or simply link them while keeping them apart, is its own deliberate judgment call.
Why Isn’t Recognizing Shared Identity the Same Problem Deduplication Already Solves?
Deduplication asks whether two memories are saying essentially the same thing, a question about content overlap. Identity resolution asks a different question entirely: whether two memories, even ones describing completely different facts, both concern the same real-world entity underneath. A memory about someone’s job title and a separate memory about their favorite restaurant share no semantic overlap whatsoever, deduplication would never flag them as similar, yet they’re both genuinely about the same person, and a system that fails to recognize that shared identity treats one person as though they were two entirely separate, disconnected entities.
Why Does the Same Entity Often Get Referred to in Genuinely Different Ways Across Separate Memories?
Real conversation is inconsistent about naming. A person might be referred to by their full name in one mention, a nickname in another, a title or role in a third, with no single consistent label tying all three back to the same underlying individual. A company might appear under its full legal name in one memory and an informal shorthand in another. Without some mechanism for recognizing these different surface labels as pointing to the same underlying thing, a system risks treating what’s actually one consistent entity as though it were several unrelated ones, simply because the wording used to refer to it kept shifting.
What Actually Determines Whether Two Memories Referring to What Seems Like the Same Entity Should Be Merged into One Object?
Merging makes sense when the shared identity itself is what a future search will actually need to leverage, when a caller genuinely benefits from retrieving everything about that one entity as a single, consolidated unit rather than piecing it together from scattered, separately stored fragments. Keeping memories separate but linked, rather than merged into one, makes more sense when each memory still carries its own independent value and context that would be diluted by combining it with everything else known about that same entity. This is the same underlying tension the atomic-facts chapter raised: bundling too much together blurs precision, splitting too aggressively loses connective value, and identity resolution has to navigate that same tradeoff specifically around entities rather than around facts.
How Does a System Actually Recognize That Two Differently Worded References Point to the Same Entity in the First Place?
Exact string matching catches only the simplest case, identical wording used consistently every time, which real conversation rarely provides. More flexible techniques, matching on shared identifying details, tolerating minor variations in spelling or phrasing, or relying on an extraction step that resolves a reference against already-known entities before committing a new memory, do a better job of catching cases where the same underlying entity gets referred to inconsistently across different mentions. None of these techniques guarantees perfect resolution, false matches and missed matches both remain possible, which is exactly why this remains a genuine judgment call rather than a fully mechanical process.
What Happens When Identity Resolution Gets It Wrong in Either Direction?
Merging two memories that actually concern two different entities conflates information that should have stayed separate, corrupting both entities’ records with details that never actually belonged to either one individually. Failing to merge two memories that genuinely concern the same entity leaves that entity’s information scattered and incomplete, forcing a future search to somehow know to check multiple, seemingly unrelated memories to get the full picture. Neither failure mode is harmless, which is why identity resolution deserves the same careful, deliberate attention this knowledge base has given to deduplication and reconciliation elsewhere.
How Does Weaviate Engram’s Extraction and Transform Process Handle This Kind of Identity Resolution in Practice?
Weaviate Engram’s transform steps can be configured to check whether a newly extracted fact concerns an entity already represented in existing memory, consolidating references to the same underlying entity even when the wording used to refer to it varies. Consider an alumni association’s donor-relationship tracker, where the same graduate might be referred to by a maiden name in older records and a married name in more recent ones:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"Margaret Chen, class of 2008, made a leadership-tier gift to the engineering scholarship fund three years ago.",
properties={"alumni_id": "alumni-award-2008-chen"},
)
client.memories.add(
"Margaret Whitfield, formerly Margaret Chen, recently reached out expressing interest in establishing a named endowment.",
properties={"alumni_id": "alumni-award-2008-chen"},
)
Because both memories share the same underlying `alumni_id`, tying them to one consistently resolved identity despite the name change between mentions, a development officer researching this alumna’s giving history retrieves both facts together rather than missing the connection entirely:
results = client.memories.search(
query="What is this alumna's full giving history and current interests?",
properties={"alumni_id": "alumni-award-2008-chen"},
)
Without this kind of deliberate identity resolution, a development officer searching under the newer married name might never surface the earlier scholarship gift recorded under the maiden name, potentially approaching a major, already-engaged donor as though she were a stranger to the institution. This is exactly the value identity resolution delivers for a use case like alumni relations, where the same person’s record genuinely spans years and multiple names, and where failing to connect those references back to one consistent identity risks a real, avoidable relationship misstep.
Object identity and merging decide when shared identity between two memories should actually pull them together into one consolidated record. A related but lighter-weight alternative exists for connecting memories that are related without necessarily needing to merge into a single object at all. Our next chapter, What is cross-referencing related memories?, takes up exactly that alternative.