Assemble a BRD from an Evidence Pack — Without Template-Filling Theater

Workflow area: Requirements Quality · Tier: Core · Hands-on time: ~40 minutes

The dangerous thing about AI-drafted BRDs is that they look finished. A model given a template and a project name will produce fluent sections, plausible objectives and generic assumptions — a document that passes a skim and fails its first hard question. The fix is sequencing: the BRD comes last, after elicitation synthesis (pb-01), document mining (pb-15) and coverage checks (pb-16) have produced an evidence pack of cited findings. Then AI does what it is genuinely good at — organizing evidenced content into your org's template, consistently, with traceability — and you do what the document actually exists for: deciding what problem this is, what is in and out, and what you are assuming. Those sections are the analysis; delegating them is delegating the job.

When to use — and when not to

• Use it when the evidence pack existssynthesized findings with citations, mined obligations, adjudicated conflicts. Assembly is the last step of analysis, not the first.
• Use it when the template is heavyorg templates with fifteen mandated sections are exactly where AI assembly saves hours of formatting and cross-referencing.
• Use it for consistency across a programmultiple BRDs assembled from the same prompt inherit the same structure, register and traceability style, which reviewers learn to read fast.
• Skip it with no evidence packa BRD generated from a project description is fiction with headings. Do the elicitation first; there is no shortcut through it.
• Skip AI for the judgment sectionsproblem statement, scope in/out, assumptions and open risks are hand-written. If the model drafts them, they will be generic — and generic scope statements are where disputes are born.
• Skip it for lightweight-governance workif a one-page brief serves, assembling a 30-page BRD is process worship regardless of who writes it.

The recipe

1. 1.

   Stage the inputs. Three things: your org's BRD template (headings and section guidance), the evidence pack (themed findings with citations, candidate requirements with sources, stakeholder analysis, glossary), and your hand-written core — problem statement, scope in/out, assumptions, constraints. Write that core first, before the model touches anything; it is the spine everything else hangs on.

2. 2.

   Run the assembly with a strict role. In Claude (a Project holding the evidence pack works best) prompt:

   Copy

   You are assembling a BRD from evidenced findings. You organize
   and format — you do NOT invent content.
   Template: [PASTE HEADINGS + SECTION GUIDANCE]
   Hand-written core (use VERBATIM, do not edit): problem statement,
   scope, assumptions: [PASTE]
   
   Rules:
   1. Populate each template section ONLY from the evidence pack.
      Every requirement and finding keeps its citation [source, ref].
   2. Insert my hand-written sections verbatim where the template
      calls for them.
   3. If the evidence pack has nothing for a section, write
      "[GAP — no evidence collected]" — do not fill it generically.
   4. Where evidence is thin (single source), tag the item [THIN].
   5. Number requirements BR-001... and keep one requirement per
      statement — split compounds.
   6. End with an ASSEMBLY REPORT: which sections are complete,
      which have gaps, which items are [THIN], and any evidence that
      fit nowhere in the template.
   
   Evidence pack:
   [PASTE OR REFERENCE PROJECT FILES]
   

3. 3.

   Read the assembly report before the document. Good output ends like this:

   Copy

   ASSEMBLY REPORT
   - Complete: Objectives (6 items, all cited), Process Impact,
     Stakeholders, Requirements (BR-001..BR-034)
   - [GAP — no evidence collected]: §7 Reporting Requirements,
     §9 Training Needs
   - [THIN]: BR-019 (single mention, S3 IT walkthrough 41:20),
     BR-027 (one clause, MSA §11.2)
   - Unplaced evidence: finance headcount constraint (S2, 12:44)
     — no template section fits; suggest Assumptions or Constraints
   

   The report is the point: gaps become elicitation follow-ups (feed them to pb-16's loop), thin items get corroboration or a caveat, and unplaced evidence usually means the template — or your scope — has a hole.

4. 4.

   Do the analyst pass. Read the assembled draft end to end once, aloud if you can bear it. You are hunting for three things: requirements whose citation does not actually support them, section prose that drifted beyond the evidence, and your hand-written core mangled by "helpful" edits. Then run the quality tooling: ambiguity lint (pb-19) and contradiction sweep (pb-20) before anyone else sees the draft.

5. 5.

   Baseline with the gaps visible. Circulate for review with the assembly report attached and [GAP]/[THIN] tags intact. Reviewers who can see what is missing critique the substance; reviewers shown false completeness critique the font. After sign-off, the tags come out and the document is baselined with its traceability to the evidence pack preserved.

Make it yours

• Claude Project per BRD: evidence pack, template and glossary live in the Project; assembly, lint and sweep run in one workspace with stable context, and the chat log records every regeneration.
• Rovo/Confluence for Atlassian-native programs: assemble into a Confluence page tree with requirements as structured content, and let Jira links carry the requirement-to-story traceability from day one.
• Notion AI for lighter templates: databases give you BR-numbered requirements with source and status properties; the assembly prompt fills the database, not just prose.
• Program-scale prompt library: freeze the assembly prompt and template pairing per document type (BRD, FRD, scope addendum) so every analyst's assembly behaves identically and review effort goes to content.

Quality check

• The core sections are yoursproblem statement, scope and assumptions match your hand-written text verbatim; any model edits were reverted.
• Every requirement keeps its citationBR-xxx items trace to a finding, clause or session; a requirement that appeared during assembly with no source is an invention and comes out.
• Gaps are visible, not papered overempty sections say [GAP], and each gap has a follow-up owner or a documented decision that it stays empty.
• [THIN] items are resolved or labeledsingle-source requirements gained corroboration, a caveat, or an explicit risk note before baseline.
• Compounds were splitone requirement per statement, numbered; the lint pass (pb-19) ran clean or its flags were adjudicated.
• The document survived a hostile readyou read it as the toughest reviewer would, and every section answers "says who?" with a citation.