Short answer: Reconciliation updates or rewrites an existing memory when a new fact corrects it, rather than restating a duplicate.
Deduplication handles restatement of what is still true. Reconciliation handles reality moving on so the old content must change. Transform may rewrite rather than bluntly replace, weaving old and new where needed. Storing a correction can deliberately trigger the same machinery. Cases that are not clean updates may need contradiction handling instead. Engram applies this so current state stays trustworthy.
Deduplication, covered in the previous chapter, handles the case where a new fact simply restates something already known. Reconciliation handles a related but distinct situation: a new fact that doesn’t restate an old one, but actively updates or corrects it. Getting this distinction right inside the transform stage is what keeps a memory store’s current state trustworthy, rather than quietly littered with facts that used to be true but no longer are.
How Does Reconciliation Actually Differ from the Deduplication Covered in the Previous Chapter?
Deduplication asks whether a new fact adds anything beyond what an existing memory already captures. Reconciliation asks a different question: whether an existing memory’s content itself needs to change because reality has moved on since it was first recorded. A duplicate restates something still true. A fact requiring reconciliation replaces something that used to be true with something that’s true now instead. Both situations get resolved during the same transform stage, using the same retrieval-then-decide pattern, but they call for genuinely different outcomes once the underlying model actually examines what’s changed.
What Does It Actually Mean for the Transform Stage to Decide an Existing Memory Needs Rewriting Rather Than Simply Replacing It Outright?
A rewrite updates an existing memory’s content to reflect what’s now true, while still preserving relevant context from what came before, rather than either leaving the old, outdated version untouched or discarding it so completely that its history disappears. This connects directly to the memory versioning concerns covered elsewhere in this knowledge base, a rewrite is exactly the mechanism through which that history gets retained or dropped, depending on how a specific topic has been configured to handle it. The newly extracted fact that triggered this update typically gets dropped once its content has been folded into the rewritten memory, avoiding a redundant, separate entry saying the same new thing twice.
How Does the Transform Stage Actually Recognize That a New Fact Should Trigger a Rewrite Rather Than Simply Being Stored as Its Own Separate Memory?
The underlying model examines the new fact alongside retrieved, related existing memories and looks for a genuine update relationship, the new fact describing a change to something the existing memory already asserts, rather than an entirely unrelated piece of information that just happens to touch a similar subject. A fact about a person’s current job title updates an existing memory about their previous title because both describe the same underlying attribute at different points in time. A fact about that same person’s unrelated hobby wouldn’t trigger any such rewrite, since it doesn’t actually update anything the existing memory was asserting in the first place.
Can a Person or an Agent Actually Use This Reconciliation Mechanism Deliberately, Rather Than Only Relying on It to Trigger Automatically?
Yes, and this is a genuinely useful pattern worth calling out directly. Correcting a memory doesn’t require deleting it through some separate administrative operation, it can be accomplished simply by storing a new, corrected fact and letting the same reconciliation machinery that handles ordinary updates supersede the outdated version automatically. An agent that realizes it stored something inaccurate can “forget” that inaccuracy not by hunting down and deleting the specific offending memory, but by storing the correction and trusting the transform stage to resolve the conflict the same way it would resolve any other legitimate update.
What Happens When the Transform Stage Encounters Something That Doesn’t Cleanly Fit the Update Pattern at All?
Some conflicts genuinely aren’t simple updates, two sources disagreeing about the same point with no credible timeline explaining the difference, exactly the kind of contradiction covered in this knowledge base’s earlier discussion of representing uncertainty. In these cases, the right outcome isn’t a rewrite that silently favors one side, it’s preserving both accounts honestly rather than forcing a false resolution. The transform stage’s job in these situations is recognizing that a genuine, unresolved contradiction exists rather than mechanically treating every new, conflicting fact as though it were automatically a legitimate correction of whatever came before it.
How Does Weaviate Engram’s Transform Stage Apply This Reconciliation Behavior in Practice?
Weaviate Engram’s transform step recognizes update relationships between newly extracted facts and existing memories, rewriting the existing memory to reflect the current, accurate state while dropping the redundant newly extracted version. Consider a marina and boat-storage facility’s slip-assignment and maintenance assistant, tracking details about each vessel and its assigned slip across a boating season:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"This vessel is currently assigned to slip C-14 for the season, with dockside electrical service included in the rental agreement.",
properties={"vessel_id": "vessel-registration-7729"},
)
Midway through the season, the owner requests a slip change due to a depth concern, and staff record the update:
client.memories.add(
"Owner requested and was reassigned to slip D-6 due to reported shallow water depth issues at C-14 during recent low tides.",
properties={"vessel_id": "vessel-registration-7729"},
)
results = client.memories.search(
query="What slip is this vessel currently assigned to?",
properties={"vessel_id": "vessel-registration-7729"},
)
Because the transform stage recognizes this reassignment as a genuine update to the original slip assignment rather than an unrelated new fact, it rewrites the existing memory to reflect the current slip and the reason for the change, rather than leaving two separate memories asserting two different, conflicting slip numbers. Dock staff checking this vessel’s current assignment retrieve exactly one clear, current answer, rather than needing to guess which of two conflicting memories actually reflects reality.
Reconciliation keeps a memory’s current state accurate as facts genuinely change over time. Beyond correcting individual facts, related memories sometimes accumulate to the point where combining several of them reveals something none of them expressed clearly on its own. Our next chapter, How do you merge related memories into higher-order knowledge?, takes up exactly that possibility.