Gap Detection
All plansA PRD that reads fine to a person can still be expensive to scope: it omits a success metric, never draws an out-of-scope boundary, leaves a non-functional target unstated, or names an integration once and never bounds it. Those omissions are exactly where a scope estimate goes wrong. Gap detection surfaces them on the PRD before they become estimation risk.
Gaps are advice, never a gate
The core principle: detection is a byproduct of assessing a PRD, not a gate in front of it. It never blocks import, save, or approval. You can leave every gap open and approve the PRD anyway.
Resolving a gap annotates — it records a decision. It does not rewrite your text. The PRD stays your source of truth; the gap system never fights it. Each gap can be:
- Resolved — you addressed it (a recorded decision).
- Ignored — acknowledged, proceeding anyway.
- Reopened — brought back to the open list.
The value is the recorded pattern, surfaced when it matters, not a forced correction.
What gets detected
Detection runs a set of deterministic rules over the PRD's text. It flags:
| Gap | What it catches |
|---|---|
| Missing success metric | No measurable goal to scope against |
| Missing out-of-scope boundary | No non-goals — unbounded scope is the most expensive thing to guess at |
| Unspecified non-functional | Performance, scalability, security, availability, or accessibility never stated |
| Dangling integration reference | A named system or integration mentioned once with nothing bounding it |
| Expensive sentence | An unresolved cost-hiding phrase — an unbounded verb ("supports", "integrates"), a vague quality ("seamless", "scalable"), or an open quantifier — that nothing in the sentence pins down |
| Recurring question | A question asked repeatedly about the scope generated from this PRD (see below) |
Deterministic by design
Phase 1 detection is pure and rule-based — no AI. Every gap traces to a named rule, not a model, so results are explainable and repeatable. Because it is deterministic, running detection does not consume your AI generation quota.
Recurring questions become gaps
When people repeatedly ask the same question about a scope generated from a PRD — the recurrence threshold is at least two asks by at least two distinct people — that question is surfaced as a recurring_question gap on the originating PRD. The signal lands in the same gap panel as everything else, so a documentation gap shows up where you are already working rather than in a separate analytics tab.
These gaps follow the same lifecycle as any other: rank, resolve, or ignore. A resolve or ignore survives — the question re-appearing does not reset your decision. See Q&A for how questions are asked and tracked.
Ranking
Gaps are presented as a ranked list, not a score. They are ordered by the cost of guessing wrong first, then severity, and the open list is capped — a list of thirty gets ignored wholesale, so you see the ones that matter. Re-running detection reconciles against what is already there: new findings appear, still-open ones refresh, and your resolved or ignored decisions are preserved.
Anchoring
Span-level gaps are anchored to a snippet of the PRD text, not to a line number. A gap survives unrelated edits elsewhere in the document rather than orphaning or jumping to the wrong place. Document-level gaps (like a whole missing section) are tracked against the document as a whole.
Who can do what
| Action | Who |
|---|---|
| Run detection | Editor and above |
| View gaps | Viewer and above |
| Resolve / ignore / reopen | Editor and above |
Access is scoped to your organization; org admins can act across PRDs. See roles & permissions.
Where it lives
Gap detection surfaces in the gap panel on the PRD view. Detection is on demand — run it when you want a fresh read — and the results persist with the PRD.
Part of the PRD lifecycle
Gap detection is the first step of the PRD lifecycle: assess for gaps, summarize, then move through approval.