Claim Extraction: The Missing Step Between Expert Calls and Investment Decisions

Every expert call generates a transcript. Most transcripts generate a summary. Most summaries generate a memo. And somewhere between the expert's mouth and the investment committee's eyes, the original intelligence — precise, attributable, falsifiable — gets compressed into generalities that nobody can act on, audit, or challenge.

Claim extraction is the corrective. It is the act of pulling every discrete, falsifiable, attributable statement from an expert call transcript before any synthesis begins. Not a summary. Not a theme. A claim: a specific, bounded assertion about the world that can be attributed to a source, assigned a confidence level, and tested against what other sources say. When you extract claims systematically, you convert unstructured text into a queryable database of intelligence — one that can be cross-referenced, updated, and presented to decision-makers with a clear chain of custody.

What Is a Claim?

A claim, in the context of primary research, is any discrete statement about the world that satisfies three conditions: it can be attributed to a specific source, it can be assigned a confidence level, and it can be tested against other sources. These three conditions are not bureaucratic requirements — they are what separates intelligence from noise.

Consider the difference between these two statements from the same expert call. First: "Channel checks suggest the distributor lost two major accounts in Q3." This is a claim. It is specific (Q3, distributor, account loss), testable (you can verify with channel checks or other experts), falsifiable (another expert could contradict it), and attributable. Second: "Things are generally improving." This is not a claim. There is no attribution possible beyond the speaker's general mood, no falsifiable content, and no testable element. It cannot be entered into a claim register or used in synthesis.

Claims fall into four categories. Factual claims assert something about observed or verifiable reality: market share figures, pricing data, customer counts, headcount changes. Opinion claims reflect the expert's judgment or interpretation: assessments of management quality, competitive positioning, or strategic direction. Predictive claims make assertions about future states: revenue expectations, regulatory outcomes, technology timelines. Structural claims describe how systems work: distribution dynamics, procurement processes, regulatory frameworks. Each type requires different handling at the confidence-tagging stage, but all four are valid claim types worth extracting.

The evaporation that EXP-009 describes is not carelessness — it is what happens when extraction is left implicit. Analysts listen for the moments that confirm or challenge their hypothesis and note those. Everything else — the structural observations, the offhand competitive comments, the hedged predictions — disappears into the transcript, which nobody reads twice.

The Extraction Protocol: A Step-by-Step Guide

Claim extraction is a skill. Like financial modeling or interview technique, it improves with practice and deteriorates without a defined process. The following five-step protocol gives research teams a repeatable framework that can be applied to any expert call transcript, regardless of sector or investment style.

Step 1: Transcript Segmentation

Before identifying any claims, divide the transcript into question-and-answer pairs — not paragraphs, not topics. Each question-answer unit becomes the atomic unit of analysis. This matters because experts often respond to one question while touching on two or three distinct claim areas; segmenting by question-answer forces you to treat each unit as a complete thought before moving on.

Step 2: Claim Identification Pass

Work through each question-answer segment and highlight every falsifiable statement — not just the memorable quotes, and not just the statements that support your hypothesis. The identification pass is not an interpretation exercise; it is a mechanical scan for claims. Apply the three-condition test: is it attributable, confidence-assignable, and testable? If yes, it is a claim. If no, move on.

Step 3: Confidence Tagging

Tag each claim with one of three confidence levels. High: the expert stated the claim directly, with no hedging language, and it falls within their demonstrated domain of expertise. Medium: the claim was implied, stated with hedging language ("I think," "probably," "as far as I know"), or falls partially outside the expert's direct experience. Low: the claim is speculative, based on second-hand information, or explicitly flagged by the expert as uncertain. These tags are not judgments about the expert's credibility — they are metadata about the nature of the statement.

Step 4: Contradiction Flagging

After confidence tagging, compare each new claim against the existing claim register from prior calls in the same research program. Flag any direct contradictions — cases where a new claim and an existing claim make mutually exclusive assertions about the same subject. Contradictions are not problems to resolve at the extraction stage; they are signals to investigate. They tell you which questions to prioritize in subsequent calls.

Step 5: Source Normalization

Replace the expert's name with their EXP-XXX identifier and a standardized role descriptor — "Former VP of Operations, Industrial Distribution" rather than the individual's name or employer. This normalization serves two purposes: it protects expert confidentiality in documents that may circulate beyond the research team, and it forces the synthesis process to evaluate claims on their evidentiary merit rather than the source's perceived authority.

Building the Claim Register

The claim register is where extracted claims live. It is a structured spreadsheet or database — the format matters less than the consistency — with a defined set of fields for every claim entered. The core columns are: Claim ID (a sequential identifier), Expert ID (the EXP-XXX code), Expert Descriptor (the normalized role description), Claim Text (the verbatim or near-verbatim claim statement), Confidence Level (High / Medium / Low), Date (of the call), Call Number (within the research program), and Status.

The Status field deserves particular attention. A claim can be Active (current best understanding), Superseded (replaced by a more recent or higher-confidence claim on the same subject), or Contradicted (directly challenged by a claim of comparable or higher confidence from another source). Managing status is what keeps the register useful as a program progresses — without it, a 12-call program generates a register with 400 claims and no way to know which ones still hold.

A sample row illustrates how the register works in practice. Claim ID: CLM-047. Expert ID: EXP-012. Expert Descriptor: Former Head of Procurement, B2B Technology Distribution. Claim Text: "Pricing pressure from the largest aggregators began in Q2 and accelerated through Q3; the margin compression was roughly 200 basis points across the mid-market tier." Confidence: High. Date: 2025-09-14. Call Number: 4. Status: Active. That single row contains more usable intelligence than a paragraph of summary prose — and it can be queried, filtered, and compared in seconds.

The register delivers three compounding benefits as a research program matures. First, it enables genuine cross-call synthesis: when you have 60 claims from 8 calls, all tagged and normalized, you can identify convergence and divergence across source types in an afternoon rather than a week. Second, it surfaces contradictions the moment they arise — the flagging discipline in Step 4 means you enter the ninth call already knowing which claims from the prior eight remain contested. Third, it creates an audit trail. When an investment committee asks "why did you believe the margin thesis," you can answer with a claim ID, an expert descriptor, a confidence level, and a date — not a vague recollection of a call three months ago.

Common Extraction Failures

Even teams that adopt a formal extraction process encounter predictable failure modes. Understanding them in advance shortens the learning curve considerably.

Failure 1: Extracting summaries instead of claims. "Expert was positive on the category" is a summary. It contains no extractable claim — no specific assertion, no testable content, no confidence-assignable element. The correct extraction from the same call segment might be: "Expert believes category volume will grow 12–15% over the next 18 months, driven by regulatory tailwinds and two major customer re-contracting cycles." That is a claim. The summary is a label for what you felt after listening.

Failure 2: Conflating claim and evidence. "Channel checks show pricing pressure, which means the category leader is losing share" bundles two distinct claims into one entry. The channel check finding is Claim A. The share loss inference is Claim B. They may have different confidence levels, different sources, and different downstream implications. Keeping them merged makes it impossible to challenge either one cleanly.

Failure 3: Ignoring negative space. What the expert was asked about but declined to answer is itself a data point. An expert who spent 20 years in a sector and gave a non-answer when asked about a specific competitor's operational efficiency is telling you something — even if the transcript records only silence or deflection. Negative space claims are difficult to formalize but worth noting in a register comment field.

Failure 4: Over-extracting. Attempting to capture every statement from a 60-minute call produces a 200-line register entry that nobody will read, reference, or maintain. The extraction protocol should be filtered by relevance to the investment hypothesis. If the program is evaluating a specific competitive dynamic, claims about regulatory history in an adjacent sector may not belong in the active register. Discipline at the identification pass stage is what keeps the register actionable.

Integrating Claim Extraction Into Your Workflow

The most common implementation question is when to extract. The answer is within 24 hours of call completion, before the next call in the program begins. Memory fades fast. The nuances of tone, the moments of hesitation, the contextual details that determine whether a claim is High or Medium confidence — these are available to the analyst who was on the call for a short window after it ends. Waiting until the program is complete before extracting means extracting from transcripts alone, which is a significantly inferior process.

The second implementation question is who should extract. The analyst who took the call should do the extraction — not a junior team member who was not present, and not an AI system working from the transcript alone. Extraction requires judgment calls that depend on contextual information not captured in the text: the expert's tone when making a specific claim, whether a statement was volunteered or prompted, how a response related to what was asked. These are not transcribable, but they are essential inputs to confidence tagging.

The time investment is real but bounded. A trained analyst working a familiar sector can complete the extraction from a 45-minute call in 30–45 minutes. The first few extractions in a new sector or on a new research program take longer — 90–120 minutes — while the analyst develops familiarity with the claim taxonomy and the hypothesis being tested. The ROI becomes clear at the synthesis stage: a 12-call program with systematic extraction typically yields a coherent synthesis document in one to two days. The same program without extraction typically requires a full week of re-reading transcripts to reconstruct what was actually said.

The efficiency gain described by EXP-044 is not unusual. What drives it is not the extraction itself — it is the fact that extraction forces all the interpretive work to happen at the right moment: immediately after the call, when the analyst has maximum context. Synthesis then becomes assembly rather than archaeology.

For teams running parallel research programs, the claim register also enables something not otherwise possible: cross-program learning. A claim about distribution dynamics in one sector, tagged and stored, may become relevant when a second program touches the same distribution layer in a different vertical. Without a register, that connection is invisible. With one, it surfaces in a query.

Claim extraction is not a luxury for teams with time to spare. It is the foundation of defensible primary research — the step that converts raw expert access into structured intelligence that can be interrogated, challenged, and built upon.

Without it, you have transcripts. With it, you have intelligence.