# Process 4 — immediate delivery

> **What you will learn**
> Why fast deployment reduces risk rather than increasing it, and how the loop
> closes.

## Passing validation means shipping

What passed [automatic validation](/guide/ha-phase3-validation) **can be
deployed without human approval**, because the tests stood in for the judgement.

Feeling uneasy here is natural. "It ships without anyone looking?"

## Why fast deployment is actually safer

Counter-intuitively, **deploying small and often carries less risk.**

```mermaid
graph TD
  A["Big deploy · rarely"] --> A1["100 changes at once"]
  A1 --> A2["A problem, and you don't know which one"]
  A2 --> A3["Roll back and all 100 disappear"]
  B["Small deploy · often"] --> B1["1 change"]
  B1 --> B2["Problem = that 1"]
  B2 --> B3["Rollback scope is also 1"]
```

| | Big deploy | Small deploy |
|---|---|---|
| Tracing the cause | hard | **obvious** |
| Rollback cost | large | small |
| Time to discovery | long | short |

The reason for splitting into [micro-sprints](/guide/ha-micro-sprint) carries
through here. Small work means small deploys.

## Progressive rollout

Even so, you do not switch everything at once.

| Approach | How |
|---|---|
| **Canary** | to a slice of users first (say 5%). Widen if clean |
| **Blue-green** | run the new version alongside and shift traffic. Revert instantly on trouble |

**Either way, the path back exists in advance.** Ship fast, but be able to revert
fast.

## Monitoring becomes the next input

Deploying is not the end.

```
Watched in real time:
  error rate / response time / usage metrics / business metrics
```

The signals from here become **the next cycle's intent.**

```mermaid
graph TD
  D["Deploy"] --> M["Monitor"]
  M --> S["Signal found<br/>'drop-off is high after coupon entry'"]
  S --> I["Next intent<br/>'make the coupon error message clearer'"]
  I --> P1["Capture intent"]
  P1 --> D
```

**The loop closes.** That is what it means to say deployment is not an endpoint
but the next starting point.

## What must exist for this to work

Honestly, this phase has **the most prerequisites.**

```
□ an automatic deployment pipeline
□ fast rollback (minutes)
□ real-time monitoring
□ a structure that supports progressive rollout
□ a sandbox or staging environment
```

**Missing any one of these makes "immediate delivery" dangerous.** An
organisation without this list should adopt processes 1–3 only and leave
deployment on the existing route (human approval).

> You do not have to adopt the whole methodology. **Using only as much as you are
> equipped for** is the safe path.

## Where the human remains

Nowhere in the four phases does "a person writes code" appear. Instead people
are in three places.

1. **Before process 1** — the judgement about what to build
2. **The criterion in process 3** — the eye that checks whether the tests are a
   real pass criterion
3. **Approval of important changes** — the next chapter's
   [guardrails](/guide/ha-guardrails)

---

## Check yourself

**1. Why is deploying small and often safer?**

<details>
<summary>Answer</summary>

**Because tracing causes and rolling back are easier.** With 100 changes at once
you cannot tell which caused the problem, and rolling back loses all 100. With
one change, the problem is that one and so is the rollback scope.
</details>

**2. Why is post-deployment monitoring part of the process?**

<details>
<summary>Answer</summary>

**Because monitoring signals become the next cycle's intent.** "Drop-off is high
after coupon entry" leads to "make the error message clearer," and the loop
closes.
</details>

**3. What should an organisation without the deployment prerequisites do?**

<details>
<summary>Answer</summary>

**Adopt processes 1–3 only and leave deployment on the existing route (human
approval).** You do not have to adopt the whole methodology; using only as much
as you are equipped for is safer.
</details>

---

Finally, the mechanisms that make this speed survivable →
[Guardrails and a pre-adoption checklist](/guide/ha-guardrails)