Work out which records are the same. Then keep one that everyone can trust.

Datum finds every version of a client, matter and person across your systems and decides which are the same. It keeps one governed record of each and holds how they connect. This page shows how, surface by surface.

Narrowed, weighed, grouped, and stopped when a group stops making sense.

Deciding that two records are the same client is the part a firm is right to be sceptical about. None of it is a black box: everything behind a decision is shown to the person who has to act on it.

Tidy the data before comparing it

Company suffixes, people's names, registration numbers, addresses and matter numbers are put into one consistent form first. You compare the companies, not two people's typing habits.

Weigh the evidence, do not guess

A rare name matching is strong evidence, a common one is weak, and a missing value counts for nothing. Every line of that reasoning is kept, so a reviewer reads why rather than trusting a score. The method is Fellegi–Sunter, the standard in record linkage.

Some differences count against a match

Company suffix, country, entity type and qualifiers in the name count strongly against a match when they disagree. That is how two companies in the same group stay two companies.

When a group stops making sense, Datum stops

Merges chain: A matches B, and B matches C. When the chain grows past what the evidence supports, Datum suspends it and flags it, rather than producing one record that is really three companies.

Northgate Wells LLP
Home Queues Match review
as at now
4
Priya Raman Data steward
Queues
Match review 1,274
Suspended clusters 8
Escalations 63
Data quality 17
Hierarchy 24
Drift 1
Data
Search
Import
Reference data
Taxonomy
Hierarchies
Tasks
Match review
12 of 1,274
Assigned to me
Pair
Group
Graph
Organisation
Cavendish Technologies Ltd
blocked on name_token, postcode
Match probability
0.9612
Proposed
Attribute
elite3e · LON000901
elite3e · MAN000233
Normalised name
CAVENDISH TECHNOLOGIES
CAVENDISH TECHNOLOGIES
Entity suffix
LTD
LTD
Postcode
M1 1AA
M1 1AA
Registration no.
07731204
not supplied
Country
GB
GB
Evidence — Fellegi–Sunter weights total +12.26
Normalised name
+7.18
agrees exactly — a rare value, about 0.08% of records
Postcode
+4.32
agrees exactly on ‘M1 1AA’
Entity suffix
+0.76
same value — weak positive, since values are skewed
Registration no.
0.00
missing on one side, so it carries no weight
Confirm C
Reject R
Defer D
Undo window 8s
3 hidden by an ethical wall
Match review 12/1,274
Organisation Cavendish Technologies Ltd
0.9612
Proposed
Evidence total +12.26
Normalised name
+7.18
Postcode
+4.32
Entity suffix
+0.76
Registration no.
0.00
Confirm
Reject
Defer
The review screen on the demonstration firm. The evidence panel adds up everything for and against the match; the amber mark on the bar is the point above which this firm has said Datum may merge on its own.

One record, built field by field, and it tells you so.

Choosing which value wins is where a system like this earns your trust or loses it. The rules are yours, written in plain terms, and a person can always overrule them.

Four kinds of claim, never mixed up

A value checked against Companies House, a value someone at the firm asserted, a value copied from one of your systems, and a value Datum worked out from a match are four different strengths of claim. They are coloured differently on every screen, because "these names look alike" is not "this company owns that one".

Merging, unmerging, and a record of both

Every decision is recorded with its reason, takes effect at once with a window to undo it, and survives a full re-run of the matching. Datum will not re-propose what a person has settled. Undoing a merge is a normal operation, not a support ticket.

Northgate Wells LLP
Home Records Pemberton Holdings Ltd
as at 12 Mar 2014
Priya Raman Data steward
Queues
Match review1,274
Escalations63
Data quality17
Data
Search
Import
Reference data
Taxonomy
Hierarchies
Legal
Party register
Registry checks
Retention
Golden record
Pemberton Holdings Limited
Organisation
MST-0041-7729-PH
Propose a change
Attributes
Sources 4
Hierarchy
Matters 37
History
Lineage
Attribute
Surviving value
Provenance
Legal name
Pemberton Holdings Limited
Companies House
Registration no.
04471902 verified 14 Aug
Companies House
Registered office
1 Ropemaker Street, London EC2Y 9AW
Companies House
Trading name
Pemberton Holdings
Elite 3E
Entity suffix
LTD
Standardised
Group parent
Pemberton Group Holdings plc
Steward
Practice area
Corporate — Mergers & acquisitions SALI L1.C.02
Steward
Sector
Industrials inferred
From matching
Client since
12 Mar 2014
Elite 3E
Relationship partner
A. Wainwright
Elite 3E
Billing arrangement
Withheld — not permitted by your role
Provenance
External register3
Steward assertion2
Source system5
Inferred from matching1
Contributing sources
elite3eLON000412
elite3eJHB000118
crmC-8841
companies_house04471902
Recent changes
Group parent set to Pemberton Group Holdings plcP. Raman · 28 Aug 2026
Registered office refreshed from Companies Housesystem · 14 Aug 2026
Merged with JHB000118 after steward reviewA. Osei · 02 Aug 2026
as at 12 Mar 2014
Golden record MST-0041-7729-PH
Pemberton Holdings Limited
Surviving values & provenance
Pemberton Holdings Limited
Legal name · Companies House
04471902verified 14 Aug
Registration no. · Companies House
Pemberton Group Holdings plc
Group parent · steward assertion
Industrialsinferred
Sector · inferred from matching
Withheld — not permitted by your role
Billing arrangement
A company record as it stood on the day the client relationship opened. The billing arrangement is withheld from this person's role and shown as withheld: a field you may not see and a field nobody filled in are different problems.

Every relationship, held as data.

A record on its own answers little. The questions a firm actually asks are about groups, parties and people, and each of those is a dated link with a source.

Groups and hierarchies

The whole corporate structure is held so that every parent is one step away, which makes "what have we done for this group?" a fast question. You can model a restructure that has not happened yet, and any total respects the ethical wall.

Parties and matters

Who is on which matter, in which role, from when. Clients, counterparties and the other names they go by are one register, so a matter's parties are a list you read, not a search across systems.

People and roles

Who was assigned, at what rate, and where they are admitted to practise, each with the dates it applied from. "Who was on this matter in March?" is a question you ask, not an archaeology project.

Two clocks on every link

Every link carries two dates: when it was true, and when the firm recorded it. Ask what the firm knew on the day a matter opened and you get that answer, not today's answer applied backwards.

Data quality is a queue, not a report.

Everything Datum finds wrong, uncertain or unfinished becomes a piece of work with an owner, a reason and a deadline. Six queues, built the same way, so someone new can clear two hundred items with a one-page guide.

Match review

Possible duplicates waiting for a decision, with the evidence for and against each one added up line by line.

Suspended clusters

Where Datum stopped a merge growing past what the evidence supports.

Escalations

Raised by a reviewer, routed to the right person, with a deadline.

Data quality

Broken rules, ranked by seriousness and by record type.

Hierarchy

Suggested parent companies, and records that have none.

Drift

A source system that has started disagreeing with itself.

Rules your firm can write

Written in a simple expression language and checked as you type. Anything they catch arrives as work to do, not as a report nobody opens.

A workflow you can look at

Each queue's steps and the moves between them are drawn as a diagram. A mistake in the routing survives a review as prose; it does not survive being drawn.

Search that understands legal names

Ltd, Limited or LTD finds the same company. Permissions apply while the search runs, so nothing screened ever reaches the results.

Reference data and a classification the industry already uses.

Code lists, mappings between systems and the way work is classified are held as data rather than written into the software. A new version is a migration, not a rewrite.

The industry standard for classifying work

Datum uses SALI LMSS, the classification the legal industry has settled on, plus your firm's own additions and a mapping from however you classified work before.

Mappings between systems, held as data

How your practice management system's codes line up with the CRM's is a table your team can read and change, not a rule buried in a connector.

A queue for what did not fit

Anything an import cannot place lands with a person to clear, never in a silent default nobody sees.

The data model is a screen, not an appendix.

The first question every evaluation asks is what the data model looks like. Datum answers it from the product, drawn from the same source your own systems read. Because the model is data rather than code, your firm can add a field, watch it be validated, and publish it without waiting for a release.

Northgate Wells LLP
Home Design Data model
as at now
Priya Raman Data steward
Queues
Match review1,274
Escalations63
Design
Data model
Workflows
Survivorship rules
Match thresholds
Entities in view
Organisation
Person
Client role
Matter
Internal person
Org unit
Data model
served from /v1/schema · catalogue northgate-1
100%
+
Fit
1..n 0..n 1..1 1..n 0..n 0..n 1..n party_organisation 14 attrs master_iduuid · pk normalised_nametext registration_numbertext · idx entity_suffixenum party_person 11 attrs master_iduuid · pk family_nametext given_namestext[] date_of_birthdate · masked client_role 9 attrs client_iduuid · pk party_master_iduuid · fk relationship_partneruuid · fk opened_ondate org_unit 7 attrs unit_iduuid · pk parent_unit_iduuid · fk officetext practice_grouptext matter 18 attrs matter_iduuid · pk matter_numbertext · uq sali_practice_areacode lifecycle_stateenum internal_person 12 attrs person_iduuid · pk bar_admissionsjsonb rate_card_iduuid · fk assignment_perioddaterange Every entity above is bitemporal. Exclusion constraint: one business key, one current truth.
Selected — matter
Attributes18
Records41,882
Sources2
Open violations1,043
Lifecycle gates
Intake checkpoint cleared
Number issued
Practice area required
Closure not reached
Withheld by role
billing_arrangement
Data model GET /v1/schema
Entities in view 6 of 91 tables
Organisation 14 attrs
Person 11 attrs
Client role 9 attrs
Matter 18 attrs
Internal person 12 attrs
Org unit 7 attrs

Every entity keeps its history. The database itself enforces one current version per thing.

The data model canvas, read live from the demonstration firm's configuration. Ninety-one tables in PostgreSQL 16; every entity keeps its history, and the database itself enforces one current version per thing.

The two things a firm gets wrong most expensively.

Where the cost of a bad record lands: in a report, a pitch, or a bill.

Matters

Matter numbering, the stages a matter passes through, and the checks it has to clear before it moves, recorded rather than remembered. A matter that skipped a check is visible as one months later.

People

Assignments, rates and admissions, each with the dates it applied from. The dates are the point.

Watch it run, start to finish.

One hour on the demonstration firm: the mess as we generated it, someone clearing the review queue on real evidence, the record it produces, and where it plugs into what you already run.

Book a demo

Questions before booking? Use the contact form.