PP Gate Funnel v2 - What Each Gate Kills

A feature flows left to right. Each gate filters out a specific class of failure. Failures loop back to upstream phases (red dashed). Post-release outcome metric loops back to Gate 0 evidence (green strip). Gates are delivery-quality controls; they sit alongside continuous discovery, not instead of it.

Customer signalprimary inputMike + Mario surface, but signal must trace to user / problem / evidence
→
Gate 0Problem (proposed)
→
SpecApp Spec, Ticket, AC
→
Gate 1Requirements
→
Build & Testimplementation + test agents
→
Gate 2QA
→
Releasedeploy agent
Customer signal
Customer interviews, telemetry, support tickets, win/loss data. Mike and Mario surface candidates but proposals must trace back to a real customer signal, not founder anecdote.
Gate 0 stops

The Build Trap

  • No identified user
  • No evidence of the problem
  • "Mario thinks we should..." (founder anecdote without external signal)
  • Solution-shaped before problem-shaped
  • Single-source evidence ("Evan said this once")
Passes (ALL required)
  • User named (specific role, not abstract)
  • Problem statement (one line, observable)
  • Evidence from 2+ sources (interviews, telemetry, support tickets - not single anecdote)
Owner: PM · Bypass: explicit Mario sign-off, logged
Spec phase
App Spec, Ticket, and concrete-value AC drafted. PM + tech lead + QA pre-review. Outcome metric defined alongside AC (per artifact-stack v2 Section 8 of every ticket).
Gate 1 stops

Abstract AC & scope drift

  • "Valid phone" / "appropriate response"
  • No in-scope file list
  • Prior-fix-preservation field empty
  • No test design feasibility check
  • Missing non-goals
  • No outcome metric (Section 8 blank)
Passes (ALL required)
  • Concrete values (real phone, real DOB)
  • Scoped files listed
  • AC→test map present
  • Outcome metric defined
Owner: PM + QA co-sign · Bypass: P0 hotfix only, logged
Build & Test
Implementation agent works within the in-scope file list. Test agent writes & runs the AC-derived suite plus regression. QA observes for AC drift and spot-checks AC→agent prompt translation (per swimlane v2).
Gate 2 stops

Test theater & regression

  • Tests written for code, not AC
  • Prior fix regressed
  • Out-of-scope files touched
  • No exploratory pass beyond checklist
  • Severity-blind sign-off (severity model in Constitution)
Passes (ALL required)
  • AC coverage validated by QA
  • No regression to prior fixes
  • Exploratory pass completed
  • Severity-tagged for any deferred bugs
Owner: QA · Bypass: severity P3 + log & ship
Release
Outcome metric instrumented (per ticket Section 8). PM reviews at T+14d. Decision logged: did the metric move? If not, ticket reopens for re-discovery (loops back to Gate 0).
←fails go back to Customer signal (re-validate or defer)
←fails go back to Spec (rewrite AC, scope, or test design)
←fails go back to Build & Test (fix & retest, or escalate)
↺
Outcome loop (Release → Gate 0) At T+14d post-merge, PM reviews each ticket's outcome metric. If the metric moved as predicted, ticket closes. If not, the post-release decision becomes evidence for the next Gate 0 evaluation: was this the right problem? Was the solution wrong? Was the metric wrong? The diagram is a loop, not a one-pass pipeline.

Severity model

P0 = production down, customer impact, all hands stop · P1 = customer-impacting, workaround exists · P2 = customer-impacting, deferrable · P3 = cosmetic, log & ship
Lives in always-loaded Constitution / standing context (per swim-lane meta lane). Required for Gate 2 bypass to be falsifiable.

Cycle-time math

Gate overhead at typical staffing: ~30 min / ticket × ~50 tickets / week = ~25 hrs / week of gate work, split between PM (Gate 0/1) and QA (Gate 1/2).
At scale, batch low-risk tickets and reserve full-gate review for net-new behavior. Tune frequency from real catch-rate data, not guesswork.
Bypass policy (proposed) Every gate has an explicit, logged escape hatch. Gate 0 bypasses on Mario sign-off (founder override on strategic bets without ground-truth). Gate 1 bypasses on P0 hotfix (production down, customer impact > spec discipline). Gate 2 bypasses on severity P3 + ship-and-log (cosmetic / non-blocking). Every bypass writes an `audit_log` row.
Review owner: PM (Aaron) reviews bypass log weekly at Friday standup. Flagged bypasses (P0 hotfix patterns repeating, founder-override frequency increasing) escalated to Mario at the same standup. Gate fatigue is a real failure mode - the alternative to a bypass policy isn't "no bypasses," it's silent ones.

Where these gates sit relative to continuous discovery

Continuous discovery is the right shape for deciding what to build - customer interviews, opportunity-trees, assumption testing, weekly cadence. These gates are a separate discipline: they target whether what we built was built right, which is a delivery-quality concern. They sit alongside continuous discovery, not instead of it. The agentic team needs both: outcome-grounded discovery upstream (feeding Gate 0 evidence) plus concrete-AC delivery checks downstream (Gate 1 + Gate 2). Adopting the gates without the discovery practice produces fast shipping of unvalidated features. Adopting the discovery without the gates produces validated ideas built unreliably. Both, or neither.

Source: Mario's SDLC Process Audit (March 2026) for Gate 1 + Gate 2. Gate 0, bypass policy, evidence-quality threshold, customer-signal foregrounding, and outcome loop are Aaron's proposed expansions, sourced from `research/2026-05-05-sdlc-critique-personas.md` and the May 7 multi-persona critique pass.
Failure-class language tied to Ben's May 6 diagnosis of the v1 platform: requirements unclear up front, tests covered code not business cases, no QA function.
Agent-fleet roles shown by function (implementation, test, deploy). Specific agent names within the Hermes framework pending confirmation with Mario.