In one sentence
The fact graph now recognises that “Max Mustermann”, “M. Mustermann” and “Herr Mustermann” could be the same person — and expressly turns that into a suggestion for you to decide on, instead of a merge that simply happens.
Three nodes for one person
Fact extraction works document by document, and documents differ in care. The pleading names “Max Mustermann”, the exhibit to it “M. Mustermann”, the minutes “Herr Mustermann”. Until recently those were three separate nodes in the case file’s relationship graph. The only duplicate detection applied to values that were identical letter for letter — and therefore not here.
In a small case file that is cosmetic. In a large one it is expensive: the context window fills up with spelling variants of the same person, and links point to different duplicates of the same human being. Precisely the consolidation a fact graph is built for is lost.
Three signals, one suggestion
A suggestion arises when one of three independent signals is triggered:
- Abbreviation — the same surname with an abbreviated first name.
- Containment — one name is contained in full within the other, from a length of six characters upwards.
- Spelling — very similar spelling, measured as trigram similarity from 0.45 upwards.
Shared neighbours in the graph — two names attached to the same deadline or the same contract — by contrast never produce a hit. They only raise the rank of a suggestion that has already arisen from one of the three signals in any event. Two people can have signed the same contract without being the same person.
Only persons and organisations
The function looks exclusively at the names of persons and organisations. For sums of money, dates and clauses it is deliberately switched off. The reasoning is written into the code just like that: with money, dates and clauses, similarity precisely does not mean identity — 12,500 euros and 12,600 euros are very similar and guaranteed to be different. A similarity search that does not distinguish this reliably produces nonsense in a schedule of claims.
You decide not only whether, but what the person is called from now on
A single “merge” button would have been the obvious design — and the wrong one. It would silently have decided along the way under which spelling the person is carried in the case file from then on. Instead both versions stand side by side, and you choose: “keep the left-hand spelling” or “keep the right-hand spelling”. The direction is part of the decision, not a by-product of it.
Suggestions, not automation
Above the list it says: Suggestions, not automation. Two similar names can also be two different people. Father and son, a company and its identically named managing director — these cases are not exotic. In a legal context a wrong merge is more expensive than an overlooked duplicate, because it disguises itself as a clean set of data.
The “state of knowledge in this case file” card
Alongside it there is a new overview showing how far a case file has been developed — including how many documents have not yet contributed any facts at all. What is notable about it is an omission: documents you have excluded from AI use are expressly not counted here. They are never meant to be read; reporting them as a gap would be a silent misstatement. Instead they are shown separately, so that the case file does not look more complete than it is.
What the function does not do
It merges nothing by itself, not even where similarity is high. It does not detect identity across category boundaries. And it answers no legal question: whether two designations mean the same party — for instance in the case of a change of company name, legal succession or a risk of confusion in the case caption — is an assessment the case file has to make, not the graph. The suggestion shows you the place where that question belongs.
→ The living case file · AI assistant · Agents · Contradiction detection
