# Preflight

A risk check that runs before any high-stakes action, whether a person or an
assistant is about to take it. The output gate protects what you say. This
protects what you do.

The shape is the same as the gate: a trigger the actor can observe, and a
fixed list that must pass before the action happens. The difference is that
a bad sentence can be retracted and a bad publish cannot.

---

## Trigger

Run preflight before any action that is one or more of:

| Property | Examples |
| --- | --- |
| **Irreversible** | Deleting, overwriting without a backup, force-pushing, sending |
| **Outward-facing** | Publishing to a site or wiki, posting a status, emailing a group, opening a pull request others will read |
| **Cross-file** | An edit that touches many files at once, a rename, a search-and-replace |
| **Asserting a fact** | Reporting a status, a number, a date, or a completion to someone who will act on it |

If none apply, skip preflight. The list has to stay reserved for actions
that earn it, or it becomes noise and stops being run.

---

## The checklist

Every item is pass or fail. The action does not proceed until every line
passes.

- [ ] **Target verified.** The thing I am about to change is the thing I
      think it is. I looked at it (read the file, ran the query, opened the
      page) in this session, not from memory.
- [ ] **State matches description.** What I found matches how it was
      described to me. If it does not, I stop and report the difference
      instead of proceeding.
- [ ] **Backup exists.** A copy of the current state is saved somewhere I can
      restore from, or the change is under version control with a clean
      working tree.
- [ ] **Blast radius named.** I can say in one sentence what else changes if
      this goes wrong: which files, which readers, which downstream job.
- [ ] **Markers preserved.** If the target carries someone else's edits,
      comments, or annotations, my change keeps them. A publish that wipes a
      reviewer's inline notes is a failed publish.
- [ ] **Facts sourced.** Any status, number, or date in what I am about to
      send traces to a source I opened. Nothing inferred from a timestamp,
      nothing assumed from a filename.
- [ ] **Dry run done, where one exists.** Build before deploy, preview before
      publish, diff before commit, print before send.
- [ ] **Authorization current.** I was told to do this, for this target, in
      this context. Approval for an earlier action does not carry forward.

---

## After the action

Preflight has a second half that most versions skip:

- [ ] **Verified live.** I checked the result where it landed (the page
      loads, the row exists, the message is in the sent folder), not just
      that the command returned.
- [ ] **Recorded.** One line in the session log: what changed, where, and how
      to reverse it.

---

## Why a list and not judgment

Judgment is what you use to decide whether an action is high-stakes. Once
it is, judgment is the wrong tool for the checks themselves, because the
moments that need the checks most are the moments you are most confident.
The list does not get confident.

Adapt the items, keep the shape: observable trigger, binary checks, run
before the action. And keep it short. A preflight that takes longer than
the action gets skipped, and a skipped preflight is worse than none,
because everyone believes it ran.