The customer-data layer under a real-estate book.

Messy contacts, a one-hop referral field, unprovable keep-in-touch: three pains, one stack.

It starts with capture and ends with proof. Layer 1 is where the data comes in; everything downstream depends on Layer 2 getting identity right first.

The keystone. And it stands alone.

Before any graph or analytics, you have to know who is who. A 59-row import (nicknames, diacritics, Jr/Sr, spouses sharing an inbox, office lines, junk) resolved into clean entities. (This import fixture is the resolver's own stress set, separate from the 20-person referral book the later layers run on.) The design that matters: assisted, banded, evidence-rich, non-destructive. It merges only what's certain and hands the gray zone to a person with the reasons attached.

• 1.00 / 0.67Auto-merge precision / recall. Precision is 1.00 by design: it auto-merges only what's certain. The recall it gives up isn't guessed; it's routed to a person.
• 1.00Recall once review is included. Every true duplicate surfaces somewhere, merged or flagged. Nothing silently lost.
• 1.00 / 1.00Spouse-split & non-person precision/recall. Two people on one record become two contacts; “WiFi Password” never becomes one.
• 28Adversarial stress rows. A second fixture built to break it: family emails shared across a household, recycled phone numbers, hyphenated married names, firm names that read like couples. The first run cracked the auto band (precision fell to 0.50). Two guards later it holds 1.00 on both fixtures, by demoting doubt to review, never by discarding.

The decision ledger: what it did, and why

Every call carries its evidence. Names are synthetic; the reasoning is the product.

The adversarial set: 28 rows built to break it

The import above is realistic mess; this second fixture is engineered traps. Every decision below is the engine's current output on it, and the pattern is one rule applied everywhere: when the evidence cuts both ways, ask a person instead of guessing.

Still missed, and named: a flipped name order (Zhang Wei / Wei Zhang) never even becomes a candidate pair (needs its own blocking pass; parked), and a nickname pair with two fully-populated records and zero shared identifiers scores below the review bar; the real fix there is multi-value identifiers, on the roadmap. Score on this set: auto-merge precision 1.00, recall including review 0.71. Worse numbers than the clean import, on purpose; publishing them anyway is the point.

Go deeper: the resolver's two companion pages

On the honest edges: measured against Cloze's real importer (a 59-row live test, July 2026), the overlap is real: both merge on a shared email or typed phone when the names agree. The differences are at the edges. An importer can't reach a duplicate with no shared identifier (an email-only record and a phone-only record for the same person), and when a shared identifier meets a changed surname it drops the second record as invalid; this engine links the first case and routes the second to review, and it never discards data. Candor cuts both ways: the adversarial set above initially cracked this auto band too, fixed with guards that demote to review rather than guess. A household split is a flag, not an auto-action: we surface the two people and bundle the shared contact info, but assigning which phone or email belongs to whom is a human call (and cleanly needs multi-valued contact fields, on the roadmap). And middle names compare on the first token, so “Chad Michael” still matches “Chad” rather than mis-flagging as a household.

Who actually drives your business?

A flat “referred by” field stops at one hop. This traces credit multi-hop, decayed per hop, so the person who seeded a chain gets seen, even when they closed nothing themselves. Nodes are colored by referral archetype (a behavioral attribute Cloze doesn't segment on) and sized by the volume they touch. Hollow rings closed $0 of their own; a dashed ring marks an outlier whale deal. Flip the toggle and watch the hidden originators grow.

Who drives the book (ranked by network influence)

$2.83M of originated volume sits with Karen Whitfield, Aisha Patel, Luis Romero, invisible to a one-hop field. Influence is an influence score, not accounting (credit duplicates up the chain). A listing self-markets and spins off buyer leads, so the mix matters as much as the dollar figure.

Deal structure: buy / sell / both / dual agency

Transactions model as deals + sides: a deal is one property; each side ties a contact to it as a buy or a sell, carrying that side's GCI. A deal with both sides = dual agency (you repped buyer and seller, one transaction). So the book classifies every client and flags dual deals, not just a single buy/sell tag, and volume counts the property once even when you earn both commissions.

Referral archetypes: the “beyond what they have”

Cloze segments by stage and lifecycle. None of them segment by referral behavior. Five bins, tendencies not verdicts: a lens. And they're living labels, recomputed from current activity every run: tag a One-and-done as a referrer on your next deal and she moves toward Connector; as the book's average sale price rises, a Harpoon slides toward Connector. Not a permanent stamp.
Property-sourced leads aren't referral-archetyped; they have no referral behavior to classify, so they sit out of these bins (see Lead sources below).

Two engines feed the book: relationships and inventory.

The graph above is mostly your personal-derived engine: people sending people. But a property is a lead-gen node too: a listing's open house spawns buyers who often close elsewhere, and a sale farms its neighbors. Those are property-derived leads. In the graph they hang off the source listing's owner on a dashed line: a real link, but not a referral, so it carries no referral credit. One book, two engines; in production the property side hydrates from the MLS, another source plugging into the same resolved-entity core (Layer 1).

Where the two engines meet

Properties and people aren't separate graphs; they're one. Here a single listing is the hub: a referral brought you the seller, and the listing brought you more buyers. Both engines, one resolved property.

Everything above is one agent's book.

A brokerage promises the client a relationship with the firm, but every book is isolated, rightly. So when the roster changes, the firm forgets. The question that answers is the one this whole project started from: how does a brokerage pool its agents' data without breaking the per-user isolation and the real-mailbox moat?

The wedge: an agent leaves, and the book does not go dark.

Flip the toggle. 1 of 3 agents departs and the graph routes each orphaned client to the agent who already has a link, not round-robin. 3 of 4 land on a real relationship path, and the one that cannot is flagged as a load-balanced fallback rather than dressed up as a match.

Co-owned GCI is counted once, in the owning book, and the co-ownership is flagged rather than double-billed. Tom Gallagher earned $10K of influence inside Maria Santos's book by handing over one buyer, which a per-agent production ranking cannot see. Cross-agent links are assisted and banded: a human confirms, and a name-only match is review, never auto.

Governance is the spine, not the headline.

Brokers buy the outcome. Governance is why the agents say yes, and it is the whole difference between this and the surveillance version anyone could build. So the visibility rules ship opinionated: one matrix, not a matrix builder.

Agreed while relations are good, so offboarding stops being a fight, and it cuts both directions: the same architecture is the arrival-side answer to a recruit asking what the firm will be able to see. Every surface answers to five checks:

1. Does it act for the agent in the moment, or on them?
2. Aggregates to the broker: fine. Individual activity to the broker: surveillance.
3. Symmetry: the agent can always see what the firm sees of their book.
4. Does the intel route opportunity, or feed discipline?
5. Identity and deal facts pool. Notes, sentiment, and message content never do.

Synthetic 3-agent fixture, ~470 lines of stdlib Python on top of the same resolver above; both this panel and the companion render one JSON the engine emits. Production wires the identical engine to the real per-agent books.