# Map of the four processes

> **What you will learn**
> What each of the next four chapters covers, and where the familiar
> analysis-design-build-test stages ended up inside them.

That is the concepts — [what still blocks](/guide/ha-agile-limits),
[what changes](/guide/ha-what-changes),
[micro-sprints](/guide/ha-micro-sprint),
[IntentOps](/guide/ha-intentops),
[fluid software](/guide/ha-fluid-software).

Now the actual process. It runs over four chapters; before going in, here is the
whole thing on one page.

## The four processes

```mermaid
graph TD
  P1["Process 1<br/>Capturing intent"] --> P2["Process 2<br/>Agent orchestration"]
  P2 --> P3["Process 3<br/>Automatic validation"]
  P3 --> P4["Process 4<br/>Immediate delivery"]
  P3 -.->|"tests fail"| P2
  P3 -.->|"retry limit — the spec is wrong"| P1
  P4 -.->|"monitoring signal"| P1
```

The three dotted lines are the content of this picture.

- **Process 3 → 2 (self-healing)**: when a test fails, nobody is paged — the
  code is regenerated. This is the loop's normal operation.
- **Process 3 → 1 (going back)**: if several rounds of fixing do not help, it is
  not the code that is wrong but **the spec or the test**. This is where a
  person enters.
- **Process 4 → 1 (the loop closes)**: after release, monitoring signals become
  the intent of the next cycle.

One lap takes **minutes to hours.** Not two weeks.

## What each process answers

| Process | Core question | Output |
|---|---|---|
| 1. Capturing intent | **what are we building** — with no room for interpretation | spec + the tests that decide "done" |
| 2. Orchestration | **how do we build it** | working code |
| 3. Automatic validation | **is it actually done** | a fully passing test run |
| 4. Immediate delivery | **is it actually used** | shipped change + monitoring signals |

## Where did the familiar four stages go?

Analysis → design → build → test. If your organisation has worked in that order,
the diagram above will look foreign. Those stages did not disappear — **they
moved.**

| Familiar stage | Where it went | What changed |
|---|---|---|
| **Analysis** | Process 1 | not a meeting but a PM agent's questions. Not minutes, but **the Q&A itself is the spec** |
| **Design** | the architect inside Process 2 | not a separate stage but **a role running concurrently with build and review** |
| **Build** | the coding agent inside Process 2 | written by an agent, not a person. Code is not an asset but a [derivative](/guide/ha-fluid-software) |
| **Test** | the front (IntentOps) + Process 3 | not the final gate — **decided up front alongside the spec**, then judged automatically at the back |
| (Release) | Process 4 | not an event outside the stages but **inside the loop** |

The middle two are worth a closer look.

### Design did not disappear

[Process 2](/guide/ha-phase2-orchestration) has an architect agent, and the work
of designing system structure and change scope is still there. What is gone is
**the order in which review waits for build to finish.** The three run at the
same time and hand problems back to each other.

And the points where a person steps into design are fixed.

1. **When the design direction diverges from the spec**
2. **Irreversible decisions** — schema changes, external contract changes

However short the cycle gets, those two are looked at by a person.

### Test moved to the front

Traditionally testing was the final gate. Here, [IntentOps](/guide/ha-intentops)
**settles the tests up front together with the spec**, and Process 3 merely runs
them and judges.

There is one reason for the reordering. If a person is not going to decide when
something is done, **the criterion has to exist at the start.**

## What changed is the coordination, not the order

It is easy to read this map as "so it is waterfall, run fast." It is not.

```mermaid
graph TD
  W["Sequential model"] --> W1["build waits for design<br/>review waits for build"]
  H["Process 2"] --> H1["architect · coding · review run<br/>at the same time, handing work back"]
```

As [what changes](/guide/ha-what-changes) put it, what this methodology changes
is not the order or the length of the stages but **who does the coordinating.**
The mapping table above is only a map of where the familiar names landed — the
four processes **must not be read as sequential gates.**

## Where the people are

Nowhere in the four processes is there "a person writes the code." People are in
three places instead.

| Position | What they do |
|---|---|
| **Before** Process 1 | deciding what to build |
| **Inside** Process 2 | design direction, and approving irreversible decisions |
| Process 3's **criteria** | the judgement of whether the tests are a real pass mark |

The third is the one most often dropped. The loop's goal is passing the tests,
so [if the criteria are shallow it will exploit the gaps
precisely](/guide/ha-phase3-validation).

## Do you have to adopt all four?

No. Process 4 (immediate delivery) has the most prerequisites — an automated
deployment pipeline, rollback in minutes, real-time monitoring. Without them,
**use Processes 1-3 and leave delivery on human approval** as before.

## Common misunderstandings

### "So we write no design documents?"

**The spec and the tests** take the document's place. Documents written to
explain things to people shrink; what remains is a spec that people and agents
both read. It is the same point as
[fluid software](/guide/ha-fluid-software) — the asset you protect moves from
code to spec plus tests.

### "We are required to review the output of each stage"

Every process has an output, so the review points can exist. What differs is
**where you attach them.** With cycles running in minutes, attaching a human
review to every cycle brings back exactly the coordination cost you removed.
Attach review to **the spec and the test criteria**, not to individual cycles —
which is the subject of [guardrails](/guide/ha-guardrails).

---

## Check yourself

**1. Where did the familiar "design" stage go?**

<details>
<summary>Answer</summary>

Into **the architect role inside Process 2.** It was not removed; it stopped
being a separate stage and now runs **concurrently** with build and review.
Irreversible decisions (schema, external contracts) are still approved by a
person.
</details>

**2. Why did testing move to the front?**

<details>
<summary>Answer</summary>

**Because a person no longer decides when something is done.** For the judgement
to be automatic, the criterion has to exist at the start, so IntentOps settles
the tests up front alongside the spec.
</details>

**3. If tests keep failing in Process 3, what should you suspect?**

<details>
<summary>Answer</summary>

If several rounds of fixing do not help, it is not the code but **the spec or
the test** that is wrong. That is why the loop has a retry limit and calls a
person when it is exceeded — the Process 3 → 1 dotted line in the diagram.
</details>

---

Now each process one at a time →
[Process 1 — capturing intent](/guide/ha-phase1-intent)