Spec “same person” before you sync writes.
Syncing the same person across systems is a write. Decide what counts as a match before that write is allowed to land.
Before a sync writes the same person into a second system, fill a TWIMCO Identity Match Spec: which identifiers may match, what never matches alone, how conflicts resolve, and who may merge or unmerge. A shared email is not an identity policy.
The sync will invent a person if you let it
Two systems both have a customer named Maya. One has her work email. One has her personal email and an old phone. A nightly job “matches” on email when it can, and on name-plus-zip when it cannot. One Tuesday it glues the wrong Maya to a payment profile. Support spends a week untangling. Engineering says the matcher is “usually fine.” Usually is not a spec.
If you are about to let automation write across systems, the first product question is not the field map. It is: what does “same person” mean here, and who is allowed to say so when the signals disagree?
This note is the TWIMCO Identity Match Spec—short questions with answers you write down before the sync may create, update, or merge a person record. The filled answers are the unreproducible asset. There is no public quiz that already knows your identifiers. Copy the questions. Leave “unknown” when it is true.
When the work is the handoff and verification between business systems, the natural home is business process automation. The CMS can keep related work without forcing a tour of a past project into the prose.
Q: What may prove a match?
A: Only the identifiers you name, with the strength you name.
Write the strong keys first: a stable external id both systems already share, a verified customer id from the system of record, a payment customer id that both sides treat as authoritative. Then write the weak keys: email, phone, name, address. Say which weak keys may never match alone. Say which combinations may propose a match but must not write until a human confirms.
Q: What must never match alone?
A: The fields that collide in the real world. Shared household emails. Shared phones at a front desk. Common names in a small city. A truncated loyalty number. If your job currently matches on any of these alone, the answer on the spec is not “it works in prod.” The answer is either “forbidden as sole key” or “propose only.”
Q: Who is the system of record for the person?
A: One system owns the canonical person row for this sync’s purpose. The other systems may hold copies. If two systems both believe they are canonical for the same attributes, the sync will thrash. Name the owner for identity attributes separately from the owner for, say, open orders—if they differ, write that down.
These three answers alone stop the most common silent merge. If you cannot answer them, stop the write path and leave the sync read-only.
How the work moves
Answer before the write
- Name strong keys
Ids both systems already treat as authoritative.
- Forbid sole weak keys
Email, phone, or name alone cannot auto-write.
- Pick the person owner
One system of record for identity attributes.
- Write conflict rules
Block, propose, or prefer—never silent guess.
- Name merge roles
Who may merge, who may unmerge, what they see.
A sync that guesses “same person” is a merge with no owner.
Q: What happens when signals disagree?
A: A conflict rule, not a coin flip.
Same strong id, different emails: which email wins, or do both remain as typed alternatives? Same email, different strong ids: block and queue—do not merge. Fuzzy name match above some internal score: that score is yours to define, but the spec must say “propose” versus “auto-write.” Do not put a magic threshold in this note as if it were universal. Write the rule your operation will defend.
Q: Who may merge, and who may unmerge?
A: Roles, not a shared inbox. Merging two person records is an irreversible-looking act for support and for finance. Unmerging is often worse if orders and messages already moved. Name the role that may confirm a proposed match, the role that may force a merge when keys conflict, and the role that may split a bad merge. If nobody may unmerge, say that, and make auto-merge harder.
Q: What does the operator see?
A: Enough to judge. Both candidate records, the keys that matched, the keys that conflicted, and the action about to run. A spinner that says “deduplicating” is not a review surface.
Q: What do you log?
A: Match decision, keys used (not secrets), actor, timestamp, and whether it was auto or confirmed. You need enough to undo a story. You do not need to log full payloads into a place that becomes a second PII store by accident.
The conflict and merge answers are where product and engineering meet operations. Skip them and the sync still “works”—until the wrong person gets the message, the credit, or the ban.
Refuse the matcher that only works on the happy path
A few failure shapes are boring and expensive. They are composites, not client metrics.
The job matches on email, lowercased. Two people share an inbox. One person’s orders appear in the other’s history. Sole-key email was forbidden on the spec—or should have been.
The job matches on “name plus last four of phone” because a vendor demo did. The collision rate is someone else’s problem until it is yours. Weak combo without a propose step belongs in the refuse pile.
A support agent merges two profiles from a dropdown with no reason code. The next dispute cannot explain why the ledger moved. Who-may-merge was never filled.
A reverse sync re-creates a person you deleted or split, because the upstream still has the old id mapping. The spec needs a suppression or mapping table story, or the sync will undo the unmerge overnight.
If you recognize these, fix the Identity Match Spec first, then the job. Tuning a fuzzy score while the sole-key rules are wrong only makes bad merges more confident.
Decision guide
Guess versus spec
| Consideration | Matcher improvises | Spec is answered |
|---|---|---|
| Email alone | Auto-merges on a shared inbox. | Forbidden as sole key; propose only if allowed at all. |
| Two strong ids | Picks one quietly. | Blocks and queues for a named role. |
| Operator view | A success toast. | Both records, keys, and the pending action. |
| Bad merge later | Nobody can split it. | Unmerge role and mapping suppression are named. |
Put this into practice
- Pick one sync that creates or updates a person across two systems. Freeze new auto-writes if the spec is empty.
- Answer the TWIMCO Identity Match Spec questions: strong keys, forbidden sole keys, system of record, conflict rules, who may merge and unmerge, what operators see, what you log.
- Walk one real collision from last month—if you have one—against the answers. If you have none, invent the collision you fear and see whether the rules catch it.
- Only then map fields. Field mapping without match rules is how you decorate a bad merge.
- If the gap is the automation between systems, scope it under business process automation.
“Same person” is a product decision. The sync is just the enforcement.
Related work: Sutton|Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.