Stage 1 — Brief Parser
Project metadata, seed constraints, initial stakeholders.
The Brief Parser is the first generative stage. It reads your Brief end-to-end and emits the foundational nodes that downstream stages build on.
What it outputs
| Output type | What it is |
|---|---|
| Project metadata | Title, customer, mission summary, scope statement |
| Seed Constraints | Quantified bounds extracted from the Brief (mass, power, schedule, cost) |
| Initial Stakeholders | Named parties identified in the Brief |
These are seeds — the Stakeholder stage refines and extends them.
Why it runs first
Two reasons:
- Anchoring — downstream stages need to know "what is this project for, at the highest level". Skipping straight to requirements without that framing produces requirements disconnected from intent
- Constraint extraction — quantified constraints (mass ≤ 8kg) propagate as hard bounds through the pipeline. If a downstream trade study proposes a 12kg design, the constraint catches it
Quality signals
A well-parsed Brief shows:
- ✓ 3–8 named stakeholders (not "the user" or generic roles)
- ✓ 3–10 quantified constraints (numbers with units)
- ✓ A 2–3 sentence mission summary that you, the author, would write the same way
If you see only 1–2 stakeholders or 0–1 constraints, your Brief probably needs more specificity before the rest of the pipeline can deliver. See What is a Brief §"What makes a good Brief".
Failure modes
WARNING
The Brief Parser can hallucinate stakeholders or constraints that
aren't in your Brief. Spot-check the citations on each output node
before relying on downstream artifacts.
Common failure modes:
- Stakeholders inferred too liberally — e.g. inferring "FAA" from the word "aircraft" when your Brief doesn't actually involve FAA certification. Check the citations
- Constraints copied from boilerplate — if your Brief has a template "TRL 6 by Q3" sentence that isn't real, the parser may surface it. Edit and rerun if needed