Building an identity resolution system.

Search "Maria Garcia, software engineer" on LinkedIn. You'll get over 400 matches. Now imagine your AI-powered briefing system picks the wrong one — and writes a detailed, internally coherent profile about a completely different person.

That's the problem we ran into building Reedy Meet's automatic briefing pipeline. LLMs are exceptional at synthesizing information. They are not, by design, identity-verification tools. They have no native mechanism to detect when results for "Michael Smith" are pulling from three different people who happen to share that name. Solving that requires a fundamentally different approach — one that quantifies certainty rather than inferring it.

Overview of the meeting detail page.

There's no clean threshold that separates "this is the right person" from "this isn't." The available evidence varies too much. Sometimes you have five independent signals converging on the same profile. Sometimes you have a single mention in an outdated directory from 2019.

Modeling that uncertainty as a continuous value between 0 and 1 isn't just an elegant design choice — it's what allows the downstream system to be calibrated about what it knows and honest about what it doesn't. The confidence used to assert something should be proportional to the evidence supporting it.

That score maps to four operational levels that directly control how the briefing is written:

The distinction between HIGH and MEDIUM is not cosmetic. How a fact is framed changes how much weight the reader gives it — and how much trust they place in the system that generated it.

The briefing generation system works as an agent that chains multiple tools: search, extraction, verification, synthesis. This post covers only the verification step — the guardrail that sits between raw search results and the final report.

The scoring model runs for every external participant in a meeting. Internal participants (those sharing an email domain with the meeting host) are excluded entirely. Identity resolution is only meaningful for people outside the organization — so rather than applying a score penalty, the system uses a context-based exclusion before any signals are evaluated.

The premise is simple: a single signal can fail or mislead. Ten independent signals pointing in the same direction are much harder to refute.

Each signal is a binary question — it fires or it doesn't — and each carries a weight that reflects its real-world discriminative power. Positive signals add to the score; negative signals subtract from it.

Score = sum of weights of fired signals Final score = clamp(Score, 0, 1)

Two cases make this concrete.

Elena Rodriguez — elena.rodriguez@nexusai.com

Raw score: 1.15 → clamped to 1.00 → HIGH

Carlos Lopez — carlos.lopez@gmail.com

Score: −0.20 → clamped to 0.00 → FAILED

Gmail alone isn't the problem. The problem is the total absence of positive signals combined with a very common name. A Carlos Lopez with Gmail but an active LinkedIn, a clear company, and a consistent role would score very differently.

Scores below 0.7 don't go straight to failure. Instead, the system activates a second, more targeted search using all available identifiers combined:

"Carlos Lopez" "carlos.lopez@gmail.com" "DataCorp" "LinkedIn profile"

Each result from this secondary search is treated as a candidate and scored on a different scale:

The top candidate wins only if it scores above 40 points and leads the second-ranked candidate by more than 20 points. A narrower margin is flagged as "too close to call" — and no briefing is generated.

In production, this second layer resolves approximately 85% of cases that didn't pass the first one.

A global score of 0.75 doesn't mean every fact in the profile is equally reliable. The person's company and current role might be corroborated by five different sources, while their education appears in a single result from 2019. Treating both identically would be a mistake.

The system classifies each profile field by priority and by how many critical signals fired:

The briefing generator receives explicit instructions for each tier:

The result is a report that's honest about its own degree of certainty — not an undifferentiated mix of facts and assumptions.

Two reasons.

The pragmatic one: labeling enough cases to train a reliable model has real cost in time and money. Iteratively tuned weights produce 2–3% error rates on HIGH cases. That's sufficient for the problem being solved.

The more important reason is interpretability. When the system returns a MEDIUM score of 0.67, you can see exactly why: which signals fired, which didn't, and what information was specifically missing. A black-box model returns a number with no explanation. In a product where user trust depends on being able to audit decisions, that difference matters more than marginal accuracy gains.

Weights are also just parameters. If production data shows email_exact_match is more discriminative than expected, the weight goes from 0.25 to 0.30 — no retraining required.

Score distribution across all processed participants:

73% of cases reach sufficient confidence to generate a briefing. The 27% that don't reflects the system's real limitations — not a design failure. A system that's honest about uncertainty is more useful than one that papers over it.

From weekly manual validation on 50 random cases:

23% of cases trigger the disambiguation layer. Of those, 85% are resolved with enough confidence to proceed.

The system performs well for tech professionals with active digital presence: engineers with GitHub profiles, LinkedIn, blog posts, or conference appearances. Also for executives with press coverage.

Three scenarios consistently produce lower performance:

Recent job changes. The web takes weeks or months to re-index. Someone who changed companies three weeks ago may still appear in their previous role across most results. The score drops appropriately — the email domain won't match what the results show — but the system can't determine which version is current.

Professionals in traditional sectors. The system is optimized for the tech environment, where digital footprint is high. An executive in manufacturing or distribution with low online presence can produce low scores even if they're clearly identifiable through other means.

Namesakes within the same company. Two people named "John Lee" at TechCorp will confuse the system even when the domain matches perfectly. This is the primary source of false positives, at a rate of 2–3% in HIGH cases.

Generated participant report view.

Resolving identity on the web is an evidence-accumulation problem — not a search problem. The gap between "finding information about someone" and "verifying that the found information belongs to that specific person" feels subtle, but it changes everything about how the system needs to be designed.

The scoring model described here isn't perfect — no heuristic system is. But it's interpretable, tunable, and calibrated in the right direction: it prefers silence over confident mistakes. In applications where an identity error undermines product credibility, that's exactly the right stance.