Entity resolution.
The same person shows up as an email address, a calendar attendee, a name in a transcript and a contact in a CRM. Deciding when those are one person, and when they are not, is where most knowledge graphs quietly go wrong. Team0 treats it as the most conservative part of the system.
Merge on proof, suggest on resemblance.
The line that matters is which signals may merge two records on their own, and which may only suggest a merge.
- Keys that merge
- An email address, including secondary addresses on the same record. A company domain. A workspace-unique chat identity. An exact normalised name, including the same words in a different order.
- Signals that only suggest
- An initial that expands to a full name. A spelling within two edits. These never merge on their own: a model checks that the two are the same person first, and anything uncertain goes to a person.
- Signals that never match
- Phone numbers. A signature line can carry a shared company number, so a phone is stored as enrichment and never used to decide that two people are one.
Identity is decided at the door.
Most systems ingest first and clean up duplicates later. Team0 resolves identity as each record is written.
- 01Strong key matchesA known address or domain binds the incoming record to the existing entity.
- 02New address, same personA strong match that brings a new address adds it to the person’s record, atomically.
- 03Same name, conflicting addressSplit into a clean new record rather than merging two people who share a name.
- 04Nothing matchesA new entity is created, and the nightly resolver looks again with everything it now knows.
You, specifically.
The owner of a workspace appears in almost everything. Getting the owner’s identity right is its own problem.
Addresses that Gmail has verified as sending on your behalf are treated as yours. A look-alike address is asked about once, in the workspace, and never assumed. A name that matches yours is never, on its own, treated as you.
Relationships read from prose are checked twice.
“Dana works at Acme” in an email is a claim about a relationship. Team0 treats it as one.
Relationships extracted from prose, such as who works where, who is whose client or investor, who introduced whom and who reports to whom, are re-checked every night against the exact words they came from. If Team0’s model and a model from another vendor both find that the text does not support a link, it stops counting as fact and becomes a candidate.
In transcripts, a name that sounds like someone you know is linked to the record of the person you actually meet with around that time, rather than to anyone with a similar name.
The rules identity follows.
- 01
Keys merge; resemblance never does on its own
Matching addresses merge. A similar name merges only after a model check that the two are the same person, or in one clear case: a bare first name with no address of its own and exactly one full-named person with that first name in your active circle. Every merge is reversible.
- 02
A merge leaves a tombstone
Merged records point to the survivor rather than disappearing, so any merge can be undone and every past reference still resolves.
- 03
Confidence is never the decider
A model saying it is fairly sure two people are the same is not enough. Verification returns a yes, a no or an unsure, and only a yes changes anything.
- 04
Every address counts for the right person
Activity sent to any of a person’s addresses, including ones held on a merged record, counts toward that person.
Compared with typical entity resolution.
| The usual approach | Team0 | |
|---|---|---|
| When | Batch deduplication after ingest | At the moment each record is written, plus a nightly pass |
| Similar names | Merged above a similarity threshold | Never merged on similarity alone; a model or a clear first-name case must confirm |
| Conflicting addresses | Often merged by name | Split into separate records |
| Relationships from text | Taken from one model’s extraction | Re-checked nightly; demoted when two vendors’ models find no support |
| Undo | Rarely possible | Every merge is reversible |
- OverviewThe World Model
- Data modelStatements, two clocks, belief lanes
- Truth maintenanceHow beliefs are retired, never deleted
- Trust and scopeWho said it, who may see it
- Understanding EngineFrom graph to a read an agent can use
- Memory vs understandingWhat a memory layer does, and what understanding adds
- The 31 problemsEverything you have to solve, in one list
Your agents will change. Your understanding shouldn’t.
Invite-only private beta.