How it works · thespine.tech · The mechanics in plain English

How it works
isn't a diagram.

It's the discipline of saying yes to a merge, and saying no to a guess. Four moves, in order, every time.

Read time · ~4 minutes · No source names · No engine internals
01
FIRST MOVE Deterministic merge

Two records.
Two deterministic matches.
We merge them.

One matching data point is a signal. Two deterministic matches are a fact. If two records share two key deterministic identifiers — email + phone, email + domain, phone + address hash — we treat them as the same entity. No probability score. No confidence threshold. The merge is binary, traceable, and trivial to explain to your audit team.

Requiring two deterministic data points to agree is what separates a real merge from a lucky collision. Most identity vendors drop this bar to one. We don't. Roughly seventy percent of merges in a typical buyer's data resolve here, before any enrichment touches the graph.

02
SECOND MOVE Enrichment to threshold

Only one match?
Enrich until
two agree.

When two records share only one deterministic data point, we don't merge yet. We enrich both records — appending key identifiers like emails, phones, domains, and address hashes from 270+ sources — until a second key data point either confirms the match or rules it out. The merge fires only when two key identifiers agree.

We expand only to durable, key matching data points. We don't lean on transient signals like IP, cookies, or short-lived ad-tech tokens to force a merge. Enrichment stays in its lane: not a replacement for deterministic signal, but a way to find the second key identifier that makes the deterministic merge safe. Every enrichment step that contributes to a merge is logged. You can always see which source provided the confirming identifier.

03
THIRD MOVE Provenance — the receipt

Every merge carries
its receipt.

When two records become one, the merge writes its own paper trail — which records, which fields, which inputs, which rule, which confidence, which time. The trail lives next to the entity, not in a separate audit table you have to join against.

Your privacy lead can ask "why did this person become this person?" and we can answer in one query. Your C-Suite can run the same query against last quarter's export. Your data scientist can subtract a specific input source and re-run resolution to see what changes. The graph is reproducible because every merge is reversible.

04
FOURTH MOVE Continually refreshed

Yesterday's graph
is yesterday's graph.

Identity drifts. People change phones. Households move. A merge that was correct in March can be a mistake in May. The graph is continually refreshed from raw — not patched, not incrementally updated, rebuilt.

This is more expensive than incremental update. We pay that cost so you don't inherit a graph that quietly compounds bad merges from six months ago. The buyer who lights up on this is the one who has lived through a vendor's silent identity drift and learned to fear it.

That's the work.
Want the result?

Forty-five minutes. We walk the schema, run resolution against your file, and show you each merge with its receipt.

TheSPINE