Entity resolution across four systems that never spoke

Here is a situation every firm recognises. A signed agreement names “Meridian Holdings Limited”. The CRM has a row for “Meridian Holdings Ltd”. An investment committee memo discusses “Meridian”. An email thread refers to “the Meridian deal”. Four systems, four strings, one company — and not one of those systems is in a position to know that.

They are each individually right and collectively useless. The document store is not wrong to hold the legal name; that is what was signed. The CRM is not wrong to hold the trading name; that is what the team types. The memo is not wrong to be informal. The failure is not in any of them. It is that nobody owns the join.

Why does search not solve this?

Because search returns documents that match a string, and the problem is that the strings do not match. Searching “Meridian Holdings Limited” finds the agreement and misses the memo. Searching “Meridian” finds the memo, the agreement, and every unrelated company with Meridian in its name — and leaves you to work out which is which, which is exactly the work you were trying to avoid.

More to the point, search has no concept of the company at all. It has a concept of documents containing words. You cannot ask it what the firm knows about Meridian, because “Meridian” is not a thing in its model of the world — it is a token. This is the difference we mean by search versus memory: one holds your work as text and the other holds it as structure.

What does resolution actually have to get right?

Two failures, in opposite directions, with very different costs.

A missed join splits one company into two, and the memory quietly under-answers: you ask about Meridian and get the CRM half, with the agreement and the memo sitting in a second entity nobody looks at. This failure is invisible. Nothing is wrong on the screen; there is simply less there than there should be, and no one can tell.

A false join is worse and louder. Two genuinely different companies merged into one entity produce an answer that mixes them — a covenant from one, a decision from the other — and the answer looks completely normal. In credit or audit work that is not an inconvenience, it is a wrong answer delivered with full confidence and a citation attached to each half.

A missed join makes the memory quieter than it should be. A false join makes it confidently wrong. Neither announces itself.

So resolution is deliberately conservative, and it leans on more than the name: the identifiers a record carries, the documents the entity appears in, the people around it, the dates. A similar name with no other overlap is a different company until something says otherwise.

Where do entities come from?

From documents, and only from documents. An entity exists because something your firm holds mentioned it. Nothing in recall or in an agent's question can mint one.

That rule sounds like a technicality and it is load-bearing. It means the memory cannot grow a company nobody ever wrote about, that every entity traces back to the first document that named it, and that asking a question can never quietly change the record. The glossary states it as a definition; in practice it is the reason the entity list is a description of your firm rather than an artefact of what people have been asking lately.

What happens when the join is wrong?

It has to be correctable, and the correction has to be visible — which is a harder requirement than it sounds, because the obvious implementation is to merge two entities and lose the evidence that they were ever separate.

Because the record is append-only, a correction is a later assertion rather than an edit. The merge is a thing that happened, on a date, and the state before it is still readable. That matters in the case that actually bites: a join made in error, acted on, and unwound six months later, when the question becomes what the memory was saying at the time somebody relied on it.

It also means resolution can improve without a migration. A new document arrives carrying an identifier that settles an ambiguity, and the entity that was two becomes one from that point, with both halves' history intact. Nothing has to be reprocessed and nothing is thrown away — which is the practical reason nothing is ever overwritten rather than a philosophical one.

What becomes possible once the join exists?

Questions that no single system can answer, because the answer spans several of them. What did we decide about this company, on what stated rationale, and what has happened since. Whether the CRM stage and the minuted resolution agree — and they frequently do not, which is only visible once both are attached to the same entity.

It is also what makes precedent reachable. “Have we seen this before” is a question about companies, not about documents. Answering it requires knowing that the concentration profile in this deal resembles the one in a deal you declined two years ago, which requires both to be attached to entities that can be compared. Without the join it is a question only the longest-serving partner can answer, and only until they leave.

None of this is exotic. It is the join a diligent analyst makes by hand, every time, from scratch, and forgets. The system's contribution is that it makes it once, keeps it, and shows the evidence for it.