You are reading the First Edition (2026) archive. The Second Edition is being published at academy.buildclub.com.

WORKSHOP · ENTITY RESOLUTION · WS·10

From Conversation to Capability

The deep-dive companion to WS-08. How meeting transcripts become trustworthy memory — the resolution layer that turns raw talk into a knowledge asset, end-to-end. Three passes, two storage layers, one identity spine. 18 slides, 30 minutes.

18 SLIDES · ~30 MIN · PLAYBOOK OVERVIEW
Key Takeaways
  • Without a resolution layer, every new raw document adds duplicates, conflicts, and ambiguities. The larger the pile, the faster the search index turns into a heap of garbage.
  • Choose one pile to resolve. Do not build a 'company brain' overnight. Pick one folder — transcripts or a customer success log — and resolve it first.
  • The deep-dive companion to WS-08. How meeting transcripts become trustworthy memory — the resolution layer that turns raw talk into a knowledge asset, end-to-end. Three passes, two storage layers, one identity spine. 18 slides, 30 minutes.
WORKSHOP · ENTITY RESOLUTION

From Conversation to Capability

How meeting transcripts become trustworthy memory.

BuildClub Academy
01 · THE FALSE PARADIGM

A summary is not memory.

1
The Promise — AI Meeting Notes
Lossy reduction. Generates a generic bulleted list that captures immediate context but strips specific constraints. No linkage — a transcript from Tuesday exists in complete isolation from a transcript from Wednesday. Ambiguous entities — references to 'the client' or 'Mike' are left completely unresolved. Unverifiable — claims cannot be traced back to the exact conversational moment they originated from. Result: a pile of disconnected summaries.
2
The Reality — Trustworthy Memory
Precise facts. Extracts atomic commitments, decisions, and associations directly from transcripts. Persistent links — matches names, systems, and objects across meetings into a single graph. Canonical IDs — resolves variations of names ('Mike', 'Michael') into one distinct record. Full audit trail — retains a clear, queryable pointer to the source timestamps. Result: a single source of institutional truth.

'AI takes my notes' sounds solved. It isn't. A summary is localized and isolated. Memory must be unified.

02 · THE FIVE POINTS OF COLLAPSE

Where the raw pile fractures.

1
2
3
4
5
1
Same person, multiple aliases
One transcript says 'Mike,' another 'Michael S.,' the calendar 'mike@'. Without resolution, the AI treats them as three separate people with disconnected responsibilities.
2
Split company and system names
'ACME Corp', 'Acme, Inc.', and 'the legacy system' are mapped to separate files, preventing any synthesis of requirements or support timelines.
3
Anonymous commitments
Action items extracted as 'We'll follow up next week,' with no owner and no specific deadline. The commitment is untrackable.
4
Silent decision reversals
A Friday decision reverses a Tuesday choice. Because they live in separate files, the AI happily quotes the stale Tuesday choice as 'the decision.'
5
Unverifiable claims
The LLM answers confidently but can't cite the exact conversation, file, or speaker block, forcing humans to read back through hours of audio.

These five failure modes are not limits of the LLM's model size. They are limits of the data structure. You cannot resolve entities at query-time.

03 · THE SCALING PARADOX

More meetings.
Less trust.

Resolved entity memory holds the line.
Raw transcripts decay into a hallucination zone.
Data volume without metadata resolution
guarantees logical entropy.

The Thesis
04 · TWO GRAPHS, ONE ONTOLOGY

One structure, two views.

1
How a person browses it (Obsidian-style)
A network of nodes — Meeting A, Meeting B, Michael S., ACME Corp, Commitment — connected by associative links. Humans navigate by walking these edges. The shape is intuitive but loose; the same name can mean different things on different links.
2
How the AI reasons over it (Entity-Relation)
A typed hierarchy — PERSON → DECISION → SYSTEM / COMMITMENT — under one strict ontology schema. The machine reasons by joining typed entities. The shape is rigid but precise; every reference points to exactly one canonical record.

How humans browse (Obsidian links) and how the machine reasons (ontology entities) are not competing systems. They are different projections of the exact same resolved logical structures. The resolution engine establishes entity types (Person, Decision, System, Commitment) under one strict ontology schema.

05 · THE ARCHITECTURE

The resolution engine is the middle layer.

1
2
3
1
Raw Transcript
Messy speech-to-text dump. No standardized names or stable IDs. High semantic noise. The temptation is to point the LLM directly at it.
2
Resolution Layer
Maps aliases to identity spines. Structures actions under strict schema rules. Escalates uncertain entities to humans. Nothing reaches the database without passing through.
3
Trustworthy Memory
Pure relational schema database. Grounded, verifiable facts. Comprehensive cross-meeting queries. Intact audit trail to source files.

Do not let your LLM read raw files directly. You must insert a validation filter that cleans and structuralizes every object and name before writing to corporate memory. Raw audio is cheap. Clean, indexed facts are priceless.

06 · THE MECHANISM

The gatekeeper of truth.

1
Functional Duties
Identity resolution. Collapsing linguistic variations ('Mike', 'Michael Scheinman', 'mscheinman') into one distinct person entry. Strict state checks. Ensuring action items carry both an explicit personal owner and a target timestamp before commits. The job is to sort out who and what before anything gets recorded.
2
Technical Execution
Two-phase transactions. Generates candidates, executes matching lookup, writes structured records. Uncertainty escalation. Suspends doubtful entity matches and routes them to user feedback forms. Nothing ambiguous reaches storage; everything ambiguous gets a human-readable question.

The resolution layer is the logical gatekeeper sitting between raw transcription outputs and database memory. It enforces deterministic rules over unstructured text — the border between unstructured conversational noise and grounded factual storage.

08 · THE PROCESS

Three steps to a trusted database.

1
2
3
1
Pass 1 — Candidate Extraction
Scans raw text segments to isolate potential entities — proper names, systems and vendors, stated commitments, key decisions. Cheap, broad, and probabilistic. Designed to over-produce candidates; the next pass filters.
2
Pass 2 — Identity Resolution
Queries the local registry. Computes fuzzy match score. Maps variations to canonical IDs. Flags low confidence for human feedback. This is where 'Mike' becomes per_0042 — or escalates if the system cannot tell which Mike.
3
Pass 3 — Structured Recording
Records validated facts. Emits YAML structured blocks. Binds objects via strict schema keys. Integrates into the global memory database. Only resolved, validated entities reach this stage.

The pipeline is transactional: if Pass 2 fails to resolve and lacks human input, Pass 3 is suspended to protect database integrity. Strict isolation between candidate generation and data committing is a key architectural safety pattern.

09 · THE SCHEMA — IDENTITY SPINE

Aliases resolve to a single ID.

1
Unresolved Candidates
Three different surface forms enter the resolver: 'Mike' (from a transcript), 'Michael S.' (from a meeting note), 'mike@acme.com' (from an email). Each looks like a different person. Each must collapse to one canonical record.
2
Canonical Identity Spine — per_0042
Canonical name: Michael Scheinman. Assigned ID: per_0042. Registered aliases: 'Mike' (fuzzy score 0.92), 'Michael S.' (fuzzy score 0.95), 'mike@acme.com' (explicit match). Created: 2026-06-03 from source meet_9041. Design principle: aliases resolve strictly to one canonical ID. There are no duplicated person profiles allowed under the organization schema. All files refer to per_0042.

Never let your search index get polluted by multiple records representing the same human being. The identity spine binds all historical and future names to a single, stable pointer. The foundation of a clear search index is standardizing human and system entities.

10 · THE SPEC — YAML SERIALIZATION

Grounded and human-readable.

person_canonical_schema.yaml
# Stable Identity Spine Schema - Version 1.0.4 entity_type: person id: per_0042 canonical_name: Michael Scheinman aliases: - name: "Mike" confidence_match: 0.92 context: "transcript_block_12" - name: "Michael S." confidence_match: 0.95 context: "notes_sec_04" - email: "mike@acme.com" confidence_match: 1.00 context: "calendar_invite" meta: created_at: "2026-06-03T10:14:00Z" source_meeting: meet_9041 last_verified_by: system_pipeline_resolver associations: - role: "assigned_owner" target: com_0012 # Points to specific commitment ID - role: "decision_maker" target: dec_0085 # Points to specific decision ID

YAML is perfect for identity logs. It is clean, declarative, natively parsed by modern LLMs, and simple for engineers and humans to read back and audit during data checks. Declarative structure blocks replace long natural text files.

11 · THE SCHEMAS — ACTION AND AUTHORITY

Commitments need owners.

commitment_and_decision_schemas.yaml
# Commitment Block Schema entity_type: commitment id: com_0012 owner_id: per_0042 description: | Ship radiology section draft to PMO board folder. deadline: "2026-06-10T17:00:00Z" source: meet_9041 status: pending # Decision Block Schema entity_type: decision id: dec_0085 owner_id: per_0028 # CFO ID description: | Allocate remaining budget line to the radiology project. timestamp: "2026-06-03T10:45:00Z" reverses_decision: dec_0041 status: active

Mandatory constraint — action items must have both an assigned owner ID and target deadline. If either field is missing, the resolver flags a schema validation error. Logical temporal trace — decisions are strictly timestamped and carry explicit reference links to prior actions they modify or reverse.

12 · THE DECISION GATE

Ask, don't guess.

1
High confidence — score > 0.90
Record automatically to database. No human intervention needed. The fuzzy match score, the explicit email match, and the contextual fingerprint all agree. The system writes the link, logs the score, and moves on. This is the fast path; it should handle the majority of entities.
2
Low confidence — score < 0.90
Escalate. Ask a person: 'Did you mean Mike Scheinman?' Persistence note: once the user answers, the alias is bound to ID per_0042 and the system never asks again. One question, one answer, permanent rule. The human is part of the pipeline, not a stand-in for it.

If your pipeline is unsure, it shouldn't guess or choose blindly. Low-confidence matches drop into human verification queues. When answered, the system locks that rule forever. Uncertainty is processed as structured feedback, not silent failure.

13 · THE VALIDATION TIERS

Continuous logical linting.

1
2
3
1
Tier 1 — Syntax and schema integrity
Validates formatting parameters. Rejects empty blocks, unassigned commitments, or entries lacking a secure stable ID. All dates must conform strictly to RFC-3339. This is the spell-check layer; it runs on every write.
2
Tier 2 — Contradiction and orphan detection
Identifies logical conflicts. Flags when a decision directly opposes an active corporate guideline or when a commitment exists with no parent meeting linked. This is the logic-check layer; it runs nightly and on demand.
3
Tier 3 — Observability and auditing
Inserts pointers back to source transcripts. Annotates changes without overwriting physical file history. Assures complete transparency and audit capability. The system uses write-only logs. When logical reversals are identified, the database annotates the stale node as supersedes: dec_0085, preserving the full audit timeline.

Your database is a live organism. Just as software needs compilation checks and lint rules to verify code structure, knowledge graphs must continuously lint logic, contradictions, and orphaned entities. Continuous logical validation keeps corporate knowledge reliable.

14 · THE CENTERPIECE WORKFLOW

How a meeting becomes memory.

1
2
3
4
5
1
Transcript — Raw Input
Audio finishes, speech-to-text runs, unstructured text drops into the inbox. The only step the LLM sees raw.
2
Candidate Check
Pass 1 extracts every possible entity — names, systems, vendors, commitments, decisions. Deliberately over-produced.
3
The Gate — Confident?
Pass 2 scores each candidate. Above 0.90: commit path. Below 0.90: human queue. The difference between memory and noise.
4
Ask — 'Which Mike?'
Low-confidence candidates surface as plain questions. Once answered, the answer is bound to the canonical ID forever.
5
Commit — Trustworthy Answer
Validated entities, with full source provenance, write to the entity database. The downstream LLM queries this, not the transcript.

Nothing is recorded until every name is known — or a person has answered. This is the core transactional pipeline. It ensures that no ambiguity is committed to global memory. The result is total factual consistency.

15 · THE STORAGE SPLIT

Raw archived. Resolved queried.

1
Raw Transcript Archive
Immutable text blocks. Stores verbatim speech-to-text transcript logs. Unstructured content — high storage footprint, containing grammar errors and repetitions. Not queried by default — kept strictly for audit verification and safety backups. This is the cold store.
2
Resolved Entity Memory
Pure schemas. Stores only validated YAML entity blocks: Person, Decision, Commitment. Highly compressed — strips natural syntax, represents only connected facts. Production database — serves as the primary source of truth for downstream AI queries. This is the hot store.

Golden rule: keep the raw forever; query the resolved. Linked by a shared key ID. Do not let your search system query long raw transcripts. Archive them as safe copies. Your production models query only the resolved entity nodes, protecting your budget and context. Separate the raw text history from the verified database representation.

16 · THE ROI

The resolution payoff.

01 · Multi-hop cross-meeting queries
Query across years of meetings and trust the answer. No hallucinated names or overlapping action items. 'What did Michael commit to across all radiology meetings?' returns one ranked list.
02 · Flawless audit trails
Every fact, decision, or commitment maintains a stable ID pointer back to the exact source transcript and timestamp. Compliance reviews stop being a project. They become a query.
03 · Temporal resolution
Track how decisions evolve. Reversals are linked sequentially, resolving contradictions. 'Why did the budget allocation change?' returns the chain of decisions, not just the latest one.
04 · Intact onboarding
Bring new employees or advisors up to speed instantly. Let them query historical files with factual reliability. Institutional memory becomes a learnable artifact, not tribal.

Factual consistency is the difference between a novel toy and an enterprise-grade platform. When entities are resolved, your database becomes a single source of reliable, queryable truth. From raw, unstructured conversations to reliable business capability.

17 · MONDAY-MORNING ACTIONS

Build capability from conversation.

Monday Morning
  1. 1
    Choose one pile to resolve. Do not build a 'company brain' overnight. Pick one folder — transcripts or a customer success log — and resolve it first.
  2. 2
    Standardize the entity registry first. Compile a clean registry of names, roles, and legacy system codes. All files must bind to these keys. The registry is the foundation.
  3. 3
    Enable 'ask, don't guess' policies. When fuzzy matches fall below 0.90, halt automated entries and route to human feedback forms. Uncertainty is structured feedback, not silent failure.
  4. 4
    Ask the test question: 'When your AI is unsure, does it ask — or quietly pick one?' If the answer is the second, the rollout is not enterprise-ready.
WS·10 · Questions CEOs Ask

Frequently Asked Questions

What is the core idea of From Conversation to Capability?
Without a resolution layer, every new raw document adds duplicates, conflicts, and ambiguities. The larger the pile, the faster the search index turns into a heap of garbage.
What should a CEO do Monday morning after reading From Conversation to Capability?
Start here: Choose one pile to resolve. Do not build a 'company brain' overnight. Pick one folder — transcripts or a customer success log — and resolve it first; Standardize the entity registry first. Compile a clean registry of names, roles, and legacy system codes. All files must bind to these keys. The registry is the foundation; Enable 'ask, don't guess' policies. When fuzzy matches fall below 0.90, halt automated entries and route to human feedback forms. Uncertainty is structured feedback, not silent failure.
What are the steps in From Conversation to Capability?
1) Same person, multiple aliases; 2) Split company and system names; 3) Anonymous commitments; 4) Silent decision reversals; 5) Unverifiable claims.
Where do the claims in From Conversation to Capability come from?
The playbook cites Internal workshop source material.
WS·10 · Sources

All Sources in This Playbook

00 / 18