# Guardrails and a pre-adoption checklist

> **What you will learn**
> Three guardrails and where each one goes, plus a self-check before adopting.

## Raise the speed and you also raise the speed of being wrong

Guardrails are not brakes.

> **They do not slow you down; they are the conditions that make the speed
> survivable.**

Three of them.

---

## Guardrail 1 — human in the loop

### What it is

**Changes to important business logic go through explicit human approval.**

### Where it goes

This is the core of the design.

```mermaid
graph TD
  A["A change"] --> B{"Reversible?"}
  B -->|"yes"| C["Proceed automatically"]
  B -->|"no"| D["Human approval"]
```

Where approval lands in practice:

| Area | Example |
|---|---|
| Paths where money moves | payment, settlement, refunds, pricing |
| Permissions and access control | role changes, granting access |
| Data leaving the building | personal data, external APIs, sending email |
| Hard-to-reverse changes | schema migrations, data deletion |

### Not too much, not too little

| | Result |
|---|---|
| Too much approval | coordination cost returns → **back to agile** |
| Too little approval | logic nobody reviewed reaches production |

Using **is it reversible** as the criterion generally lands in the right place.

---

## Guardrail 2 — controlling hallucination

### What it is

AI [is wrong plausibly](/guide/ai-hallucination). Code can compile and pass
review and still differ from the intent.

**What stops this is not review but a deterministic test suite.**

### What you need

| Item | Why |
|---|---|
| **Unit, integration, and E2E together** | one layer cannot distinguish passing from correct |
| **A sandbox environment** | isolates problem code before it reaches production |
| **Treating tests as the specification** | fit them to the code and the defence line is gone |

> This is the **only condition** under which
> [code as a consumable](/guide/ha-fluid-software) holds. With weak tests,
> regeneration is a gamble rather than an improvement.

---

## Guardrail 3 — cost management

### What it is

Agents running without rest means **spending tokens without rest.** Attach the
most expensive model to every task and cost escapes control.

### Model routing

Match the model to the difficulty of the task.

| Task | Model |
|---|---|
| Format conversion, simple classification, repetitive edits | a light model |
| Design, hard diagnosis, complex judgement | a strong model |

The shorter the cycle, the more often this choice occurs, so **the effect
compounds.**

### Other controls

```
□ maximum retries in the self-healing loop
□ a cost ceiling per task
□ usage monitoring and alerts
```

That is the data you see on
[Connect's usage screen](/guide/cn-usage). Look at the **distribution**, not the
total.

---

## Pre-adoption self-check

What an organisation needs before introducing the methodology. **If any of these
is empty, filling it first is faster.**

| Check | Why it is needed | Without it |
|---|---|---|
| Is test automation trustworthy | the criterion for process 3 | **nothing works** |
| Is deployment automated | process 4 | adopt 1–3 only |
| Is rollback fast | you must revert as fast as you ship | slow the deploy cadence |
| Is monitoring real-time | the input for the next cycle | the loop does not close |
| Are approval points agreed | decide after the fact and you decide after an incident | agree first |

**The first row is an absolute requirement.** Partial adoption is possible
without the others, but without tests this methodology is only dangerous.

## Which organisations it suits

**Good fit**

- Where customer needs change quickly
- Where release speed is a competitive factor
- Where testing and monitoring are already mature
- Where technical governance is established

**Not recommended**

- **Organisations with no testing culture** — you end up fast with nobody able to
  judge quality
- Areas where regulation legally requires human review of every change
- Environments where deployment is locked to a quarterly cadence (fix that
  first)

---

## Check yourself

**1. What one-line criterion decides where approval goes?**

<details>
<summary>Answer</summary>

**Is it reversible.** Too much approval brings coordination cost back and returns
you to agile; too little sends unreviewed logic to production.
</details>

**2. What is the only condition under which "code is a consumable" holds?**

<details>
<summary>Answer</summary>

**Dense tests.** Tests are the only thing guaranteeing that regenerated code
preserves the old behaviour, so with weak tests regeneration is a gamble.
</details>

**3. What is the one absolute requirement in the pre-adoption check?**

<details>
<summary>Answer</summary>

**Trustworthy test automation.** Partial adoption is possible without the other
items, but without tests the methodology only raises speed while leaving nobody
able to judge quality.
</details>

---

**That completes the AI Transformation track.** Now we look at how these concepts
are implemented in the actual products →
[HyperTeams on your machine](/guide/ht-what-is-it) ·
[A tour of Connect](/guide/cn-what-is-it)