Why ARM Plans Are Fundamentally Different From BMAD

The current wave of AI planning systems has largely optimized around one thing: document generation.

Systems like BMAD generate PRDs, architecture documents, implementation plans, role-based outputs, and simulated cross-functional workflows. The result is often impressive at first glance: large outputs, multiple “agents,” extensive structure, and the feeling of completeness.

But there is a serious problem hiding underneath that approach:

More generated text does not necessarily create better decisions. That realization is one of the core reasons behind ARM (Adversarial Review Module).

ARM (Adversarial Review Module) is an open-source structured planning and adversarial review system focused on clear decisions, evaluable plans, and implementation-independent execution.

Website:

https://branchpointlabs.github.io/arm-adversarial-review-module/

Repo:

https://github.com/BranchPointLabs/arm-adversarial-review-module

It was designed as a structured planning and decision framework for technical PMs and engineers who need to answer a much harder question:

“What exactly are we committing to, how do we evaluate it, and how do we know if this work should continue?”

BMAD Optimizes for Artifact Production

BMAD-style systems generally follow this pattern:

Input
→ Role prompts
→ PM document
→ Architect document
→ Engineering document
→ QA document
→ Massive generated output

The assumption is that simulating multiple roles creates rigor.

Sometimes it does.

But in practice, several issues appear very quickly:

• documents become extremely large
• engineers often do not fully read them
• artifacts drift out of sync
• implementation details become prematurely prescribed
• generated architecture gets mistaken for validated architecture
• review becomes difficult because the surface area is enormous

The result is often a planning process that looks sophisticated while becoming increasingly difficult to evaluate.

This issue was explicitly identified early in ARM’s design direction:

“More text → less clarity → weak decisions.”

ARM intentionally moves in the opposite direction:

“Less text → stronger pressure → clearer decisions.”

ARM Treats Planning as a Hierarchy of Evaluatable Work

The ARM hierarchy is:

Plan
→ Initiatives
→ Epics
→ Tickets
→ QA Review

Each level has a specific responsibility.

Initiative

A major body of work with one clear responsibility.

Epic

A child outcome area under an initiative.

Ticket

A specific implementation-independent goal containing:

• success requirements
• validation criteria
• measurable outcomes

QA Review

The QA Review page converts the plan into an evaluable system:

• what must be tested
• what evidence should be captured
• how tickets map to acceptance validation

This is not documentation for its own sake.

It is a decision framework.

BMAD Simulates Teams | ARM Structures Decisions

• No massive text document to read → multi-page output
• Editable in the reading view
• Pre-planning questions can tailor to the plan produced to your specific use case
• Automatically generated Mermaid relationship diagrams, to help explain at a high level the relationship between the elements of the plan
• Tickets are aimed at goals and validation criteria not implementation details

Final Thought

ARM is not trying to replace engineering thinking with AI-generated architecture.

It is trying to improve planning clarity before implementation begins.

The goal is not maximum output.

The goal is:

• clear responsibilities
• measurable outcomes
• structured validation
• readable plans
• implementation flexibility

Website:

https://branchpointlabs.github.io/arm-adversarial-review-module/

Repo:

https://github.com/BranchPointLabs/arm-adversarial-review-module