DECISION: [ADR-004] Build-Fly-Learn Over Waterfall
DATE: 2026-02-18
TYPE: 1 (irreversible)
STATUS: Accepted
SOLITON SCORE: 0.88

## Context

Orxaq's prior attempt (v0.1-v0.43) was the "Fly" phase — code was written
rapidly without compliance infrastructure, ADRs, or structured testing.
This bootstrap is the "Build" phase that incorporates the "Learn" from that
prior experience.

The bootstrapping problem: you cannot design a causal inference system
perfectly upfront because the system's own design decisions form a causal
graph that you only understand through building it.

## Options Considered

### Option A: Waterfall (Full Design → Full Build → Full Test)
Pros: Complete design upfront, clear phase gates.
Cons: Bootstrapping problem unsolvable by design alone; prior attempt proved
this — 43 sprints of code with no compliance trail.

### Option B: Pure Agile (No Upfront Design)
Pros: Maximum velocity, minimal ceremony.
Cons: No compliance trail, no examiner auditability, regulatory risk.

### Option C: Build-Fly-Learn Cycles (selected)
Pros: Each cycle produces working code + measured results + documented
learnings. Compliance infrastructure committed before code (Build), code
exercised immediately (Fly), results feed back into next cycle (Learn).
Cons: Requires discipline to maintain cycle cadence.

## Decision

Adopt Build-Fly-Learn cycles where:
- **Build**: Compliance infrastructure first (ADRs, tests, CI)
- **Fly**: Working code that exercises the infrastructure
- **Learn**: Metrics collected, ADRs updated, next cycle planned

## Rationale

The prior 43 sprints proved that "Fly" without "Build" creates technical
debt that compounds until the system is unmaintainable. This bootstrap
inverts the order: compliance first, code second.

## Consequences

**Easier:** Every examiner question has a documented answer from day one.
**Harder:** Initial velocity appears slower (compliance overhead up front).
