Source: bmad-rcon-howto · bmad-rcon-howto.md · updated 2026-07-25 · 🔒 secret gist

Synced verbatim from gist.github.com/bl9.

Part 1.5 — Concept-by-concept how-to

Companion to bmad-deep-recon-foundations.md (what the terms mean) and bmad-deep-recon-guide.md (task-driven walkthroughs).

What this document is for. The foundations doc explains what a dimension, a topology, or a mode is. This one shows, for each concept, exactly what you type, exactly what comes back, and exactly what you do next. One concept at a time, in the order you'll meet them.

Section 20 does the same thing without BMAD at all — the same techniques applied in a plain Claude conversation, since dimensions, plan gates, source discipline and staleness are portable ideas, not BMAD features.

Fidelity note. Session excerpts are illustrative reconstructions. The interaction shape — what you're asked, what you can say back, what lands on disk — reflects the documented design. Exact wording lives in the skill's reference files and will differ. TOML key paths should be confirmed against your installed customize.toml.

Contents

• 0. Setup
• 1. Mode: Draft
• 2. Mode: Process
• 3. Mode: Run
• 4. Type and pack
• 5. Decision shape: explore vs select
• 6. Dimension
• 7. Topology
• 8. The plan gate, line by line
• 9. Effort presets and budgets
• 10. Rounds and leads
• 11. The firewall
• 12. Verification and red team
• 13. Claims and statuses
• 14. Briefs, digests, memlog
• 15. Staleness, refresh, deepen
• 16. The run folder and slug
• 17. Headless and scripting
• 18. Configuration in practice
• 19. Recovering when things go wrong
• 20. All of this in plain Claude, without BMAD
• 21. One-page cheat card

0. Setup

npx bmad-method install     # pick your IDE; deep-recon ships in core

Verify and look around:

/bmad-customize bmad-deep-recon

Read the options; change nothing yet. You're building a map of what's adjustable.

1. Mode: Draft

What Draft does: composes a research prompt carrying the pack's craft — pruned dimensions, freshness bars, source policy, a hard citation demand — tuned to the external tool you name. You paste it into that tool. No searching happens in your session.

Use it when: you already pay for ChatGPT/Gemini/Perplexity deep research, and the question is a broad public sweep.

What you type

> /bmad-deep-recon

draft a deep research prompt for Gemini: choosing a machine translation
vendor for EN↔FR, EN↔ES, EN↔JA, at roughly 40M characters/month.
Hard requirements: EU and Canada data residency, glossary and
do-not-translate support, and a DPA we can actually sign.
Type: competitive, select shape.

What comes back (shape)

DRAFTED PROMPT — for Gemini Deep Research
─────────────────────────────────────────
Research the commercial machine-translation vendor landscape for a buyer
with the following profile: [your volume, pairs, residency needs].

Cover these dimensions, in priority order:
  1. Pricing structure at 40M chars/month — not list price, the actual
     shape (per-character, committed-use tiers, minimums)
  2. Per-pair quality evidence for EN↔FR, EN↔ES, EN↔JA specifically;
     distinguish vendor-reported from independent
  3. Data residency options for EU and Canada; processing locations
  4. Glossary / do-not-translate / custom terminology feature parity
  5. Contractual posture: DPA availability, sub-processors, training-on-
     customer-data defaults, exit and portability terms

Source requirements:
  - Every claim must carry publisher, publication date, access date
  - Pricing and feature claims older than 6 months: flag as possibly stale
  - Mark vendor self-reported quality claims explicitly as self-reported
  - Prefer primary sources (vendor docs, pricing pages, trust centres)
    over review-aggregator sites

Output: a comparison with an explicit "could not determine" section.
─────────────────────────────────────────
Paste this into Gemini. When you have the report back, run:
   process <path to the report>

What you do

Check three things before pasting. This is the whole skill of Draft mode:

Edit the prompt freely. It's a starting point, not an output.

Why it works this way

The value isn't that Deep Recon can write a prompt — you could. It's that the pack's craft gets embedded automatically: the dimension priorities, the source policy, the self-reported-claim flagging, the "could not determine" demand. Those are the things people forget, and they're the difference between a usable report and a marketing summary.

2. Mode: Process

What Process does: takes a finished report from anywhere, files the original untouched, extracts claims into digests behind the firewall, gap-checks against the pack, and distills the standard cited research.md.

Use it when: you have a document — from Draft mode, from an analyst, from a colleague.

What you type

> there's a research report at ~/Downloads/mt-vendors.pdf, process it

What comes back

PROCESSING — competitive pack

  imports/mt-vendors.pdf              preserved, unmodified
  digests/d01-pricing-structures.md   14 claims extracted
  digests/d02-quality-evidence.md      9 claims  (6 flagged self-reported)
  digests/d03-residency.md             7 claims
  digests/d04-terminology-features.md  5 claims

GAP CHECK against the competitive pack
──────────────────────────────────────
COVERED
  pricing, language coverage, published quality claims, API surface

GAPS — not covered by the imported material
  ✗ sub-processor lists and processing-location commitments
  ✗ training-on-customer-data defaults and opt-out terms
  ✗ exit terms and data portability
  ✗ per-pair quality for EN↔JA specifically (only aggregate given)

research.md written — 35 claims, 22 sources, 4 gaps flagged

What you do

Read the gap list, not the report. That's where the value is.

Notice the pattern in that example: every gap is either contractual or specific to you. Hosted research tools crawl broad public commercial surfaces well and are systematically poor at narrow contractual questions and at your particular parameters. That's the division of labour to internalize — and it tells you what to do next:

> run a focused pass on the gaps only — sub-processors, training-on-data
  terms, exit/portability, and EN↔JA quality specifically.
  Effort standard, validation high.

This lands in the same run folder, because the slug is deterministic across the draft → process → refresh lifecycle. One decision, one artifact.

Why it works this way

Preserving the original untouched is provenance: you can always go back to what the tool actually said, rather than trusting the extraction. Extracting behind the firewall means your project context can't shape which claims get pulled out.

3. Mode: Run

What Run does: native research in your session — plan gate, parallel fan-out, verification at landing, cited synthesis.

Use it when: you want it now, or you need tools only your session has (internal MCP sources, your own files, an authenticated API).

What you type

> /bmad-deep-recon

I need to choose a reranking approach for our recommendation retrieval
stage. Decision horizon ~12 months. Candidates to include but not to
confirm: cross-encoder rerank, learned sparse rerank, MMR-only diversity,
no rerank at all.

Constraints: 200ms p99 for the whole retrieval stage, of which rerank can
have at most 40ms. Multilingual content. We self-host; no hosted APIs.

Type: technical, select shape. Effort: standard. Validation: high.

What comes back

The plan gate — covered in detail in §8. You approve or amend, and then:

ROUND 1 — breadth-first, 3 assistants
  [dim 1] latency/throughput ................ 8 sources → digest landed
  [dim 2] quality delta evidence ............ 8 sources → digest landed
  [dim 3] multilingual behaviour ............ 8 sources → digest landed

  verifying load-bearing claims as they land...
  § "Latency and throughput" written

LEADS FROM ROUND 1
  - Two sources disagree on cross-encoder latency by ~3x; the difference
    appears to be batch size and hardware, not the model
  - Learned-sparse rerank quality claims are almost entirely from one
    research group

ROUND 2 — depth on the two leads
  ...

What you do

Watch for two things and speak up:

• Aggregator pileup. If several digests trace to the same summary site, that's one publisher wearing several hats: "dimension 2 is leaning on aggregators — chase the primary papers."
• Leads not being chased. Disagreement is the most valuable signal in the run. If round 2 isn't going after it, say so.

You can interject at any point; you don't have to wait for a checkpoint.

4. Type and pack

How to set it. Three ways, in increasing explicitness:

> research the MT vendor landscape                    # type inferred
> competitive research on the MT vendor landscape     # named in prose
> Type: competitive.                                  # stated as a parameter

How to see what a pack changes

Ask before approving:

> what does the competitive pack prioritise, and what are its freshness
  windows?

You'll get the card: dimension priorities, source craft, freshness per claim class. Reading this once for each type you use is 5 minutes well spent — it's how you learn what to add at the plan gate, because you'll see what the pack considers out of scope.

Choosing when it's ambiguous

When two fit, run two. A vendor decision often needs competitive (what they offer) and domain (what the regulations require of anyone offering it). Merging them gives you a report that's shallow on both, because they want different sources.

5. Decision shape: explore vs select

Two independent axes: type = the subject matter, shape = the form the conclusion takes.

explore — you don't yet know the option space

> technical research: how are teams handling multilingual embedding
  drift as models get re-versioned? Explore shape.

Output: a structured understanding. Approaches, trade-offs, who does what, where the disagreements are. No recommendation, because you haven't defined what you're choosing between.

select — you're choosing, and you know the candidates

> technical research, select shape: choose between cross-encoder rerank,
  learned sparse rerank, and MMR-only, under a 40ms budget.

Output: everything explore gives you, plus a weighted matrix where the weights are your stated constraints.

The mistake, and how to avoid it

Running select too early narrows prematurely. If you name three candidates before you know whether there's a fourth category you've never heard of, the matrix will confidently rank three options out of a space you haven't mapped.

The sequence when you're genuinely unsure:

1. > ... explore shape          # map the space, cheap preset
2. read the report; now you know the real option space
3. > ... select shape, candidates: [what you learned]

Two cheap runs beat one expensive run that answered the wrong question.

6. Dimension

This is the concept with the highest leverage, so here it is as a full interaction.

Seeing them

Dimensions appear at the plan gate. You don't create them from nothing — the pack proposes, you edit.

DIMENSIONS (5)
  1. Latency and throughput under our budget
  2. Quality delta versus no-rerank baseline
  3. Multilingual behaviour and per-language variance
  4. Serving cost and hardware requirements
  5. Implementation and operational complexity

The four operations

DELETE — the one you'll use most.

> Drop dimension 5. We have the eng capacity; complexity isn't a
  differentiator for this decision.

Why: each dimension costs a full fan-out. At deep, cutting one saves roughly 15% of the run. Dimensions that don't bear on the decision aren't neutral — they dilute.

ADD — the one that determines whether the report is useful.

> Add a dimension: behaviour under filtered ANN search. Every benchmark
  I've seen measures unfiltered top-k, but our production path always
  applies filters, and I suspect that's where the approaches diverge.

Why: the pack is generic by design. Only you know your constraints. In that example the addition is the difference between a report that answers your question and one that answers a similar-looking question.

SPLIT — when one dimension is secretly two.

> Split dimension 2. "Quality delta" for us is two separate questions
  with different evidence bases: published benchmark deltas, and
  reported production A/B results. Keep them separate — the benchmark
  literature and the engineering-blog literature don't overlap.

Why: merged dimensions get one brief, one set of sources, and a shallow answer to both halves.

MERGE — when two would hit identical sources.

> Merge 1 and 4. Latency and hardware cost come from the same
  benchmarks; running them separately duplicates the search.

How to tell whether your dimension set is good

Three questions, in order:

1. Does it span the decision? If you imagine the report coming back complete, is there any way you'd still be stuck? That's a missing dimension.
2. Is anything here not load-bearing? If a dimension's answer wouldn't change your choice, delete it.
3. Would two of these send an assistant to the same sources? Merge them.

The test that catches most errors

For each dimension, finish this sentence:

"If this comes back saying ___, I choose differently."

If you can't complete it, the dimension isn't decision-relevant. Delete it or reframe it.

7. Topology

Topology is proposed for you. You mostly review it — but knowing how to override is what lets you fix a badly-shaped run before it costs you 40 minutes.

Seeing it

TOPOLOGY   breadth-first (dimensions are largely independent)

The three, and what each looks like in practice

Breadth-first — the default, and right most of the time.

ROUND 1 — breadth-first, 3 assistants
  [dim 1] ──→ assistant A ──→ digest
  [dim 2] ──→ assistant B ──→ digest      all in parallel
  [dim 3] ──→ assistant C ──→ digest

Use when the dimensions are genuinely independent. You get even coverage across everything.

Depth-first — one question, multiple angles, iterating.

> Use depth-first. This is really one question — whether the reported
  cross-encoder latency numbers hold on our hardware class — and the
  disagreement between sources IS the problem.

ROUND 1 — depth-first, 3 assistants, one question
  assistant A: vendor and library documentation
  assistant B: independent benchmarks and reproductions
  assistant C: production engineering reports
        ↓
  synthesise, identify what's actually in dispute
        ↓
ROUND 2 — chase the disputed mechanism

Use when you have one contested question and the contradiction matters more than breadth.

Straightforward — one assistant, small budget.

> This is a lookup. Straightforward topology, quick preset.
  Just: what's the current license on [model], and has it changed
  in the last 12 months?

Use for facts. Ten agents on an easy question just burns tokens — this is the most common waste in the whole system.

How to tell the proposal is wrong

Why knowing the algorithms helps

BFS and DFS are graph-traversal algorithms (see the foundations doc, §4.6). Their known weaknesses transfer directly:

• BFS holds the whole frontier in memory → breadth-first research burns more tokens per round. If you're context-constrained, fewer dimensions beats a lower preset.
• DFS can go far down a wrong corridor → depth-first research on a question that turns out to be a side issue wastes the entire run. Only go depth-first when you're confident the question is central.

8. The plan gate, line by line

The single hard stop. Here's how to read every line of it.

DECISION                                          ← ① is this actually your decision?
  Select a reranking approach for recommendation
  retrieval; 12-month horizon, 40ms budget.

DIMENSIONS (5)                                    ← ② prune, add, split, merge
  1. Latency and throughput
  2. Quality delta vs. no-rerank baseline
  3. Multilingual behaviour
  4. Serving cost and hardware
  5. Implementation complexity

TOPOLOGY   breadth-first                          ← ③ right shape?
EFFORT     standard — 3 assistants / 8 sources
           per round / 2 rounds                   ← ④ matches reversibility?
VALIDATION high; red_team off                     ← ⑤ do you have a prior?
FRESHNESS  benchmarks 12mo · libraries 6mo        ← ⑥ fast-moving field?
ESTIMATE   ~22 minutes                            ← ⑦ matches your patience?

Approve, or tell me what to change.

The seven checks

A realistic reply

Approve with changes:
- Drop 5; complexity isn't a differentiator here
- Split 2 into published-benchmark evidence vs. production A/B reports
- Add: behaviour under filtered ANN search, not just unfiltered top-k
- Keep breadth-first and standard
- red_team on — I'm going in expecting cross-encoder to win, so argue
  against it

Why you get exactly one gate

Constant confirmation trains you to click through. One gate that genuinely matters gets read. Everything after it is light checkpoints. Your attention here is the single highest-value input you give the system — a well-cited report answering a badly-framed question is the most expensive failure mode available.

9. Effort presets and budgets

Setting it

> ... effort: deep
> ... quick preset, this is just a sanity check

The presets

Precedence — memorize this

Your request beats a pinned setting beats the preset. Whatever you say in the moment wins. So you can pin standard in TOML and still say "deep for this one" without editing config.

Overriding one axis only

You don't have to take a preset whole:

> standard preset, but 3 rounds instead of 2 — I expect the first round
  to surface contradictions and I want them chased properly

Changing effort mid-run

> stop after this round and write up what you have — I have less time
  than I thought

The stop-and-write valve exists precisely for this. Files-first means everything already landed is kept.

How to choose

Scale to reversal cost, not to how interesting the question is:

10. Rounds and leads

A round is one full cycle of parallel searching, followed by reassessment. Leads are what round 1 produces that shapes round 2: contradictions, unexpected connections, gaps.

Watching leads form

LEADS FROM ROUND 1
  - Two sources disagree on cross-encoder latency by ~3x
  - Learned-sparse quality claims trace to one research group
  - No source addresses filtered-search behaviour at all

Steering round 2 — this is where you add most value mid-run

> For round 2: the 3x latency disagreement is the most important thing
  here. Chase the mechanism — I suspect it's batch size and hardware
  class rather than the model. Deprioritise the sparse-rerank lead;
  single-group evidence is enough for me to discount it.

Contradictions are the highest-value lead type. When two credible sources disagree, one of three things is true, and all three are worth knowing:

1. The claims are about different conditions (usually — and the conditions are the real finding)
2. One source is wrong (which tells you about that source)
3. The field genuinely disagrees (which means your decision carries more risk than the report's tone suggests)

When rounds stop

A dimension stops early when its questions are answered or a full round surfaces nothing new. You can force it:

> dimension 3 is done — stop there and move on

11. The firewall

The rule: your project context may shape what gets asked. It may never shape what counts as evidence. Subagents receive only their brief.

Working with it correctly

✅ Our retrieval stage has a 200ms p99 budget and we self-host.
   Given those constraints, what reranking approaches are viable?

Your context became a constraint on the question. Legitimate — that's the context of discovery.

Breaking it by hand — what not to do

❌ Here's our current architecture doc [paste]. Research whether our
   reranking approach is the right one.

You've supplied the conclusion as context. You'll get a well-cited report explaining that your approach is sound. It will be persuasive and worthless.

The tell: if you're pasting a design in and asking "is this right?", stop. Reverse the order:

✅ 1. What do the constraints and evidence say the right approach is?
   2. [read the report]
   3. Now compare your design yourself.

That ordering is the discipline. It costs you nothing and it's the difference between research and justification.

When you genuinely need internal context

Sometimes the research genuinely requires internal sources — your own metrics, an internal wiki, a private API. The firewall doesn't forbid this; it's about where the context enters:

> Use our internal metrics MCP for dimension 1 only — I need our actual
  p99 distribution, not published benchmarks. Keep dimensions 2-4
  external-only.

Scoping internal sources to a specific dimension keeps the rest of the run clean. What you're avoiding is internal context bleeding into dimensions where it would bias the external evidence gathering.

Checking it held

> did any dimension's findings rest on context I supplied rather than
  retrieved sources?

A clean run answers "no." If the answer is anything else, that's a finding about the report's reliability.

12. Verification and red team

Setting the level

> ... validation: high

Turning on red team, and why the phrasing matters

> red_team on. I'm going in believing cross-encoder rerank is the right
  answer — argue the strongest case against it.

Naming your prior explicitly gives the adversarial pass a target. "Red team this" is weaker than "here is what I believe; attack it."

The rule for when: turn it on exactly where you already believe the answer. Nobody walks into a security or privacy review neutral — you walk in believing you're fine. That's the condition it exists for. It's off by default because it costs tokens, not because it's optional for high-stakes work.

Challenging a specific claim mid-run

> claim [7] is doing a lot of work in this recommendation and it's from
  a vendor blog. Verify it independently or downgrade it.

What verification is not

The system checking a claim is the same system that produced it. That's a coherence check, not independent corroboration. Useful, weaker than the word suggests. Treat high validation as "the obvious errors were caught," not "this is confirmed."

13. Claims and statuses

Every claim carries a status: unverified → verified → disputed → overturned.

Reading them

[4] Cross-encoder rerank adds 35-60ms at batch size 32 on A10-class
    hardware.  [verified · 2 independent sources · pub 2026-02, 2026-04
    · accessed 2026-07-25]

[7] Learned-sparse rerank matches cross-encoder quality at 40% the
    latency.  [disputed · vendor-reported · single research group ·
    pub 2025-11 · accessed 2026-07-25]

What to do with each status

Why overturned claims aren't deleted

Because erasing the old belief destroys the audit trail that makes the new one trustworthy. If you can rewrite history, nobody can tell "this was always true" from "someone changed it." Same reason version control doesn't delete old commits.

Challenging the tally

> how many claims in the recommendation section are still unverified?

That count comes from the deterministic script, not the model's estimate — it's a real count.

14. Briefs, digests, memlog

Inspecting a brief — what one assistant was actually told

cat _bmad/planning/rerank-selection-2026-07/briefs/latency-throughput.md

Why look: if a dimension came back thin, the brief usually shows why — it was too broad, or too narrow, or it didn't mention your hardware class. That diagnoses whether to re-run the dimension or reframe it.

Inspecting a digest — what one assistant found

cat _bmad/planning/rerank-selection-2026-07/digests/d01-latency.md

Why look: trace one claim from research.md back through its digest to its source. Do this once, early. After you've seen how a claim in the report relates to what was actually retrieved, you'll never over-trust a polished report again.

Reading the memlog

tail -40 _bmad/planning/rerank-selection-2026-07/memlog

Append-only, so it shows the sequence — including claims whose status changed. ref= and status= entries are what the deterministic script tallies. Last status wins.

Why files-first exists

Everything lands on disk when it exists, not at the end. Consequences you'll actually feel:

• A run that dies at minute 30 resumes from disk
• The report builds in front of you instead of behind a spinner
• You can inspect intermediate work and intervene

15. Staleness, refresh, deepen

The staleness map

At the bottom of every report:

STALENESS MAP
  Fast-moving (re-check ~3 months)
    [4] latency figures — hardware and runtime releases move these
    [11] library versions and API surface
  Medium (~12 months)
    [7] published quality benchmarks
  Slow (~24 months)
    [2] license terms

Turn this into calendar entries the same day. This is the step everyone skips, and skipping it is what turns a living asset into a snapshot.

Refresh — time has passed

> refresh the rerank research

CONFIRMED (9)
CHANGED (2)
  [4] latency improved ~25% after a runtime release
  [11] library API changed; migration guide published
OVERTURNED (1)
  [7] the quality parity claim was retracted by the authors

⚠  Claim [7] is referenced by:
       docs/decisions/0021-reranking.md

That warning is why the lifecycle exists. What you do: open the ADR, note the change, decide whether it changes anything. Often it doesn't. The value is that the question got asked.

Deepen — a dimension was under-answered

> deepen the filtered-ANN-behaviour dimension

Drills one dimension without re-running the rest. Minutes, not tens of minutes.

Choosing between them

16. The run folder and slug

Finding your runs

ls _bmad/planning/
# rerank-selection-2026-07/
# mt-vendor-selection-2026-07/
# embedding-model-selection-2026-06/

The slug is deterministic — generated by the script, not the model — so draft, process, and refresh of the same decision all land in the same folder.

Anatomy

rerank-selection-2026-07/
├── imports/     # originals, untouched — provenance
├── digests/     # extracted claims — the working layer
├── briefs/      # what each assistant was told — file-based, never shell
├── memlog       # append-only sequence — the truth
└── research.md  # the canonical cited report — the artifact

Where to put it in your repo

docs/decisions/
├── 0021-reranking.md          # ADR: what we chose, and why
└── 0021-research.md           # the evidence, with provenance

The ADR tells you what in six months. The research file tells you whether it still holds.

17. Headless and scripting

output_format = auto renders HTML for interactive runs and plain markdown for headless or skill-invoked ones — no configuration needed.

A quarterly refresh job

# .github/workflows/research-refresh.yml
on:
  schedule: [{ cron: "0 6 1 */3 *" }]
jobs:
  refresh:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          bmad-deep-recon refresh \
            --headless --output-format md \
            --workspace docs/decisions/research/
      - run: ./scripts/alert-on-overturned.sh

The alerting rule that keeps it alive

Alert on overturned, and on changed where the claim is referenced by a decision record. Ignore confirmed.

Get this wrong and you've built a quarterly notification everyone mutes by the second quarter. Get it right and you have decision-rot detection that costs nothing and requires nobody to remember.

18. Configuration in practice

The three layers

Merge rules: scalars override; tables deep-merge; arrays of tables keyed by code/id replace matches and append new ones; other arrays append. No removal mechanism — you override, you don't delete.

A sensible day-one personal config

# _bmad/custom/bmad-deep-recon.user.toml

[workflow]
output_format = "both"
validation    = "normal"
# red_team stays off globally — turn it on per-run, deliberately

A domain source policy — the highest-value override

[[workflow.source_policies]]
code = "regulatory"
preferred = ["eur-lex.europa.eu", "edpb.europa.eu", "ico.org.uk",
             "priv.gc.ca", "cai.gouv.qc.ca"]
banned_kinds = ["law-firm marketing", "compliance-vendor content marketing"]

[[workflow.source_policies]]
code = "security"
preferred = ["nist.gov", "owasp.org", "attack.mitre.org", "nvd.nist.gov"]
banned_kinds = ["security-vendor content marketing"]

Write a policy for a domain you know well. You can already tell good sources from bad in your own field — that expertise is exactly what a source policy encodes, and it's the single most effective configuration you can make.

Confirm key paths against your installed customize.toml; the shape and intent are what matter here.

19. Recovering when things go wrong

That last row is the important one. Re-framing until you get the answer you wanted is the one failure mode the whole system cannot protect you from, because you're driving.

20. All of this in plain Claude, without BMAD

Most of what makes Deep Recon good is discipline, not tooling. You can run a decent approximation in any Claude conversation. Here's the whole method.

20.1 The five moves

Move 1 — State the decision, not the topic.

I'm choosing between cross-encoder rerank, learned sparse rerank, and
MMR-only for a recommendation retrieval stage. Constraints: 40ms budget
for rerank, multilingual content, self-hosted only, 12-month horizon.

Before you research anything: propose 4-6 independent dimensions of
investigation, and tell me which you'd prioritise. Don't search yet.

That last line manufactures your own plan gate.

Move 2 — Prune the plan before any searching.

Drop the "implementation complexity" dimension — not a differentiator
for us. Add: behaviour under filtered ANN search specifically, since
benchmarks measure unfiltered top-k and our path always filters.
Now go.

Move 3 — Demand the source discipline explicitly.

For every claim: publisher, publication date, and note whether it's
vendor self-reported or independent. Flag anything published more than
12 months ago as potentially stale rather than stating it as current.
If several claims trace back to one original source, say so — I want to
know when three citations are really one.

Move 4 — Ask for the negative space. The single highest-value instruction, and the one people never give:

End with two sections:
- What you could not determine, and why
- Which of these claims will go stale fastest, and roughly when I should
  re-check them

Move 5 — Red-team it in a separate turn.

I'm inclined toward cross-encoder. Make the strongest case that I'm
wrong, using the evidence you gathered.

Separate turn matters — asking for a recommendation and its refutation in one breath produces a hedge instead of an argument.

20.2 Keeping the firewall

The discipline is entirely on you here, because there's no architectural barrier:

❌ Here's our architecture [paste]. Is our approach right?
✅ What do the constraints and evidence say? [read] ... then compare yourself.

If you must supply internal context, scope it and say why:

Use this only as a constraint on the question, not as evidence:
our p99 budget is 200ms and we self-host. Don't let it shape which
sources you weight.

Weaker than a real firewall — it's an instruction, not a wall — but stating it makes you notice when you're about to break it, which is most of the benefit.

20.3 Approximating the artifact

Ask for the output as a file with the metadata that makes it durable:

Write this to a markdown file with frontmatter: date, the decision it
supports, and a source list with publication and access dates.

Then commit it next to the ADR, exactly as you would with BMAD output. The lifecycle is the part you can fully replicate without any tooling — a dated file in version control and a calendar reminder from the staleness section gets you most of the refresh mechanism.

20.4 Approximating refresh

Three months later, open the file:

Here's a research file from three months ago. Re-check only the claims
it flags as fast-moving. Tell me: confirmed, changed, or overturned —
and flag anything overturned that the linked decision depends on.

20.5 What you can't replicate

Being honest about the gap:

The honest summary: roughly 70% of the value is discipline you can adopt today, in any conversation, with no installation. The tooling buys you enforcement, parallelism, and lifecycle — real things, but they're the multiplier on the discipline rather than a substitute for it.

If you take one thing from this document into tomorrow's work, take Move 1 and Move 4: state the decision before the topic, and always ask what couldn't be determined.

21. One-page cheat card

Framing

I'm choosing between X, Y, Z. Constraints: A, B, C. Horizon: N months.
Include those candidates but don't treat the list as the frame.
Type: <market|domain|technical|competitive|user-voice|academic-lit>
Shape: <explore|select>   Effort: <quick|standard|deep>
Validation: <normal|high|max>   red_team: <on|off>
Freshness: claims older than N months are history, not fact.

At the plan gate

Approve with changes:
- Drop dimension N — doesn't bear on the decision
- Add: <the thing only you know matters>
- Split N into <A> and <B> — different evidence bases
- Topology: <breadth-first|depth-first|straightforward>
- red_team on — I'm going in believing <X>

Mid-run

Dimension N is leaning on aggregators — chase the primaries.
Round 2: prioritise the <contradiction>; deprioritise <weak lead>.
Claim [n] is load-bearing and single-sourced — verify or downgrade.
Stop after this round and write up what you have.

Reading the report — in this order

1. Could not determine       4. Staleness map → calendar
2. Selection matrix weights  5. The recommendation, last
3. Self-reported flags

Lifecycle

refresh the <topic> research      # time passed
deepen the <dimension> dimension  # under-answered
/bmad-deep-recon                  # genuinely new question

The sentence that gates everything

"I am choosing between ___, ___ and ___, under constraints ___, ___ and ___, and I'll live with it for ___ months."

Can't write it? You're not ready to research — you're ready to brainstorm.

Companions: bmad-deep-recon-foundations.md (what the terms mean) · bmad-deep-recon-guide.md (task-driven walkthroughs, applied domains, epistemology)