The worked example
Most documentation teaches with two records that differ in one obvious way. Real data does not look like that, and neither does this.
Every worked example in this documentation is a slice of the record set below. The people are invented — no documentation should carry real personal data — but nothing else is. The attribute names are the ones the shipped person model actually defines, the value shapes are the ones the platform actually stores, and the disagreements are the ones it was built to reconcile.
One person, six systems
A retail bank holds the same customer in six places. No two records agree.
| System | Given name | Middle | Family name |
|---|---|---|---|
| CRM | Jon | — | Pemberton |
| ERP | Jonathan | — | Pemberton-Hayes |
| KYC | Jonathan | Stuart | Pemberton-Hayes |
| Mobile app | Johnny | — | PEMBERTON |
| Loan origination | Jonathan | — | Pemberton Hayes |
| Credit bureau | J | — | Pemberton-Hayes |
Six spellings of one name, and each is correct in its own system. The CRM holds what he calls himself. KYC holds what his passport says. The mobile app captured a nickname. The bureau abbreviates. Loan origination lost the hyphen to a form that would not accept one.
Only one field agrees everywhere:
date_of_birth 1979-08-22 (all six)
Where the evidence actually is
The name is the noisiest field. The evidence lives elsewhere, and it is uneven.
| CRM | ERP | KYC | Mobile | Loan | Bureau | |
|---|---|---|---|---|---|---|
date_of_birth | ● | ● | ● | ● | ● | ● |
email | ● | ● | ● | ● | ● | — |
phone | ● | ● ● | — | ● | — | ● |
address | ● | ● | ● | — | ● | — |
middle_name | — | — | ● | — | — | — |
Two things fall out of that grid immediately.
A phone number ties three systems together. +15553001001 appears in CRM as
a mobile, in ERP as a mobile, and in the credit bureau record as a home
number. The usage type disagrees; the number does not. ERP carries a second
number, +15553009002, typed work.
Nobody holds a government identifier. There is no ssn on any of the six.
That matters more than it looks: it removes the one shortcut that would settle
this instantly, and forces the pair to be decided on accumulated evidence
instead. Most real clusters are like this.
The address that looks like a conflict and is not
Three systems hold an address, and two of them write the same street differently:
| System | address.line1 | address.postalCode | Usage type |
|---|---|---|---|
| CRM | 12 Old Mill Road | 06103 | home |
| ERP | 12 Old Mill Rd | 06103 | home |
| KYC | 12 Old Mill Road | 06103 | home |
| Loan origination | 440 Asylum Avenue | 06105 | mailing |
Road and Rd are the same street. Standardization
resolves that before anything is compared — and note the direction, because it
is the opposite of what people expect: the platform expands abbreviations
rather than contracting them, so both land on old mill road and converge.
The loan record is a genuinely different address, at a different postal code,
and it is typed mailing rather than home. That is not a conflict to
resolve — it is a second, true address that
survivorship keeps alongside the first.
Without it, 12 Old Mill Road and 440 Asylum Avenue look like two systems
disagreeing about where he lives. With it, they are a home address and a mailing
address, and both survive.
What a reader should take from it
Follow this record set through the guides and each stage has something real to do:
| Stage | What this cluster forces it to handle |
|---|---|
| Standardize | PEMBERTON casing, Rd versus Road |
| Match | six name spellings, no shared identifier |
| Review | pairs that land between the thresholds |
| Survivorship | which name wins, and both addresses surviving |
| The 360 view | one record, with all six inputs still visible |
Source records and crosswalks
The six above are separate records because nothing has matched them yet. Once records are linked to one entity, the link is a crosswalk — the entity plus each system's own identifier for it.
A different fixture in the same pack shows the shape, for a customer already resolved across three systems:
System Record type Identifier in that system Confidence Primary
ERP CUSTOMER ERP-CUST-100001 100 yes
CRM CONTACT CRM-CON-A8K42P 95 no
MARKETING LEAD MK-LEAD-7842 80 no
Read the middle column. The same human is a customer in the ERP, a contact in the CRM, and a lead in marketing — three systems that do not even agree on what kind of thing he is. The crosswalk records that without forcing any of them to change.
Next
Last verified against commit 5fe30d28 (2026-08-03)