# The Safety-at-Scale Checklist

*Run this before you build a system, and again before you trust it with real work. A minute now saves
a bad afternoon later. A bigger system fails in bigger ways — see it, gate it, cap it.*

## Scope every specialist (least privilege)
- [ ] **Least privilege, per specialist.** Each specialist has the smallest set of tools its job needs — read-only wherever it can be, never "just in case." *The access I grant a specialist is the blast radius I accept for it.*
- [ ] **Every specialist has a defined job.** No part is a vague catch-all; each has a clear job, its inputs, its output, and its handoff to the next.
- [ ] **The smallest system that meets the goal.** No specialist, stage, or step is here that the goal doesn't require. Over-engineering is the trap; restraint is the skill. If one tool would do, I built one tool.

## Keep a human at the risky joints
- [ ] **There's a checkpoint at every joint that acts on the world** — sending, posting, changing a record, moving money or files. Prepare by machine; commit by hand.
- [ ] **I'm in a mode that asks before acting**, not one that runs without me.
- [ ] **I sent or showed it to myself first** on anything with an outward effect, and watched it behave before letting it act for real.

## Make it reliable (add a verification stage)
- [ ] **There's a verification stage.** A separate specialist cross-checks the work against the source or the requirements before I trust it — because nothing checks the output automatically.
- [ ] **I've tested the whole system end to end**, watched, before letting it run on real work.
- [ ] **I know how partial work is reported.** If a specialist is cut off (a rate limit, an overload), it reports the partial work it managed rather than failing silently — there's no automatic retry, so I re-run that stage deliberately.

## Make it observable
- [ ] **I can see what each specialist did and what it cost** for any run (`/usage`, `/workflows`, the agent view, saved transcripts). A system I can't observe is one I can only hope about.

## Cap the cost
- [ ] **I've accounted for the cost of coordination.** Running many specialists — especially in parallel, or as an experimental team — multiplies token use (agent teams run roughly several times a single session). I've set a monthly limit.
- [ ] **I've picked cheaper models where a specialist doesn't need the strongest one.** (Prices and limits change — I check claude.com/pricing.)

## Keep a kill switch
- [ ] **I know how to stop the whole system fast** — every part of it, at once — and I've confirmed I can. Knowing I can stop everything is what makes it safe to run anything.

## Know the limits (and when to get a human engineer)
- [ ] **This job belongs to a supervised system.** It doesn't need an SLA, audit logs, automatic retries, guaranteed uptime, or long unattended overnight runs. If it does, I bring in a human engineer — that's beyond a no-code system.
- [ ] **Nothing runs my whole practice or business unattended.** That's optional Book 5 territory and an engineer's harness — not something to bolt on here.

## What never to build casually
- [ ] Nothing that **moves money** runs without me at the joint.
- [ ] Nothing **sends irreversibly on my behalf at scale** without a human checkpoint.
- [ ] My **most confidential records** aren't reachable by a specialist that doesn't strictly need them.
- [ ] No system is trusted with real work **before it's been verified and observed** at least once.

## If a system misbehaves
- [ ] I **pause the whole system first**, before anything else goes out.
- [ ] I ask "**which stage?**" — I read each stage's output in order and find the first one that's off, rather than fixing the whole system.
- [ ] I **fix that stage and tighten the check after it**, then re-run from there.
- [ ] If a fix gets tangled, I **restore my last save point** — no drama.

> The golden rule: **you keep your hand on the switch.** Nothing runs, and nothing acts on the world,
> without a checkpoint where you get to approve it. When in doubt, scope tighter, verify before you
> trust, keep the system small — and know when to call an engineer.