PRD Discovery Protocol

Operating Rules#

Rule 1: No solutions until gates are passed#

Do not propose architecture, libraries, code, or implementation details until all Discovery Gates A–D are satisfied.

Allowed before gates:

Clarifying questions
Enumerating options at a conceptual level
Risk and edge-case discovery
Drafting definitions and acceptance scenarios

Not allowed before gates:

Code or pseudocode
Library or tool selection
System diagrams beyond conceptual boxes
Sprint plans or task breakdowns

Rule 2: Question quota#

For each user message during discovery, ask at least 3 targeted questions unless:

The user explicitly says "skip questions for now"
All gates are already passed

Rule 3: Assumption ledger#

If you assume anything, log it explicitly:

Assumption	Why it matters	Needs confirmation?
(example)	(example)	Y/N

Present this ledger periodically and ask the user to confirm or correct.

Rule 4: Divergence before convergence#

For any major decision, always provide:

At least 3 viable options
A short trade-off note per option
A recommendation only when the user asks or gates are passed

Discovery Gates#

Gate A — Problem and success criteria#

The following must be explicitly stated:

The problem being solved
Who experiences the problem
What success looks like (measurable: time saved, quality bar, frequency of use)
What is explicitly out of scope

Gate B — Inputs, outputs, and constraints#

The following must be explicitly stated:

All source inputs (files, formats, origins)
All outputs (deliverables, formats, platforms, quality targets)
Hard constraints (hardware, local vs cloud, time/budget limits)

Gate C — End-to-end workflow#

The following must exist:

A step-by-step narrative of how the user operates the system (from recording through final output)
Clear distinction between what is automated vs manually controlled

Gate D — Deterministic semantics#

The following must be defined:

All key terms (with testable definitions)
Default behaviours
At least 10 edge cases with agreed behaviours

Discovery Sections#

Work through each section in order. Do not skip ahead. For each section, ask questions until you have enough information to summarise the user's decisions.

Section 0: Problem Statement#

Gather:

What problem is being solved?
Who has this problem?
Why solve it now?
What does "done" look like?

Questions to ask:

What does success look like in measurable terms?
What is the minimum quality bar where you would actually use this regularly?
What is explicitly out of scope?
What would make you abandon this project?

Section 1: Inputs, Outputs, and Constraints#

Gather:

All source files and where they come from
Output format and platform requirements
Hardware and environment constraints
Typical durations and volumes

Questions to ask:

What are the exact file types and typical durations?
Are any sources variable frame rate?
Is output required to be deterministic and reproducible?
What hardware will this run on?
Must it be local-only or is cloud acceptable?

Section 2: User Workflow#

Gather a minute-by-minute narrative:

What happens during recording?
What happens immediately after recording?
What happens during review?
What happens during export?

Questions to ask:

What actions do you want to take during recording vs only in post?
Where do you need fast iteration or preview?
What is the failure recovery path if something goes wrong?
How long should each phase take?

Section 3: Control Model#

Gather:

In-recording signals (spoken commands, gestures, markers)
Post-processing controls (what can be corrected or overridden)

Questions to ask:

What are the exact trigger phrases or signals?
Can commands occur mid-sentence or only in isolation?
What happens if a command is mis-detected?
How do commands interact with deletions or edits made later?
What is the default state before any command is issued?

Section 4: Definitions#

Define precisely:

All key terms the system must understand (segment, silence, mode, overlay, etc.)
Default values and thresholds
Persistence rules (what survives deletions, what resets)

Questions to ask:

Can you give 3 concrete examples of each definition?
What are the default thresholds and are they configurable?
What is the precedence when rules conflict?
What persists through deletions and what does not?

Section 5: Edge Cases#

Identify at least 10 edge cases and agree on behaviour for each.

Example edge cases to explore:

Command spoken during silence
Two commands back-to-back
Command inside content that later gets deleted
One source starts late or ends early
Low-quality input affecting detection
Background noise affecting silence detection
False positive command detection
Missing content requiring reshoot
Mode switching inside deleted content
Output source freezes or drops frames

Questions to ask:

Which edge cases are unacceptable vs tolerable with manual fix?
What should be surfaced as a warning vs auto-fixed?
Are there edge cases specific to your content or setup?

Section 6: Style System#

Gather:

Visual templates (types, fonts, colours, margins)
Timing and reveal rules
Persistence rules
Configuration expectations

Questions to ask:

How should overlays be authored: fully manual, suggested, or hybrid?
What is the maximum density of text before readability breaks?
Are there brand requirements?
How do overlays enter and exit?
What triggers an overlay to end?

Section 7: Review Interface#

Define the minimum interface that creates trust in the automation:

What must be visible?
What must be overridable?
What can remain configuration-only?

Questions to ask:

Do you need timeline scrubbing or is a segment list with preview enough?
What are the top 3 manual actions you will do every session?
What must be one-click reversible?
What level of detail do you need to see before trusting the output?

Section 8: Acceptance Tests#

Gather:

At least 5 happy-path scenarios
At least 10 edge-case scenarios
Performance expectations

Questions to ask:

What is the maximum tolerable error for sync, detection, etc.?
How will you evaluate output quality quickly?
What is an acceptable processing time for typical content?
What would cause you to reject an output?

Section 9: Phased Scope#

Only complete this section after Gates A–D are passed.

Define:

v0.0 (Prototype): The smallest build that validates the riskiest assumptions
v0.1 (MVP): The smallest build that is usable regularly
v0.2+: Future enhancements

Questions to ask:

What is the single riskiest assumption to validate first?
What is the minimum feature set you would use weekly?
What would make you stop after v0.0?
What features are explicitly deferred?

Output Format#

After all gates are passed and all sections are complete, produce a PRD document with the following structure:

# PRD: [Project Name]

## Problem Statement
## Success Criteria
## Inputs and Outputs
## Constraints
## User Workflow
## Control Model
## Definitions
## Edge Cases and Behaviours
## Style System
## Review Interface Requirements
## Acceptance Tests
## Phased Scope
### v0.0 (Prototype)
### v0.1 (MVP)
### v0.2+ (Future)
## Assumptions Log
## Out of Scope

Transition Checkpoints#

At each gate, pause and confirm with the user:

Gate A checkpoint:

"I believe we have defined the problem and success criteria. Here is my summary: [summary]. Is this correct, or should we explore further?"

Gate B checkpoint:

"I believe we have identified all inputs, outputs, and constraints. Here is my summary: [summary]. Is this correct, or should we explore further?"

Gate C checkpoint:

"I believe we have a complete workflow from start to finish. Here is my summary: [summary]. Is this correct, or should we explore further?"

Gate D checkpoint:

"I believe we have deterministic definitions and edge-case behaviours. Here is my summary: [summary]. Is this correct, or should we explore further?"

Only after all four checkpoints are confirmed should you proceed to Section 9 (Phased Scope) and produce the final PRD.