KlyrStart freeThe evidence-PM glossary.
The concepts behind Klyr, defined plainly. Cited synthesis is table stakes; these are the terms for everything after it.
Citation floor
The minimum number of verified source quotes a theme needs to survive. In Klyr the floor is two: any theme backed by fewer than two citations auto-drops before it reaches you. The point is to kill confident-sounding patterns that rest on a single voice, where one talkative customer can masquerade as a trend. The floor runs at synthesis time, so what lands in front of you is already filtered. You can raise it per workspace if you want a stricter bar. See the proof for how citations are checked against transcripts.
Feature Bet
A ranked, evidence-backed proposal to build something specific. A Feature Bet pulls together the themes that justify it, an impact score, a confidence level, and the counter-evidence against it, so the wager is explicit rather than implied. It sits between raw synthesis and a Build Pack: themes tell you what people said, the Feature Bet says what you should do about it and why it might be wrong. Ranking is comparative, so you see which bet earns the next sprint instead of debating in the abstract. Promote a bet to generate its Build Pack.
Build Pack
The buildable artifact Klyr generates from a Feature Bet: a PRD, explicit acceptance criteria, and a coding-agent prompt ready for Cursor or Claude Code. Every requirement traces back to the cited evidence that motivated it, so the spec carries its reasoning instead of stranding it in a doc no one rereads. The agent prompt is the handoff: it ships your evidence into the tool that writes the code. A Build Pack is meant to be the last translation step before implementation, not another planning layer. See the docs for the full structure.
Product Memory
The persistent store that connects evidence to outcomes over time. Every transcript, theme, Feature Bet, Build Pack, and shipped result stays linked, so a claim made today can be traced to the interview that seeded it months ago. This is the part your coding agent throws away after each session. Product Memory is why a bet you lost last quarter can warn you off repeating it, and why new evidence can resurface an old theme. It is the substrate that makes outcome learning possible rather than a one-off. The persistent graph is the moat, not the synthesis.
Evidence graph
The linked structure connecting source quotes, themes, bets, specs, and outcomes. Instead of storing notes as flat documents, Klyr stores the relationships: this quote supports that theme, which feeds this Feature Bet, which became this Build Pack, which shipped and produced this result. Because the links are first-class, you can walk in either direction: from a decision back to its evidence, or from a customer quote forward to everything it influenced. The evidence graph is what makes claims auditable and what lets Product Memory answer questions a pile of transcripts cannot. See the proof.
Spec Quality Gate
An automated check that a PRD or Build Pack is fit to hand off before it reaches an engineer or coding agent. The gate looks for the failures that quietly waste a sprint: acceptance criteria that are vague or untestable, requirements with no cited evidence behind them, and ambiguity a coding agent will resolve by guessing. It scores the spec and flags what to fix rather than blocking blindly. The aim is to catch a bad spec at authoring time, when a sentence fixes it, instead of in code review after the agent built the wrong thing.
Decision Room
A structured review surface where a proposed decision is examined against its evidence before it is committed. Reviewers see the Feature Bet, the supporting themes, the counter-evidence, and the open questions in one place, then approve, reject, or send it back. The Decision Room exists so decisions are made on the record and stay connected to the evidence graph, which means a later why-did-we-build-this question has a real answer. It turns the usual untraceable Slack consensus into a logged decision that Product Memory can reference long after the room closes.
Opportunity plan
A view that maps validated themes to the opportunities they imply and the bets that would address them, before anything is committed to a roadmap. Where a single Feature Bet answers should we build this one thing, the opportunity plan steps back to show the landscape: which clusters of evidence point to real problems, how they relate, and where the highest-leverage work sits. It keeps prioritization anchored to cited demand rather than loudest-stakeholder energy. Think of it as the bridge between synthesis and sequencing: evidence on one side, an ordered set of bets on the other.
Synthesis
The step that turns raw interviews and notes into structured, cited themes. Klyr reads your uploaded transcripts, groups what customers actually said into patterns, and attaches the verified source quotes that support each one. Cited synthesis is now table stakes: NotebookLM and coding agents do a version of it for free. Klyr's view is that synthesis is the entry point, not the product. The value is what happens after: the citation floor that prunes weak themes, and the loop that carries a theme through to a shipped outcome and back into memory.
Theme
A recurring pattern Klyr extracts from your evidence, with every claim it makes linked to verified source quotes. A theme is not a summary you have to trust; it is a claim plus the citations that back it, which you can open and read in context. Themes that fall below the citation floor of two sources auto-drop, so a theme that reaches you has cleared a minimum bar of corroboration. Themes are the raw material for Feature Bets and the opportunity plan, and they remain linked in the evidence graph so you can trace any later decision back to them.
Counter-evidence
The quotes and signals that argue against a theme or Feature Bet, surfaced deliberately rather than buried. Most synthesis tools only show you confirming evidence, which quietly inflates confidence. Klyr attaches the dissent: customers who wanted the opposite, who hit no such problem, or who would churn on the proposed change. Counter-evidence feeds directly into a bet's confidence score and gives the Decision Room something to argue with. The goal is to make disagreement visible at decision time, so you are betting with eyes open instead of discovering the objection after you have shipped.
Outcome learning
The closing step of the loop, where what actually happened after you shipped is recorded back against the bet that drove it. Did the feature move the metric, get adopted, or fall flat? That result links to the Build Pack, the Feature Bet, and the original evidence in the graph. Outcome learning is what turns Klyr from a synthesis tool into a memory: next quarter's prioritization can see which kinds of bets paid off and which patterns of evidence misled you. Without it, every cycle starts from zero. With it, the system gets calibrated to your product over time.
Agent context
The structured, cited slice of Product Memory that Klyr hands to a coding agent so it builds with your evidence instead of its guesses. Delivered in the Build Pack's agent prompt and through the agent-context API, it carries the requirements, acceptance criteria, and the source quotes behind them. Your coding agent forgets everything between sessions; agent context is how Klyr feeds back the memory it loses, on demand. The result is an agent that can answer why a requirement exists because the evidence travels with the spec, not a generic implementation detached from what customers said.
Retrieval-then-generation
The discipline of pulling the actual source material first, then writing only from it, instead of generating fluent text and hoping it is grounded. Klyr retrieves the relevant transcript passages, then produces themes and claims tied to those exact quotes, which is what makes every citation verifiable against the original. The ordering matters: generation-first systems sound confident and invent support after the fact. Retrieval-first keeps the claim and its evidence bound together, so a citation either points at a real quote or it does not exist. See how the checks work in the proof.
Transcript health
A read on whether an uploaded interview or note is good enough to synthesize from. Klyr flags problems that quietly corrupt downstream themes: garbled speech-to-text, missing speaker labels, truncated recordings, or a transcript so thin it cannot support real patterns. Poor inputs produce confident-sounding but hollow synthesis, so transcript health is a gate at the front door rather than a cleanup afterward. It tells you which sources to re-upload or fix before you trust the themes built on them, and it keeps the citation floor meaningful by ensuring the citations point at usable text.
Impact score
A comparative estimate of how much a Feature Bet matters, used to rank bets against each other. It draws on the weight of evidence behind the bet: how many distinct customers raised it, how acute the pain reads in their own words, and how it stacks up against competing opportunities. Impact is deliberately separated from confidence: a bet can have high impact and low confidence, meaning it would matter a lot but the evidence is still thin. Keeping the two apart stops a single blended number from hiding the real question, which is whether to invest now or gather more proof.
Confidence
How much the evidence actually supports a theme or Feature Bet, kept separate from how much it would matter. Confidence rises with corroboration: more independent sources, cleaner transcript health, and stronger direct quotes. It falls when counter-evidence is present or when the support leans on one loud voice. Pairing confidence with impact gives you the honest two-axis read: build the high-impact, high-confidence bets, and go gather more interviews on the high-impact, low-confidence ones rather than guessing. Confidence is computed from the evidence graph, so you can open it and see exactly which citations moved it.