Source: bmad_Research · bmad_research.md · updated 2026-07-23 · 🔒 secret gist

Synced verbatim from gist.github.com/bl9.

BMAD Research Capabilities — The Complete Reference

Scope & recency. BMAD-METHOD V6 (BMM module), current as of July 2026. The V6 line shipped steadily through spring 2026 (v6.3 → v6.8.x by late May). BMAD moves fast; command names and folder layout shift between point releases, so treat exact command strings as version-dependent and confirm against your install with bmad-help. Where a detail could not be verified against current published docs, it is flagged inline rather than guessed.

Table of Contents

1. At a Glance
2. Where Research Sits in the Lifecycle
3. Choosing the Right Research Type
4. The Three Research Workflows in Detail
5. The Sub-Agent Architecture
6. Research Depth and Scale-Adaptive Intelligence
7. End-to-End Walkthrough
8. Scenario Library
9. Multiple and Parallel Agents (Party Mode)
10. Where the Facts Come From (Provenance and Retrieval)
11. Cost, Context, and Running Off-IDE
12. Brownfield Research and Established Projects
13. Worked Example: A User Recommendation System
14. Markov Decision Processes and Stochastic Dependency Graphs
15. Observations and Findings
16. Practical Tips and Best Practices
17. Quick Reference
18. Glossary
19. Appendix A: Copy-Paste Research Prompts
20. Appendix B: Custom Party Definitions
21. Sources and Recency

1. At a Glance

Research in BMAD is Phase 1 (Analysis) work. It is optional — the required backbone is Planning → Solutioning → Implementation — but it exists to stop you building architecture on unvalidated assumptions. There are three distinct research workflows, all driven by the Analyst agent (persona "Mary"):

Each stands alone — run one, two, or all three. Output is a structured findings document that feeds the PRD, product brief, or architecture workflows.

Command-naming caveat. Current official docs use the short forms above. Some builds and the internal registry use a module-qualified form (bmad-bmm-market-research, etc.). Both refer to the same workflow under bmad/bmm/workflows/1-analysis/research/. If one form isn't recognized, try the other or ask bmad-help.

2. Where Research Sits in the Lifecycle

Phase 1: ANALYSIS (optional)        Phase 2: PLANNING (required)
─────────────────────────           ───────────────────────────
• brainstorming                      • PRD  (bmad-create-prd)
• RESEARCH  ← you are here           • UX design (optional)
    - market
    - domain          ─── findings feed ──▶  the PRD workflow ingests
    - technical                              briefs, PRFAQ, research
• product-brief                              findings, and brainstorm
• prfaq                                       reports as input

The key design idea is that artifacts flow forward. Research findings are not a throwaway chat — they land as documents in your output folder, and the PRD workflow explicitly accepts them as input, synthesizing whatever Phase 1 produced into structured requirements. Running research before planning compounds in value rather than being busywork.

BMM follows a waterfall-with-gates model: each phase produces documents that become context for the next, and mandatory checkpoints (gates) sit before implementation to keep requirements, architecture, and work breakdown aligned.

Default output locations (from config.yaml, set at install time):

• output_folder → _bmad-output (base for everything)
• planning_artifacts → {output_folder}/planning-artifacts
• project_knowledge → docs (long-lived research / reference docs live here)

So durable research can be steered into docs/, while cycle-specific research lands under planning-artifacts/.

3. Choosing the Right Research Type

The three types answer genuinely different questions. Conflating them is the most common mistake — "research my recommender" is really three separate investigations.

                    What are you actually unsure about?
                                  │
        ┌─────────────────────────┼─────────────────────────┐
        ▼                         ▼                          ▼
  "Does anyone want       "I don't understand        "Can we build it,
   this / who else         this problem space          and how?"
   is doing it?"           / its rules?"
        │                         │                          │
        ▼                         ▼                          ▼
  bmad-market-research     bmad-domain-research      bmad-technical-research
   (MR) — external,         (DR) — vocabulary,        (TR) — feasibility,
   competitive, sizing      constraints, SME depth    architecture, libraries

Rules of thumb:

• Internal feature for a known audience? Skip market research. Run technical, maybe a light domain pass.
• Entering an unfamiliar regulated domain? Domain research first — it changes how you'll judge everything downstream.
• Choosing between concrete technical approaches? Technical research, one focused pass per decision (see §13).
• Brownfield / existing codebase? Your real entry point is often bmad-document-project, not greenfield research (see §12).
• Not sure? Run bmad-help and describe the situation; it recommends a starting point based on what you've already produced.

4. The Three Research Workflows in Detail

Market Research (bmad-market-research, MR). Examines competitors, trends, and user sentiment; produces TAM/SAM/SOM sizing, competitive positioning, and persona/journey notes. This is the most mature of the three because it fans out to five specialized sub-agents (§5). Use it to validate that a concept is worth resources before committing.

Domain Research (bmad-domain-research, DR). Builds subject-matter expertise: the terminology practitioners use, industry-specific constraints, regulatory/ethical boundaries, and how "good" is judged in this space. Use it when entering an unfamiliar domain — getting this wrong produces a technically clean system that solves the wrong problem.

Technical Research (bmad-technical-research, TR). Evaluates feasibility, architecture options, and implementation approaches. This is the workhorse for engineering decisions. Note it is currently single-agent (§5) — its output quality depends heavily on how sharply you scope the prompt and what constraints you feed it.

All three are optional Phase-1 workflows run by the Analyst, and all three write findings documents that the PRD workflow can ingest. Run any subset; each stands alone.

Adjacent capability worth knowing — bmad-investigate. V6.8 added a forensic-investigation workflow in the implementation loop that produces evidence-graded findings for debugging and complex system analysis. It isn't one of the three Phase-1 research workflows, but for "why is production behaving like this" questions it's the research-shaped tool you actually want, and it's more grounding-disciplined than a generic research pass.

5. The Sub-Agent Architecture

The research workflow isn't a single monolithic prompt. Market research dispatches to five specialized sub-agents that can work in parallel:

The known gap

As of the V6 line, technical research has NO dedicated sub-agents (tracked upstream as a feature request). When you run technical/architecture research, the main Analyst agent executes queries sequentially by itself. Consequences:

• Slower — no parallel fan-out the way market research gets.
• Shallower specialization — no dedicated "architecture evaluator" or "library comparator."
• You carry more of the load — quality depends on how sharply you scope the prompt and how much source material / constraints you supply up front.

The single most useful thing to internalize before relying on bmad-technical-research for anything load-bearing: it is a well-structured single-agent research pass, not a multi-agent swarm. Treat it accordingly, and use Party Mode (§9) when you need genuine multi-perspective technical research.

6. Research Depth and Scale-Adaptive Intelligence

Step 5 of the workflow asks you to set research depth — a knob controlling how much source-gathering and cross-checking happens versus a fast synthesis pass. Deeper settings mean more web search, more sources, longer runs, and higher token cost.

Honest, still-open gap. The exact depth option values (e.g. quick/standard/deep vs. numeric levels) are defined in the workflow's step files, not the public docs, and could not be verified at time of writing. Don't hard-code a value from memory; when the workflow prompts, read the options it offers, or ask bmad-help what your installed version exposes.

Scale-Adaptive Intelligence is the related, documented system: bmad-help analyzes project-complexity indicators (team size, architectural complexity, compliance requirements) and recommends appropriate phase entry points and planning depth. It's how BMAD scales from a five-minute bug fix (Quick Flow) to enterprise-platform planning without forcing heavy process on small work. The three planning tracks — Quick Flow, BMad Method, Enterprise — are the concrete expression of this and each defines which workflows are required, optional, or conditional.

7. End-to-End Walkthrough

The workflow follows five interactive steps. Here's a full run for a technical decision.

Step 0 — Fresh chat. Always start research in a new chat. Stale context from an unrelated workflow degrades quality and costs more tokens.

Step 1 — Load the Analyst.

bmad-agent-analyst

(You can also invoke the workflow skill directly and let the tool route to the Analyst; loading the agent first gives you the conversational menu with the MR/DR/TR triggers.)

Step 2 — Run the workflow.

bmad-technical-research

Step 3 — Choose research type. Since you invoked the technical variant directly, this is already TR.

Step 4 — Provide context. This is where the run is won or lost (especially given no technical sub-agents). Give a tight problem statement, the constraints, and what a good answer looks like. See Appendix A for ready-to-use prompt shapes.

Step 5 — Set research depth. Pick depth by stakes. A "which library" spike can be shallow; an architecture bet that shapes service topology warrants the deepest setting.

What comes out. A structured findings document in your output folder — typically: options considered, comparison across your constraints, tradeoffs, a recommendation, and (for technical research) a sketch of a validation/PoC path. Because it's a file, it becomes an input you hand straight to bmad-create-architecture later.

What happens next automatically. The workflow ends by invoking bmad-help, which inspects project state and suggests the next step (usually product-brief or PRD). If you treat BMAD as a personal tool, ignore the suggestion and keep the findings doc.

8. Scenario Library

Scenario A — Technical research (feasibility spike)

Situation: Deciding whether pre-execution validation of Athena queries should be a hand-rolled parser, a sqlglot-based validator, or Athena's own dry-run / EXPLAIN path. Expected findings: a tradeoff matrix (safety coverage vs. cost vs. language fit), a recommended defense-in-depth layering, and which failure modes each layer catches. Observation: with no technical sub-agent, expect to iterate — feed back the option you're leaning toward and ask it to pressure-test that specifically.

Scenario B — Domain research (unfamiliar space)

Situation: Scoping a recommendation feature inside a legal-tech product; you want the domain landscape before writing a PRD. Expected findings: a subject-matter primer — vocabulary, the constraints that make the domain different (authority, jurisdiction, recency of law), and the evaluation lens you'd otherwise miss. Why domain, not technical: you're building framing, not choosing a library.

Scenario C — Market research (validation before build)

Situation: Deciding whether an internal demo is worth productizing. Expected findings: this is where the five sub-agents earn their keep — a competitor map, sizing, trend forecast, and persona notes assembled in parallel, then synthesized.

Full prompt text for each is in Appendix A.

9. Multiple and Parallel Agents (Party Mode)

There are two distinct forms of "multi-agent" in BMAD, and conflating them is the most common mistake:

1. Built-in sub-agent fan-out — automatic, inside a single workflow. Market research already does this (§5). You don't control it directly.
2. Party Mode — you convene multiple agent personas in one room to attack a question from different angles. This is the deliberate, steerable tool.

Reality check on "parallel." BMAD agents are registered as Skills, which run synchronously in the main chat thread. Even Party Mode is a simulated round-table, not OS-level concurrency — there's an open request to wrap agents as native IDE subagents for true async execution, but that isn't the default. Read "parallel" as "independent reasoning per persona," not "N agents at the same wall-clock instant." The exception is agent-team mode (Claude Code only), which stands personas up as a persistent team.

9.1 The four Party Mode modes (who does the thinking)

Invoke with bmad-party-mode; pick a mode with --mode:

Fallback chain: agent-team → subagent → session when a harness can't do the rest. On a non-Claude-Code tool, asking for agent-team quietly degrades.

The core principle: one model voicing five personas will quietly converge — they share a mind, so they tend to agree. Spawning real agents (subagent/agent-team) keeps reasoning genuinely separate, which is the entire point of a review panel or focus group. If you use multi-agent for diverse input and run it in session, you paid for theater.

9.2 ⚠️ Critical best practice: grounding vs. fabrication

A known V6.3 regression worth internalizing before trusting subagent mode on anything codebase-grounded: the default subagent spawn prompt ended with an instruction telling each persona not to use tools — "just respond with your perspective." On a codebase-grounded question, spawned agents returned zero tool calls and fabricated a meaningful fraction of their claims (roughly a third in one reported run on a ~1000-line file), because they reasoned from the orchestrator's lossy summary instead of reading the source. In the same tests, --solo/session and tool-enabled variants stayed grounded.

Rules that follow:

• For grounded work (real code, real data), verify the spawned personas can actually read the sources. If the spawn prompt forbids tools, the panel is opining on a summary, not the artifact.
• Party Mode shines for judgment questions, not fact-retrieval. "Which reranking approach fits our constraints?" is perfect. "What does line 340 do?" is exactly where the summarization gap bites.
• When in doubt, feed the source into the room yourself (paste the diff, metrics, findings docs) rather than trusting each subagent to fetch it.
• Confirm on your version — this specific prompt has been iterated upstream, so newer builds may already ground subagents.

9.3 The shipped review panels

BMAD ships two custom parties as working templates (defined but inactive until summoned — they cost nothing sitting in the pool):

Code Review Crew — five lenses that attack a change and argue about what matters: Vex (security/exploit path), Grumbal (adversary, assumes it's broken), Boundary (edge cases, nulls, races, timezones), Yui (craft, simplicity, naming), Dana (pragmatist, ranks real vs. nit). Run with subagent so each reviews before they clash.

Anti-Consensus Club — for decisions and fuzzy questions where one assistant agrees too fast or debates past the useful point: Wildcard (alternative framings), Level (claim/confidence checker), Killjoy (stops repetition and fake disagreement), Splinter (challenges easy consensus). Run with --party anti-consensus-club --mode subagent.

9.4 Working around the technical-research sub-agent gap

Because bmad-technical-research is single-agent (§5), Party Mode is the sanctioned way to get multi-perspective technical research. Two patterns:

Pattern A — Fan out, then convene. Run several separate technical-research chats, one per candidate approach (fresh chat each), producing one findings doc apiece. Then open a Party Mode room in subagent mode, feed in all the findings docs, and let a purpose-built panel reconcile them. Depth (focused single-agent research per option) and independent cross-examination, without the missing built-in sub-agents.

Pattern B — Build a custom research panel via bmad-party-mode, create a new party (writes to your overrides through bmad-customize). Ready-to-use definitions are in Appendix B.

9.5 Steering, memory, and keepsakes

• Steer actively: bring a voice in, tell one persona to "take that apart," switch rooms mid-session, or summon a named custom member.
• 2–3 active voices per round, not all at once — more turns to noise.
• Non-interactive: --non-interactive "…" runs one pass to a close and releases spawned agents (good for scripted use).
• Keepsake: on wrap-up the orchestrator offers a self-contained HTML document laid out by persona — a genuinely useful artifact to attach to a ticket.
• Memory: saved parties keep lightweight memory of past sessions (dynamics, open threads) unless you turn it off via bmad-customize. Good for a standing panel; off for one-offs you don't want coloring later runs.

10. Where the Facts Come From (Provenance and Retrieval)

The question a technical reader asks first and most docs skip: when a research workflow states a "fact," where did it come from?

BMAD ships no crawler, search index, or retrieval engine. The research workflows are orchestration — structured prompts, step files, personas, output templates. The actual source-gathering rides on the host coding agent's tool access. In Claude Code that means the model's web search, any MCP connectors you've enabled, and file/repo reads. In a locked-down harness with no web tool, the same workflow falls back to the model's parametric knowledge — cutoff-bound, potentially stale or confabulated.

Consequences:

• Research currency is bounded by your host's tools. Market/domain research is only as fresh as the web access behind it.
• Technical research in a brownfield repo sources mostly from your own code — so the host needs file-read access, and (per §9.2) spawned subagents need tool access or they hallucinate.
• Provenance hygiene is on you. Ask the workflow to cite what it actually fetched; treat uncited claims as model recall, not verified fact. Matters most for bmad-technical-research, where a confidently-wrong claim about a library costs you a bad architecture bet.
• Working memory: a memlog primitive (_bmad/scripts/memlog.py) carries state across steps within a run, so a multi-step pass doesn't drag the whole context forward.

The honest framing: BMAD makes research structured and repeatable; it does not make it grounded — grounding is a property of the tools you point it at.

11. Cost, Context, and Running Off-IDE

Token cost is real. Independent testing has put a full planning cycle in the rough ballpark of ~$200 in tokens (an order-of-magnitude signal, not an official figure). Two knobs multiply it:

• Depth (§6) — deeper = more sources, more cross-checking, more tokens.
• Party Mode spawning (§9.1) — subagent/agent-team spin up a separate agent per persona per round, so an N-persona panel is roughly N× the per-round cost of session. Great for independence, expensive by design.

Context management keeps this affordable. BMAD's step-file architecture loads workflow steps just-in-time rather than holding the whole workflow in context, and each SKILL.md uses YAML frontmatter to persist runtime state across turns. The fresh-chat-per-workflow discipline (§7, §9.5) isn't just a quality rule — it's a cost rule; stale accumulated context is both worse and pricier. memlog carries the few things worth remembering so a fresh chat isn't a cold start.

Web Bundles (v1.0, May 2026) are the token-conscious escape hatch. BMAD can package planning/research skills — market research, brainstorming, product briefs, PRFAQ, PRD, UX specs — as Google Gemini Gems and ChatGPT Custom GPTs. Run the research-and-planning-heavy front of the process on a flat-rate web subscription instead of metered IDE tokens, then bring artifacts back into the IDE for solutioning and implementation. For token-conscious use this is the single biggest lever: offload the exploratory, high-token research phase to a fixed-cost surface.

Customization. Research workflows are customizable like every BMad skill via bmad-customize (writing to your overrides). Pin a default depth, set house rules the workflow holds for the whole run, add persistent facts so you don't re-explain your stack every time. The clean, version-safe way to shape behavior without forking the workflow.

12. Brownfield Research and Established Projects

Most scenarios frame research as pre-build validation, but in an existing codebase your real research entry points differ.

bmad-document-project (DP, Analyst) reverse-documents an existing codebase into reference docs. Critically, its output can substitute for Phase 1–2 artifacts, letting a brownfield project enter at Phase 3 (Solutioning) with generated context. For a live system, this is often the actual first move — not greenfield market/domain research.

bmad-generate-project-context (GPC, Analyst) produces project-context.md, which acts as the "constitution" for your project: technical preferences and implementation rules every agent must follow. You can hand-write it at the project root or in _bmad-output/, or auto-generate it by scanning the codebase. For research specifically, a good project-context.md means technical-research passes start already knowing your stack, conventions, and constraints — less re-explaining, sharper findings.

Practical brownfield stance:

• Market/domain research is frequently skippable for internal brownfield work — don't run the full Phase-1 suite out of completeness reflex.
• The useful pair is usually document-project (understand the system) + technical-research (decide one thing), optionally with bmad-investigate (§4) when the question is "why is it behaving like this."
• Feed project-context.md into research runs so findings respect your actual constraints from the first token.

13. Worked Example: A User Recommendation System

This section shows how BMAD research actually works on a real build. The feature: a user recommendation system that suggests content based on a user's view history. It's the ideal case study because it spans all three things research handles — algorithm choice, failure modes, and infrastructure — and because it exposes the hard boundary between what BMAD researches and what your data has to decide.

Framing first (the whole point). A recommender is ~90% technical research, ~10% domain, 0% market (internal feature, not a product to position). And per §10, BMAD will structure and survey the problem — it will not benchmark EMA-vs-two-tower on your click logs. Everything below is decision-support; the empirical answers come from eval, not the research workflow (see §13.7).

13.1 Decompose the feature into research passes

Don't run one giant "research a recommender" prompt — it produces a shallow essay. Split into focused technical-research passes, each a real decision:

Then reconcile the technical passes in a Party Mode panel (§13.5) — the fan-out-then-convene pattern from §9.4, and the way to work around the missing built-in technical sub-agents.

13.2 Pass A — scoring & representation

Real question: how do you turn "what a user viewed" into "what to show next," and keep it fresh without recomputing everything?

Options to compare and the substance you're validating:

• EMA user-preference vector — maintain u ← α·e_item + (1−α)·u per interaction (or time-decayed weight = exp(−λ·Δt)). α (or a half-life) is the recency knob. Cheap, updates online in O(1), naturally forgets stale interests. Known weakness: interest blending — a user who reads both tax law and IP law collapses into a muddy centroid that recommends neither well. That single fact is usually what pushes toward the next option.
• Recent-k / multi-vector — keep the last k interaction embeddings and retrieve by max-similarity (late-interaction style) instead of a single centroid; preserves distinct interests at higher retrieval cost. (Where ColBERT / MUVERA / late-interaction thinking connects.)
• Two-tower learned model — user tower + item tower trained on engagement; best relevance ceiling but adds training infrastructure and a cold-start dependency on engagement data.
• Hybrid — content-based ANN candidate generation (works cold) + collaborative signal in rerank once engagement exists. The usual pragmatic landing spot.

Retrieval mechanics: content/item embeddings in OpenSearch k-NN (HNSW); the user vector (EMA aggregate or multi-vector) drives an ANN query for the candidate set. Dimensionality and quantization (PQ / IVF-PQ) are the recall-vs-cost knobs.

Observation: research lays out this tradeoff space cleanly. It cannot tell you the right α or whether EMA is "good enough" for your users — that's §13.7.

13.3 Pass B — the failure modes (where recommenders actually break)

Duplicates are the headline, but they're one of a family. A good findings doc gives a layered defense and says where each layer sits and what it misses:

The layering insight research should surface: these are ordered stages (candidate-gen → seen-filter → dedup/cluster-collapse → MMR/diversity → impression-discount), and each layer only catches its own class — MMR won't catch exact dupes, seen-set won't catch near-dupes. That ordering is the finding. (The exploration slot in the last row is a one-step special case of a fuller sequential formulation — see §14 for modeling the recommender as a Markov Decision Process.)

13.4 Pass C — AWS architecture & deployment

Real question: how does all of the above run in production within latency, cost, and DR constraints? What good findings look like:

• Two paths. A batch/offline path (embed the corpus, backfill the vector index, precompute where possible) and an online path (per-request retrieve → filter → rerank). Keeping heavy work off the request path is the p95 story.
• State placement. EMA user vectors in DynamoDB (fast point read on the request, O(1) write on interaction, TTL to forget dormant users); content vectors in OpenSearch k-NN; a recommendation Lambda orchestrates retrieve → seen-filter → dedup → MMR rerank → Content API hydrate.
• Embedding generation. Batch backfill (SageMaker Batch Transform / Bedrock) for the corpus; near-real-time for newly ingested content via a Lambda on the ingest event.
• Latency budget is spent mostly in ANN retrieval + rerank; MMR over a bounded candidate set is cheap, a cross-encoder rerank is where you'd blow the budget (ties to Scenario A / reranking decisions).
• Edge & DR. CloudFront + ALB in front; origin-layer DR determines what happens to the rec call when a region degrades — fail to a popularity/editorial fallback rather than erroring.
• Top cost levers. Vector quantization (PQ) vs. recall, embedding-recompute frequency, and DynamoDB read/write capacity mode.

13.5 Reconcile the passes in a panel

Use §9. Open a Party Mode room in subagent mode and feed in the three findings docs — because the passes interact (a multi-vector user model changes ANN cost, which changes the AWS budget, which changes whether a cross-encoder rerank is affordable):

bmad-party-mode --mode subagent
# panel: relevance-engineer, latency-hawk, ops-SRE, cost-owner, eval-skeptic
# input: pass-A-scoring.md, pass-B-failure-modes.md, pass-C-aws.md

The eval-skeptic persona matters most here — its job is to keep asking "how will we know this is better?", forcing the design toward §13.7. (Heed §9.2: make sure the panel can actually read the three docs.)

13.6 What chains downstream

The three findings docs + the panel keepsake feed:

• bmad-create-prd — synthesizes them into requirements (it ingests research findings as input, §2).
• bmad-create-architecture — Pass C becomes the architecture backbone; Passes A/B become the algorithm and quality sections.
• The eval plan — where the real work starts.

13.7 The honest boundary — what the research cannot tell you

This is the "how it actually works here" punchline. BMAD technical research produces a decision-support package: options, tradeoffs, a layered design, cited sources (only if the host has web access — §10), and a proposed evaluation plan.

It does not, and cannot, tell you:

• the right α / half-life for your EMA,
• the right cosine threshold for near-dup collapse or λ for MMR,
• whether EMA beats two-tower on your users,
• your actual p95 under load.

Those are empirical and belong to eval-driven development, not research — adversarial multi-evaluator loops, offline replay against view history, and online A/B. The division of labor:

Research designs the experiment and narrows the option space. Your data runs the experiment and picks the winner.

A recommender is precisely where teams mistake a confident research doc for an answer and skip the eval. The research is real and valuable — it stops you building the wrong thing — but the tuning constants that decide whether the feature is good come from measurement, and the research's job ends at handing you a sound experiment to run.

14. Markov Decision Processes and Stochastic Dependency Graphs

14.1 Does BMAD support this natively? No — and it's worth being precise about why

BMAD's dependency model is a deterministic directed graph with conditional branches and mandatory gates — the graph TD planning flow (idea → optional research → brief → PRD → architecture → gates → implementation), soft preceded-by/followed-by sequencing in module-help.csv, and scale-adaptive heuristic routing to a track (Quick Flow / BMad Method / Enterprise). There is:

• no transition probability between milestones (a gate is pass/fail by review, not P(pass | state, action)),
• no reward/value function or policy being optimized,
• no MDP/POMDP solver, no stochastic scheduler, no Bayesian dependency graph.

"Scale-adaptive intelligence" and bmad-investigate's "evidence-graded findings" sound probabilistic but are heuristic/qualitative grading, not a Markov model. So if the question is "can I hand BMAD a stochastic milestone graph and have it solve for an optimal policy" — no, that's outside its design.

That said, MDPs and stochastic dependency graphs are relevant to your work in two distinct, genuinely useful ways. Neither is a built-in feature; one is a research subject BMAD is well-suited to investigate, the other is an overlay you build on top of BMAD's deterministic graph.

14.2 The concept — what a Markov Decision Process actually is

An MDP is the standard mathematical model for sequential decision-making under uncertainty: an agent repeatedly observes a state, picks an action, receives a reward, and lands (probabilistically) in a new state — and it wants to choose actions that maximize reward over the long run, not just right now.

The Markov property. The defining assumption: the future depends only on the current state, not the whole history — P(s_{t+1} | s_t, a_t, s_{t-1}, …) = P(s_{t+1} | s_t, a_t). In practice you engineer the state to make this true. If recent history matters (it does for a recommender), fold it into the state — and note an EMA vector already summarizes history into one carry-forward number, which is exactly a Markov-friendly representation.

The five pieces ⟨S, A, P, R, γ⟩.

• S — the set of states the world can be in.
• A — the actions available.
• P(s′ | s, a) — the transition model: the probability of the next state given the current state and action. The stochastic heart of the thing.
• R(s, a) (or R(s,a,s′)) — the reward for taking an action.
• γ ∈ [0,1) — the discount factor: a reward t steps away is worth γ^t of face value. γ near 0 = myopic (only now matters); γ near 1 = far-sighted.

What "solving" an MDP means: finding a policy. A policy π(a | s) maps states to actions. The quantity you care about is the expected discounted return from following π:

V^π(s) = E[ r_0 + γ·r_1 + γ²·r_2 + …  | start in s, follow π ]

V^π(s) is the state-value function; Q^π(s,a) is the action-value function (value of taking a in s, then following π). Solving the MDP = finding π* that maximizes value in every state.

The Bellman equation is the recursion that makes this tractable — value is immediate reward plus discounted value of where you land:

V*(s)   = max_a [ R(s,a) + γ · Σ_{s′} P(s′|s,a) · V*(s′) ]
Q*(s,a) =         R(s,a) + γ · Σ_{s′} P(s′|s,a) · max_{a′} Q*(s′,a′)

How you actually solve it — two worlds:

1. Model known (you have P and R). Use dynamic programming: value iteration (sweep the Bellman update to convergence) or policy iteration (alternate evaluate-policy / improve-policy). This is the milestone graph of §14.4 — few states, estimable transitions, solvable in a few lines.
2. Model unknown (you only get to act and observe). This is reinforcement learning. Q-learning updates value estimates from sampled transitions:

   Q(s,a) ← Q(s,a) + α·[ r + γ·max_{a′} Q(s′,a′) − Q(s,a) ]
   

   Policy-gradient methods instead push π directly toward higher return. This is the recommender of §14.3 — you can't write down how a user will respond, so you learn a policy from interaction logs.

Exploration vs. exploitation. With an unknown model, the agent must choose between exploiting the action that looks best now and exploring an uncertain one that might be better and teaches you something. ε-greedy, UCB, and Thompson sampling are the standard strategies — and this tension is exactly the diversity/exploration knob from §13.3, now with a name and a theory.

POMDP — when you can't see the true state. If the agent only gets a noisy observation rather than the state itself, it's a Partially Observable MDP. Almost every real system is one: you never observe a user's true intent, only their clicks. The fix is a belief state (a summary of history — again, the EMA vector is a crude one) used in place of S.

Two intuition anchors before we apply it:

• The bandit is the smallest MDP. A multi-armed bandit is an MDP with one state and γ = 0 — pure "which action pays best right now," no sequential effect. A contextual bandit adds a state (context) but still γ = 0. Set γ > 0 and let actions change the next state and you have a full MDP. That ladder (bandit → contextual bandit → MDP/RL) is the natural adoption path.
• Discounting is a modeling choice, not a detail. γ encodes how much you care about the future — it's where product intent enters the math.

14.3 Applying it #1 — the recommender as an MDP (a research subject, not a BMAD feature)

The strong fit, extending §13 directly. A recommender is a textbook (PO)MDP: the user is the environment, and each recommendation nudges the user into a new state whose response you can't fully predict.

The tuple ⟨S, A, P, R, γ⟩ instantiated:

Myopic vs. sequential — the concrete difference. A greedy ranker (your EMA+MMR design) maximizes immediate reward: show the highest-predicted-click item now. That can quietly degrade the state — hammer someone with the same high-CTR category and they narrow, get bored, and eventually churn. An MDP with γ > 0 will sometimes show a slightly lower-CTR item because it improves the future state — it discovers a new interest, keeps the session alive, protects long-term retention. Same catalog, same infra, different objective: sequence-value instead of click-value. That is the entire reason to reach for an MDP here.

It's really a POMDP, and that's good news for reuse: you never see true intent, but the belief state you can build is the EMA/user vector from §13. So MDP/RL layers on top of §13's representation and serving rather than replacing it — the user vector becomes (part of) S, the ANN candidate set constrains A, and the ranker becomes a learned policy.

The adoption ladder (crawl → walk → run):

1. Contextual bandit (γ = 0) over the rerank slot — the smallest useful step, and a principled version of the ε-greedy exploration you already flagged.
2. Slate bandit / slate MDP — handle that you recommend a set, where items interact (diversity, position bias); SlateQ-style decomposition tames the combinatorial action space.
3. Full RL with γ > 0 optimizing a long-horizon reward (retention, return visits) — highest ceiling, highest cost.

The hard part is evaluation, not the algorithm — off-policy evaluation (OPE). You can't A/B-test every candidate policy on live users. OPE estimates a new policy's value from logged data collected under the current policy, via inverse-propensity scoring (IPS) and doubly-robust estimators. This is the practical gate on RL recommenders and the thing a research pass should design before anyone trains a policy.

Pitfalls research should surface (all real, all expensive to learn late):

• Reward shaping / gaming — optimize raw dwell and you breed clickbait; optimize clicks and you breed rage-bait. The reward is the product's values.
• Credit assignment / delayed reward — retention arrives days later; attributing it to a recommendation three sessions ago is genuinely hard.
• Feedback loops — the policy shapes the data that trains the next policy; unchecked, it collapses diversity (the filter bubble, now self-reinforcing).
• Serving & stability — a learned policy in the request path adds latency, a model-serving dependency, and the risk of a bad policy reaching users.

How BMAD fits: research it with a technical-research pass (prompt A8 in Appendix A) — "MDP/RL vs. heuristic, and if RL, what's the OPE plan and the crawl-walk-run path?" The §13.7 boundary applies with extra force: whether RL beats EMA+MMR on your data is empirical, and the cost of being wrong is higher. Research defines the experiment (state/action/reward design, the OPE methodology, rollout guardrails); your logs decide whether to climb the ladder.

14.4 Applying it #2 — modeling BMAD's own milestones as a stochastic graph (an overlay you build)

The literal reading of the question — a stochastic dependency graph between milestones — and where the model-known branch of §14.2 applies. BMAD gives you the graph structure for free (phases, gates, and the preceded-by/followed-by edges in module-help.csv); you supply the probabilities and solve it outside BMAD.

Two versions, increasing power:

• Markov chain (no decisions) — model gate outcomes as random transitions to estimate schedule risk; this is essentially stochastic PERT.
• MDP (with decisions) — add actions at each gate — {proceed, iterate/rework, cut scope, run more research} — and solve for the optimal policy: given where the plan is and how risky the next gate looks, what's the cost-minimizing move?

A worked example. Model each gate as a transition over {pass, rework}:

              p_pass = 0.7
   [Arch gate] ───────────────▶ [Implementation]
       │  ▲
p_rework│  │ 0.3   (loop back, pay rework cost c_r)
       ▼  │
   [Re-architect]

• Expected attempts to clear a gate with pass-probability p is geometric: 1/p. At p = 0.7 that's ≈ 1.43 attempts; at p = 0.5 it's 2.0. Each extra attempt costs c_r (rework time).
• Chain three independent gates at p = 0.7: P(clean run) = 0.7³ ≈ 0.34 — only a third of projects clear all three without rework. That number alone reframes how you plan.
• Expected total rework ≈ Σ_gates (1/p_g − 1)·c_r — a concrete, defensible schedule-risk figure.

The elegant payoff — value of information. Treat "run a technical-research pass" as an action that changes a transition probability: it raises the architecture gate's p_pass (fewer late re-architecture loops). Then:

value of the research  ≈  (expected rework cost WITHOUT research)
                        − (expected rework cost WITH research)
research is worth it   ⇔   that difference  >  the research's own cost

If a research pass lifts the architecture gate from p = 0.5 to p = 0.7, expected attempts drop from 2.0 to ≈ 1.43 — saving ≈ 0.57 rework cycles at that gate. If one rework cycle costs more than the research pass, research pays for itself. This turns §13.7's qualitative "research stops you building the wrong thing" into a decision-theoretic ROI — the value-of-information calculation at the heart of MDP planning.

How to solve it: the graph is tiny (a handful of states), so value iteration by hand or ~20 lines of NumPy yields the optimal gate policy; pure schedule risk is a PERT / Monte-Carlo run.

What BMAD does / doesn't do: it emits the milestone graph and the artifacts; it does not estimate the probabilities or solve anything. You pull the edges (from module-help.csv or the planning flow), attach p values from your own historical delivery data (the weak link — garbage in, garbage out), and solve it in a notebook. A tidy loop: use bmad-technical-research to design the risk model, then own it yourself. Keep the honest caveat: the map is not the territory — a clean expected-value number built on three guessed probabilities is worse than no number.

14.5 Honest summary

• Native BMAD support for MDP / stochastic dependency graphs: none. Its model is a deterministic gated DAG with heuristic routing.
• The concept (§14.2) is sequential decision-making under uncertainty — ⟨S,A,P,R,γ⟩, solved for a policy via dynamic programming (model known) or RL (model unknown), with exploration-vs-exploitation and partial observability as the two complications that always show up in practice.
• MDP as a recommender technique (§14.3): fully applicable — the sequential, long-horizon generalization of the greedy ranker in §13, a natural bmad-technical-research subject, with off-policy evaluation as the real gate.
• Stochastic graph over BMAD's own milestones (§14.4): a valid overlay you build on the graph BMAD gives you — useful for quantifying plan risk and computing the value-of-information ROI of research itself, but solved outside BMAD.

15. Observations and Findings

Strengths

• Artifact-first design is the real value. Research isn't a chat you lose — it's a document the PRD/architecture workflows consume. The compounding across phases is the point.
• Market research is genuinely multi-agent and produces broad, structured coverage with little hand-holding.
• Clean separation of the three types maps to actually-different questions and stops you conflating "is it buildable" with "does anyone want it."
• Scale-adaptive: depth adjusts to project complexity, so bug-fix-sized work isn't pushed through enterprise-weight research.

Weaknesses / watch-outs

• Technical research is single-agent — weakest of the three for depth and speed. For high-stakes bets, plan to iterate and supply strong constraints. It amplifies a sharp prompt; it won't out-think a vague one.
• Depth options are opaque across versions — confirm at runtime.
• Command drift between short (bmad-*) and module-qualified (bmad-bmm-*) forms; bmad-help is the source of truth.
• subagent grounding regression (§9.2) — verify tool access before trusting a panel on codebase-grounded questions.
• Fresh-chat discipline is load-bearing — the most common cause of degraded, costlier output.
• Grounding is not guaranteed (§10) — research is only as current as the host's tools.

Complementary modules

• Creative Intelligence Suite (cis) — facilitated ideation frameworks (SCAMPER, reverse brainstorming, reframing) for before you have a crisp question to research.
• BMad Builder (bmb) — author your own .agent.yaml sub-agents / workflows; the sanctioned path to a personal "architecture-evaluator" sub-agent that closes the technical-research gap.
• Test Architect (tea) — risk-based test strategy and NFR assessment; research-adjacent when the question is "how will we validate this."

16. Practical Tips and Best Practices

1. For technical research, over-specify constraints. Latency budgets, runtime fit, "no new platform," existing infra you must reuse. The single agent leans on your framing.
2. State the decision, not just the topic. "Which of A/B/C and why" produces a usable doc; "tell me about reranking" produces an essay.
3. One decision per pass. Fan out across passes, then convene a panel (§9.4).
4. Match Party Mode mode to intent — session for ideation, subagent for honest critique/focus groups, agent-team for hands-off debate.
5. Verify subagent grounding before trusting a panel on real code/data (§9.2).
6. Route durable research to docs/, cycle-specific to planning-artifacts/.
7. Feed project-context.md into research so findings respect your stack from the first token (§12).
8. Offload to Web Bundles when tokens matter — run the heavy research phase on a flat-rate GPT, bring artifacts back (§11).
9. Take the keepsake HTML and attach it to the ticket; it's a real artifact.
10. Remember the boundary — research designs the experiment; your data picks the winner (§13.7).
11. Use bmb to close the sub-agent gap if you do technical research often on the same stack.
12. Always fresh chat per workflow — quality and cost both depend on it.

17. Quick Reference

Research commands

# Fresh chat, then:
bmad-agent-analyst          # load Analyst (Mary); exposes MR / DR / TR

bmad-market-research        # MR — competitors, sizing, trends (5 sub-agents)
bmad-domain-research        # DR — terminology, regulation, SME depth
bmad-technical-research     # TR — feasibility, architecture, libs (single-agent)

bmad-help                   # source of truth for what's installed / what's next

Research-adjacent

bmad-document-project           # DP  — reverse-document an existing codebase (brownfield)
bmad-generate-project-context   # GPC — write project-context.md ("constitution")
bmad-investigate                # forensic, evidence-graded system analysis (v6.8)
bmad-brainstorming              # guided ideation (before research)
bmad-party-mode                 # multi-persona room (--mode session|auto|subagent|agent-team)
bmad-customize <skill>          # pin defaults, house rules, persistent facts

BMM agents (persona · key menu codes)

Output → _bmad-output/planning-artifacts/ (cycle) or docs/ (durable). Feeds → bmad-create-prd, bmad-product-brief, bmad-create-architecture.

18. Glossary

BMAD terms

• BMM — BMad Method module; the flagship four-phase agile-AI module.
• Analyst (Mary) — the agent that runs all three research workflows.
• Skill — a workflow packaged as a SKILL.md + sharded step files; runs synchronously in the host IDE.
• Step file — step-XX-*.md, loaded just-in-time to keep context lean.
• module-help.csv — catalog mapping skills to names, menu codes, phases, output locations; powers bmad-help next-step routing.
• Party Mode — multi-persona conversation; four modes govern independence.
• Sub-agent — a specialized agent spawned within a workflow (market research) or a party (subagent mode).
• Scale-Adaptive Intelligence — automatic planning-depth adjustment by project complexity; expressed as Quick Flow / BMad Method / Enterprise tracks.
• project-context.md — the project "constitution": rules all agents follow.
• memlog — working-memory primitive carrying state across steps in a run.
• Web Bundles — planning skills packaged as Gemini Gems / ChatGPT GPTs for flat-rate, off-IDE planning.
• Gate — a mandatory checkpoint before advancing phases.

Recommender terms (used in §13)

• EMA — exponential moving average; u ← α·e + (1−α)·u for recency-weighted user profiles.
• Half-life / α / λ — the recency-decay knobs (interaction-count or time-based).
• Vectorization / embedding — mapping content/users to vectors for similarity search.
• ANN / HNSW / IVF-PQ / PQ — approximate nearest-neighbor search and its index/quantization variants (recall-vs-cost).
• Two-tower — separate learned encoders for users and items.
• MMR — Maximal Marginal Relevance; diversity rerank trading relevance against redundancy.
• Impression discounting — down-weighting recently-shown-not-clicked items.
• Inverse-propensity weighting — correcting popularity bias.
• Cold start — no history for a new user/item.
• Eval-driven development — deciding tuning constants by measurement (offline replay, adversarial evaluators, online A/B), not by research.

MDP and stochastic-planning terms (used in §14)

• MDP — Markov Decision Process; ⟨states, actions, transition probabilities, reward, discount γ⟩ for sequential decisions under uncertainty.
• Markov property — the future depends only on the current state, not the full history; you engineer the state to make this hold.
• Policy (π) — the state → action mapping an MDP solution produces (which slate to show in a given context).
• Value function (V, Q) — expected discounted return from a state (V) or a state-action pair (Q) under a policy.
• Bellman equation — the recursion V*(s) = max_a[R + γ·Σ P·V*] that defines optimal value and underlies every solution method.
• Value iteration / policy iteration — dynamic-programming solvers used when the model (P, R) is known.
• Reinforcement learning (Q-learning, policy gradient) — learning a policy from experience when the model is unknown.
• Exploration vs. exploitation — the trade between the best-known action and an uncertain one that might be better (ε-greedy, UCB, Thompson sampling).
• POMDP / belief state — partially observable MDP; the true state is inferred from observations via a history summary (a recommender rarely sees real intent, so it's really a POMDP; the EMA vector is a crude belief state).
• Contextual bandit — a one-step MDP (γ = 0); the frame behind the exploration / ε-greedy slot in §13.3.
• Discount factor (γ) — weights future vs. immediate reward; γ > 0 is what makes a recommender optimize long-term engagement over next-click.
• Off-policy evaluation (OPE) — estimating a new policy's value from logged data without deploying it live (IPS, doubly-robust); the practical gate on RL recommenders.
• SlateQ — a slate-decomposition value-learning approach for recommending sets of items under an RL/MDP formulation.
• Value of information — the expected cost/benefit of acquiring information (e.g. running research) before deciding; the ROI frame in §14.4.
• Stochastic dependency graph / PERT — a milestone graph whose edges carry probabilities (gate pass/rework), used to reason about plan time/cost risk (§14.4).

19. Appendix A: Copy-Paste Research Prompts

Ready-to-run prompt bodies. Start a fresh chat, load the Analyst, invoke the workflow, then paste. Replace bracketed parts.

A1 — Technical research (generic template)

bmad-technical-research

Decision: [the one thing to decide].
Options to compare:
1. [option] — [one line]
2. [option] — [one line]
3. [option] — [one line]
Constraints: [latency budget], [runtime/language fit], [existing infra to reuse],
[no-go's].
Output: comparison across [criteria], a recommended default, and a minimal
validation/PoC path.
Depth: [read the options the workflow offers].

A2 — Recommender Pass A (scoring & representation)

bmad-technical-research
Decision: how to represent a user's taste from view history and score candidates.
Options: (1) EMA user vector u←α·e+(1-α)·u + HNSW ANN; (2) recent-k multi-vector /
late-interaction; (3) two-tower learned; (4) hybrid (content ANN + collaborative
rerank). Constraints: O(1)-ish online update (no nightly full recompute),
Java/Spring service, OpenSearch vector store in place, tight p95.
Output: compare on freshness, multi-interest handling, cold-start, infra cost,
online-update cost; recommend a default + migration path.

A3 — Recommender Pass B (failure modes)

bmad-technical-research
Decision: mitigation strategy for recommender failure modes, view-history based.
Cover with a concrete mitigation + pipeline stage: exact duplicates, near-duplicates,
no-diversity, cross-session repetition, popularity bias, cold start, staleness.
Constraints: OpenSearch retrieval, view history queryable (Athena), content has a
cluster/grouping field. Output: a layered defense table, the order to apply layers,
and what each layer misses.

A4 — Recommender Pass C (AWS architecture)

bmad-technical-research
Decision: AWS reference architecture, batch + online paths. Cover: embedding
generation (batch backfill vs near-real-time on ingest), OpenSearch k-NN index +
quantization tradeoff, EMA user-state store (DynamoDB + TTL), serving path (rec
Lambda → ANN retrieve → seen-filter → dedup → MMR rerank → Content API hydrate),
CloudFront+ALB with origin-layer DR, warm/cold path, caching, cost drivers.
Constraints: tight p95, no GPU in request path, existing HNSW index.
Output: component/data-flow description, DR posture, top 3 cost levers.

A5 — Domain research (unfamiliar space)

bmad-domain-research
Domain: [the space]. I need: the terminology practitioners use, how "relevant"/
"good" is judged here vs. elsewhere, regulatory/ethical constraints, and the
evaluation lens I'd otherwise miss.

A6 — Market research (validation)

bmad-market-research
Space: [the category]. Who are the incumbents and adjacent players, the current
trend line, and where are the gaps a fast-follower could exploit?

A7 — Reconcile passes in a panel

bmad-party-mode --mode subagent
Convene: relevance-engineer, latency-hawk, ops-SRE, cost-owner, eval-skeptic.
Inputs (read these files): pass-A-scoring.md, pass-B-failure-modes.md, pass-C-aws.md.
**A8 — Recommender as MDP / RL (should we?)**

bmad-technical-research Decision: should the ranking stage be formulated as an MDP/RL problem (optimizing long-term engagement) or stay a greedy EMA+MMR heuristic (optimizing the next slate)? Frame: S = user vector + session + recent impressions; A = slate; P = stochastic user response; R = engagement/retention; γ = long-term weight. Compare: contextual bandit (one-step), slate-decomposition value learning (SlateQ-style), and the heuristic baseline. Constraints: no live experimentation on every policy (need off-policy evaluation), tight p95, existing OpenSearch/DynamoDB serving. Output: when RL is worth its cost, the off-policy eval plan, serving/complexity implications, and a recommended crawl→walk→run path from the heuristic baseline.

---

## 20. Appendix B: Custom Party Definitions

Author these with `bmad-party-mode, create a new party` (it writes to your overrides
via `bmad-customize`). The exact override-file format is version-specific and the
skill writes it for you — provide the personas and scene below when prompted.
Personas need *teeth*: specific values, first-move behavior, and a blind spot.

**B1 — Reranking / Scoring Decision Panel** (run `--mode subagent`)

- **Rel (Relevance Engineer).** Fights for measured relevance lift (nDCG, MRR,
  recall@k). Opens by asking for the offline metric and the candidate set size.
  Blind spot: discounts operational cost.
- **Pax (Latency Hawk).** Rejects anything that risks the p95 budget or puts a GPU
  in the request path. First question is always "what does this add to tail
  latency?" Blind spot: would ship a fast but mediocre ranker.
- **Sol (Ops/SRE).** Guards index rebuild cost, operational surface, and failure
  modes under region degradation. Blind spot: conservative to a fault.
- **Cass (Cost Owner).** Ranks options by cost-per-query and recompute frequency;
  challenges anything without a cost line. Blind spot: penny-wise on relevance.
- **Vera (Eval Skeptic).** Won't accept any recommendation without a concrete
  experiment that could disprove it. Says "how will we *know*?" in the first thirty
  seconds. Blind spot: can stall a decision that's good enough.

*Scene:* a design review for the recommender's ranking stage; the team must pick one
approach and a validation plan by end of session, and the eval skeptic has veto over
"just ship it."

**B2 — View-History Focus Group (from data)** (run `--mode subagent`)

Hand the room **anonymized user view-history clusters**; it builds representative
personas that react to a proposed recommendation strategy *from their own
behavior*, instead of one model rubber-stamping. Example seeded members:

- **The Specialist.** Reads deep in one narrow area; hates diversity injection that
  pulls them off-topic. Reacts badly to exploration slots.
- **The Generalist.** Grazes across many areas; punished by a single-centroid EMA
  that averages their interests into mush.
- **The Returner.** Comes back weekly; furious when shown items they already read
  (tests your seen-set/impression-discounting).
- **The New Arrival.** Little history; the cold-start canary.

*Scene:* each persona is shown a sample recommendation slate produced by the
candidate strategy and reacts from their own goals; the room surfaces which user
type each design choice helps or hurts.

> **Grounding note (§9.2):** for B2 to be worth anything, the spawned personas must
> actually consume the cluster data you provide — verify tool/file access, or paste
> the cluster summaries directly into the room.

---

## 21. Sources and Recency

Synthesized from the current BMAD-METHOD docs and repository
(docs.bmad-method.org, the `bmad-code-org/BMAD-METHOD` repo, its releases/issues,
and the DeepWiki module reference), plus third-party testing writeups, reflecting
the V6 / BMM state through mid-2026.

Version-sensitive or unverified items, flagged inline where they appear:

- **Research depth option values** — defined in workflow step files, not public
  docs; not verified. Read the options at runtime or ask `bmad-help`.
- **Short vs. `bmm`-qualified command form** — varies by build; `bmad-help` is
  authoritative.
- **The `subagent` grounding regression (§9.2)** and the open request for true
  native-subagent parallelism — both tracked upstream and actively changing;
  re-verify grounding on your build before trusting `subagent` mode for factual,
  code-grounded work.
- **The ~$200 full-cycle token figure (§11)** — one independent measurement, not an
  official number; treat as order-of-magnitude.
- **Custom party override-file format (Appendix B)** — the skill writes it; the
  exact schema is version-specific.

The recommender engineering content in §13 (EMA, MMR, ANN/quantization, the AWS
shape) is stable engineering knowledge, independent of BMAD version.

*Confirm anything load-bearing against your installed version with `bmad-help`.*