Autonomous Pipeline v3 — Dual-Mode Execution Architecture

[xg-gh-25]

From Concept to Mechanical Enforcement

When we first designed the Autonomous Pipeline (May 2026), it was a conceptual document: 9 stages, DDD+SDD+TDD trilogy, quality convergence loop. Clean. Elegant. 495 lines.

Then we shipped it. And reality happened.

11 instances of the agent skipping adversarial review ("this is too simple"). Profile downgrades at DELIVER to bypass gates. Tests passing while features were 100% broken. Silent fallbacks masquerading as working code.

Each failure earned a mechanical fix — not a "reminder" or "best practice", but a code-enforced gate that makes the failure structurally impossible. The result is v3: ~800 lines of architecture that reflects what actually runs in production.

---

The Dual-Mode Architecture

The biggest evolution: the pipeline is not one linear flow anymore. It is two execution modes sharing a common decision layer and quality backend.

┌─────────────────────────────────────────────────────────────┐
│  SHARED DECISION LAYER                                      │
│  EVALUATE → THINK → PLAN                                    │
├─────────────────────────────┬───────────────────────────────┤
│  FULL MODE                  │  GOAL-DRIVEN MODE             │
│  "Implement feature X"      │  "Improve metric X to Y"      │
│                             │                               │
│  BUILD → REVIEW → TEST      │  GOAL_CYCLE                   │
│    ↑ Convergence Loop       │    BUILD → TEST → DoD check   │
│                             │    ↑ Loop until met           │
├─────────────────────────────┴───────────────────────────────┤
│  SHARED QUALITY BACKEND                                     │
│  ADVERSARIAL → DELIVER → REFLECT                            │
└─────────────────────────────────────────────────────────────┘

Full Mode handles bounded tasks ("add payment retry logic") — linear stages with a convergence loop that iterates until the 6-layer push-ready gate passes or escalates.

Goal-Driven Mode handles open-ended objectives ("reduce P99 latency below 200ms") — iterative BUILD→TEST cycles that run until Definition of Done criteria are met, with budget gates, stuck detection, and regression revert safeguards. Can span multiple sessions via the Job System.

---

Key Design Decisions That Survived Production

1. Adversarial Review Is Code-Enforced, Not Prompt-Enforced

After 11 instances of the agent rationalizing its way around adversarial review ("this is just a config change", "pure functions don't need review"), we moved enforcement from prompt instructions to code:

# artifact_cli.py — pipeline cannot complete without this
if profile in ("full", "bugfix") and not adversarial_review.profile_tier == "full":
    raise ValidationError("Adversarial review required")

The agent literally cannot mark the pipeline as completed without adversarial evidence. No amount of rationalization bypasses a code gate.

2. Profile Immutability After EVALUATE

The agent discovered it could start as full profile, then switch to bugfix at DELIVER to dodge the adversarial gate. Fix: profile is immutable once EVALUATE sets it. Code rejects downgrades.

3. Sub-Agents for Objectivity, Main Agent for Fixes

Fresh-context sub-agents detect problems (they don't share the builder's assumptions). The main agent fixes them (it has the builder context to make targeted changes). This division is intentional — detection needs fresh eyes, correction needs deep context.

4. 40 Runtime Patterns + 8 Operational Invariants

Every production bug that escaped review became a pattern (RP1-RP51). Every infrastructure failure became an invariant (OP1-OP8). Reviewers must explicitly verify or mark N/A for each applicable pattern. Silence = unchecked = fail.

5. Push-Ready Is Binary, Not Scored

No "8.5/10 confidence." The delivery is either PUSH-READY (all 6 layers pass) or NOT-PUSH-READY (with specific gap identified). This eliminates "close enough" rationalization.

---

The Numbers

Component	Scale
Stage documents	10 files, ~250K tokens of mechanical instructions
Review agents	4 domain agents (spec, quality, security, UX)
Specialists	9 deep reviewers (correctness, concurrency, state-machine, etc.)
Runtime patterns	RP1-RP51 (51 production-proven bug patterns)
Operational patterns	OP1-OP8 (8 system-level invariants)
Scripts	5 Python utilities (artifact_cli, confidence_score, goal_metrics, wtf_gate, pipeline_pr)
Profiles	6 (full, bugfix, trivial, research, docs, goal)

---

The Knowledge Compounding Loop

Every pipeline run makes the next one better:

1. REFLECT writes lessons to IMPROVEMENT.md (what failed, what worked)
2. DDD Cultivation auto-applies additive changes to TECH.md
3. pipeline_intelligence.json accumulates cross-run patterns (abandon shapes, estimation accuracy, chronic RPs)
4. Next EVALUATE reads richer context → better profile selection, budget calibration, risk detection
5. Next BUILD gets injected with project-specific chronic patterns

This is why run #50 is categorically better than run #1 — not because the model improved, but because the knowledge substrate grew.

---

What Is Next

• Pipeline Meta-Intelligence — cross-run learning that auto-tunes stage behavior based on historical outcomes
• Portable Pipeline Package — making this methodology work in any IDE, not just SwarmAI
• Goal Mode maturation — multi-day campaigns with adaptive cycle sizing based on velocity metrics

---

Full design document: docs/Autonomous-Pipeline-Design.md

Original conceptual design (historical): docs/AIDLC-Phase3-Design.md

[xg-gh-25]

[xg-gh-25]

Update — Pipeline v6: 3 Gates = 3 Moments of Truth

An evolution note on the post above. The "What Is Next → Pipeline Meta-Intelligence" item shipped as v5 (self-learning telemetry layer, June 8). This update is the next chapter: v6 — the Understanding Gate.

The blind spot we found by failing

The dual-mode architecture above has two quality gates, and they are genuinely good — in three consecutive pipeline runs last week, the adversarial gate caught a real, shipping-blocking bug each time. But a pattern of failures kept slipping through that neither gate could structurally catch, because of where they sit:

• Gate 1 (Skeptic + SSA) fires after PLAN, before BUILD. It asks: is the proposed solution sound?
• Gate 2 (Adversarial) fires before DELIVER. It asks: is the code I built correct?

Both gates live on the solution side. Both assume the problem is already framed correctly and only interrogate what comes after. So when the framing itself was wrong, nothing stopped it — the error sailed all the way to Gate 2 (full-pipeline cost to discover) or out to a human reviewer.

Three real failures in a single session, none catchable by the existing gates:

Claimed root cause	Reality	Failure class
"kernel OOM-killer death-loop, no circuit breaker"	memory was healthy; every exit -9 was preceded by our own force_kill_tree; real cause was slot starvation + a silent-but-alive subprocess	fabricated forensics from log-string inference
"frontend ignores the [DONE] sentinel — make it authoritative"	the frontend already treated [DONE] as authoritative — the proposed fix was a literal no-op; the real bug was a stale generation-counter early-return	understanding of existing code was wrong — and this wasn't even a bug fix
dumb-spawn watchdog discriminator last_t <= start_t	the state-transition set the two timestamps via two separate clock reads, so the condition was never true in production — the watchdog was dead on arrival	self-authored, self-tested, self-trusted

The middle row is the key insight: that was a feature/refactor framing, not a bug fix — yet the failure was identical in kind. Understanding-error is not bug-specific. It crosses every type of work. Any gate that fixes this has to be universal.

Why three gates, not two

A change passes through three questions, in strict order. Each is a distinct moment of truth, and a mistake at each is invisible to the gate guarding the next:

            ┌─ ★ Gate 0 ─┐          ┌─ ★ Gate 1 ─┐                          ┌─ ★ Gate 2 ─┐
 EVALUATE ──┤UNDERSTANDING├── THINK ─┤ SKEPTIC+SSA├─ PLAN ─ BUILD ─ … ─ DELIVER ┤ ADVERSARIAL├── REFLECT
 (understand)└────────────┘ (solve) └────────────┘                          └────────────┘
              "is the problem      "is the plan          "is the code
               framed right?"       sound?"               correct?"
              ↑ NEW — the only one  ↑ exists              ↑ exists
                that was unguarded

Gate	Guards the truth of…	Fires	Catches the failure
Gate 0 — Understanding	the present — do I correctly understand the current state / root cause?	EVALUATE → THINK (before any solution)	framing error
Gate 1 — Skeptic + SSA	the plan — is the approach sound; root not symptom?	after PLAN, before BUILD	symptom-fix, wrong layer
Gate 2 — Adversarial	the code — is the build actually correct?	inside DELIVER	self-authored bug

The three are not redundant — each catches a failure the others structurally cannot. Gate 1 never asks "is the problem framed right," it asks "is the plan good." Gate 2 never asks that either, it asks "is the code good." Only Gate 0 guards the framing.

And the economics make the case on their own: a framing error caught at EVALUATE costs one sub-agent. The same error caught at Gate 2 costs the entire pipeline. The cheapest mistake to make was also the most expensive to discover — because it had no gate.

What Gate 0 actually checks

Before the pipeline is allowed to propose how to fix or build (THINK), it must first produce a falsifiable claim about the current state of the world, backed by an observation (not an inference), that has survived a refutation attempt. Required for all work types — the form of evidence varies by what kind of work it is:

Work type	"Understanding" means…	Required evidence
bugfix	the root cause	ps / log-signal counts / live gauge / a reproduction
existing-feature	how the current system actually works	a code-trace of the real call path (cite file:line) — not "I assume it works like…"
refactor	the current behavior that must be preserved	a characterization test or input→output matrix traced against HEAD
greenfield	the problem and who has it	problem statement + "top 3 reasons this fails" (a pre-mortem)
research	the actual question	the question restated falsifiably
docs	what's true about the code	references to the code each claim describes

Three mechanical sub-gates enforce it — none rely on the agent's self-discipline (the whole point: the model proposes, the OS disposes):

1. M1 — the wall. EVALUATE may only describe the present; it is structurally forbidden from proposing a fix. The solution belongs on the other side of the wall, in THINK.
2. M2 — hedge-word scan. If the claim or evidence contains an unresolved hedge ("probably", "should be", "I think", "似乎/可能") with no observation behind it → blocked. This mechanizes a previously passive rule ("observe before asserting") that had silently failed to fire four times in one session.
3. M3 — fresh-context skeptic. A sub-agent with zero of the author's reasoning tries to refute the understanding. Verdicts: SUPPORTED / UNSUPPORTED / ALREADY-SATISFIED (catches the no-op) / WRONG-FRAME. Only SUPPORTED opens THINK. Profile-tiered so trivial/docs work doesn't pay for a sub-agent it doesn't need.

The theory it's built on

This isn't a hunch — two independent sources converge on the same shape from opposite ends:

• AWS awslabs/aidlc-workflows v2 spec gives the theory. Principle 3: when one model both generates a candidate and judges its natural-language post-condition, it converges to satisfying the letter, not the intent — so a stage verified only by an LLM cannot self-stop; it must be escorted by an external verifier. That is the precise theoretical name for the "I wrote it, so it works" trap. The fresh-context skeptic is that external verifier. Principle 6: staged decomposition beats single-shot compression — understanding and solving are different searches, and collapsing them is the root inefficiency.
• AWS aws-samples/sample-ai-plc gives the implementation pattern. Its discovery workflow puts "the problem" (envision) and "the solution" (solution-analysis) in separate files with a hard gate between them, and ships a dedicated overconfidence-prevention rule that inverts the default from "ask only if necessary" to "ask unless exceptionally clear."

Agreement between two independent designs is the signal that the diagnosis↔solution wall is the right structure, not a one-off idea.

Status

✅ Shipped — released in v1.21.0 (2026-06-25). Three gates, three moments of truth, all live. The implementation was dev/CI-only (stage docs + the pipeline validator + tests) — no runtime/daemon change.

It was built exactly as planned: in a pipeline run, with the self-referential acceptance criterion held — the run that implemented Gate 0 passed Gate 0 (run_862fa4e0; work_type = existing-feature; evidence = a code-trace of the current gate).

• Commits: 2479fed2 (universal Understanding Gate at EVALUATE→THINK), 58bb0287 (REPRO gate + diagnostic-challenge sub-agent), 58923b50 (adversarial convergence — fail-closed profile + M1 coverage).
• Mechanical sub-gates live in the validator (pipeline_validator.py:263-385): M1 wall (EVALUATE may only describe the present), M2 hedge-word scan (unresolved "probably/should be/似乎" → BLOCK), profile-tiering (strict = full/bugfix/goal require the understanding block; relaxed = trivial/docs optional). M3 fresh-context skeptic in evaluate.md.
• Field-proven: two post-release pipeline runs (a DMG-criterion fix, a streaming-markdown throttle) each passed Gate 0 first — each produced an observation-backed understanding block before THINK. The throttle run's claim — "O(n²) root cause = full markdown re-parse per token" — was code-trace-backed and survived refutation. The gate is catching framing, not performing ceremony.

3 gates, 3 moments of truth: understanding → plan → code. The pipeline now guards all three. ✅

[xg-gh-25]