The RBPIV working cycle

RBPIV is the repeatable loop inside and across the role harnesses: Research, Brainstorm, Plan, Implement, Verify. It is not a waterfall. A failed gate returns the work to the earliest stage where the missing fact or decision belongs.

flowchart TD
  R[1 · Research<br/>What is true?] --> B[2 · Brainstorm<br/>What could work?]
  B --> P[3 · Plan<br/>What exactly will change?]
  P --> I[4 · Implement<br/>Make one bounded change]
  I --> V[5 · Verify<br/>Does evidence satisfy intent?]
  V -->|missing fact| R
  V -->|wrong choice| B
  V -->|incomplete plan| P
  V -->|implementation defect| I

1. Research

Collect facts, sources, constraints, existing artifacts, and unknowns. Do not decide while evidence is still missing.

• BA researches customer language and existing canon.
• Architect audits the handoff and maps systems and constraints.
• Developer researches concrete code paths inside the context slice.

Done when: facts cite sources, unknowns are visible, and the next decision is named.

2. Brainstorm

Create real alternatives for a decision. Separate product choices from architecture choices and implementation choices.

• BA grills product intent and proposes requirement slices.
• Architect presents alternatives at divergence points.
• Developer presents implementation options only where the design permits choice.

Done when: alternatives, trade-offs, and the decision owner are explicit.

3. Plan

Turn the chosen direction into bounded, reviewable work.

• BA prepares a coherent WP and readiness checks.
• Architect writes decisions, contracts, budgets, design, features, and context slice.
• Developer writes phases with exact files, verification commands, and done criteria.

Done when: the plan is executable, traceable, inside scope, and explicitly approved where required.

4. Implement

Apply the approved work in small phases. Persist status and stop on a red check or a needed decision change.

• Requirements are changed through versioned BA transactions.
• Architecture decisions are recorded only after human choice.
• Code changes follow the approved Developer plan and TDD where appropriate.

Done when: every phase is complete and its local verification is green.

5. Verify

Try to disprove completion against the original requirements, accepted decisions, and exact commands.

• Developer runs build, tests, lint, and package criteria.
• Quality returns or promotes the change and preserves findings.
• BA accepts delivered evidence into a baseline when the product outcome is satisfied.

Done when: evidence is durable, failures are not hidden as skipped work, and the next state is justified.

How failure routes backward

Failure	Return to	Example
Missing product intent	Research with BA	acceptance behavior is undefined
Unchosen system behavior	Brainstorm with Architect	two services could interpret a field differently
Unexecutable or untraceable work	Plan	phase says “update relevant files”
Red test or implementation defect	Implement and repair	test fails after phase 2
Evidence contradicts a requirement	Earliest owning role	delivered behavior violates the confirmed FR

The handoff tells the receiver what is already decided. The gate tells the receiver whether it is safe to continue.