The short answer
Similarity can suggest an alias; it cannot establish that two records describe the same entity.
Resolve aliases without merging different people, clients or projects. Use stable identity, scoped names and a review queue for uncertain matches.Check identity before merging records
Your meeting notes mention "J. Park." The client directory lists "Jordan Park." They might be the same person, until another Jordan Park appears at a different company. Merge the records too soon and you can attach accurate facts to the wrong person.
Entity resolution decides which records refer to the same thing. It should preserve uncertainty instead of turning every similar string into a shared identity.
Use more than the display name
| Signal | Useful for | Limit |
|---|---|---|
| Stable source identifier | Joining records from the same source system. | Identifiers may be local to one system. |
| Organization and role | Separating similarly named people. | Roles and employers change. |
| Source-supported alias | Linking a short name to a known record. | An abbreviation may have several meanings. |
| Spelling similarity | Finding candidates for review. | Similarity is not identity. |
Names are labels people can change. Keep a stable internal identity where your system supports one, and preserve the source identifiers that justify the mapping.
Create a reviewable alias decision
In a fictional supplier directory, "Aster Ltd" and "Aster Limited" share the same verified source identifier. That supports an alias decision. "Aster Labs" shares a word but has a different identifier and business scope. Keep it separate.
Candidate names: Aster Ltd / Aster Limited
Supporting source: Supplier directory entry S-204
Decision: Same supplier in this source
Canonical display name: Aster Limited
Preserved aliases: Aster Ltd
Excluded candidate: Aster Labs
Review evidence: Link to the directory recordCheck uncertain matches before connecting important records
If you cannot resolve the identity, maintain two records or an unresolved candidate relationship. A longer review queue is preferable to attaching another client's commitments to the wrong project.
OpenRefine's cell-editing documentation describes clustering and reconciliation workflows. The useful distinction is between discovering candidates and confirming identity. Neither a tool nor a high similarity score removes the need for evidence.
Test collisions before importing at scale
Build a small synthetic set with two people sharing a surname, two projects sharing a short name and one genuine alias. Ask questions whose answers differ between the lookalikes. Check that retrieval does not combine their facts.
Include a rename and a person changing roles. If someone changes roles, a correctly merged record still needs dates to show which role applied when. Preserve the alias history and avoid silently rewriting old sources to match the newest label.
Resolve the identities your work depends on
Do not resolve every name in a large archive before you have a use for it. Prioritize entities that affect active tasks and consequential joins. Record the unresolved cases in the source worksheet.
Gigabrain provides a connected knowledge structure, but source-supported identity still matters. Inspect its graph model and evidence, then compare packages for your agent’s knowledge system.
Keep two people with the same alias separate
The executed fixture contains Jamie Park, who owns Project Alder, and Jordan Park, who owns a garden shed. Both carry the alias "J. Park".
| Record | Supporting source | Identity decision |
|---|---|---|
| Jamie Park / J. Park | owner.md names the project owner. | Retain the project-owner entity. |
| Jordan Park / J. Park | unrelated.md names the shed owner. | Retain a separate entity. |
An alias match supplies a candidate identity. It does not establish that both records describe one person. Inspect the fictional sources and the ambiguous-identity case in the executed results.
The fixture deliberately authors these identities. It is not a test of a model discovering aliases or deciding to merge people.
Record the reason for each identity decision
- List the candidate records.
- Compare their roles and source context.
- Record support for a match or separation.
- Leave unresolved cases separate.
- Review affected relationships before accepting a merge.
Use the identity-review worksheet. It records a review decision, not an instruction to merge records in the product.
Method note: Gigabrain Labs prepared this material with AI assistance. Fictional teaching examples and executed results are labelled separately.
