Orders: how work is specified · Saphan Studio documentation

An order is the written specification a stream runs against — the contract between the person who wants the work and the agents who will do it. Orders are documents in your project's command deck, and the discipline around them is where most of the method lives. A complete order carries:

Section	What it settles
Class and observation	What kind of work this is, and the concrete observation that motivated it — a measured defect, a named requirement. Not "improve X"; what happened.
Confinement	What this stream does not touch. Named explicitly, so scope creep is visible as a violation rather than discovered afterwards as a surprise.
Scope	The work itself, broken into named pieces, each with its rationale — and, where a choice between variants exists, the chosen variant stated as a decision.
Owner questions	Decisions the order cannot make alone, named and put to the human before implementation — never resolved silently by the executor.
Collisions	The streams this one could interfere with, and the ordering decision.
Test plan, RED first	For each guarded behaviour: a test that proves it, and the negative control — the mutation that must turn the test red. A test that cannot detect the failure it guards is listed as a defect of the plan.
Definition of Done	Checkable conditions. If the order chose a variant, the DoD includes an assertion that turns red if the rejected variant is delivered — a design decision must be testable, or it is a comment.
Budget	Model tier, quote, and cap — per run, visible before dispatch. Overruns are named events against the quote, not ambient noise.
Assumptions of intent	What the order believes about the world, stated so that a false assumption can be recognized and the order revised — rather than the executor improvising around it.

A compact skeleton:

# ORDER — <stream-slug> (STOP-1)

**Class:** <defect | feature | recon | hardening>
**Repo:** <which repository this touches>
**Observation:** <the measured thing that motivated this — dated, concrete>

## Confinement — what this stream does NOT touch
- <boundary 1>
- <boundary 2>

## Scope
### P1 — <named piece>
<what and why; chosen variant stated as a decision>

## Questions to the owner — required before implementation
**Q1 —** <the decision the order cannot make alone>

## Collisions
- <stream X touches the same surface — this leg goes second>

## Test plan — RED first
| id | proves | negative control |
|---|---|---|
| T1 | <behaviour> | <the mutation that must turn T1 red> |

## Definition of Done
1. T1–Tn green, full tree green.
2. <the variant assertion — red if the rejected variant ships>

## Budget
- model: <tier> · quote: $<n> · cap-usd: <2x the quote> (per run)

## Assumptions of intent
1. <assumption — if false, which part of the order falls>

Recon before repair is a standing habit: when the root cause is not known, the order buys a diagnosis with evidence first — read-only, cheap, gated by the human — and the targeted fix is a separate order afterwards. Ordering the fix before the diagnosis is called what it is — buying a lottery ticket.