flight plans

Flight Plans

The Flight Plan is the only artifact the operator ever writes or approves. Everything downstream — Kanban cards, dependencies, budgets, verification — is generated from this page.

The template

---
title: "Flight Plan"
status: draft # draft → ready → launched → complete
priority: normal
budget:
  tokens: 50000
  time: "30m"
---

# Flight Plan: [MISSION NAME]

## Sizing Check (Informational)
Is this a Mission or a Task?

## Commander's Intent
What must be true, and why does it matter?

## Constraints
- Budget: [tokens / time / turns]
- Pause conditions: [what stops the line]
- Human gates: [where the operator must approve]

## Success Criteria
1. [Outcome-oriented: what result proves this succeeded?]
2. [Outcome-oriented: what else must be true?]

## Context
[Any relevant links, notes, or references]

Sections Explained

Sizing Check

Every Flight Plan must answer why this is a Mission and not a Task. If the answer is “because it sounded important” or “it involves multiple steps,” it is a task. A task with steps is still a task. A mission involves uncertainty at the method level that requires delegation of judgment, not just delegation of labor.

Commander's Intent

Two to four sentences. What must be true, and why it matters. No method, no step list. If you find yourself writing “first… then… finally…”, you are writing tasks. Delete it and state the outcome instead.

Constraints

Budget (propose defaults scaled to the work), pause conditions (what stops the line), and human gates (where the operator must approve before work proceeds). When in doubt, gate it. The operator can remove gates faster than they can undo a bad merge.

Success Criteria

Three to six, each outcome-oriented and verifiable. A judge, a test, or a human reviewing the artifact can answer yes or no. Vague criteria here means a blind judge downstream. This is the highest-leverage section of the page.

Context

Links to Substrate references, operator notes, or anything the crew needs to understand the terrain.