A blank OPERATION-MAP.md is intimidating; a guided starter isn't. Copy the template below, answer each line in plain words, and timebox the whole thing to 30 minutes. A rough map you finish beats a perfect one you postpone — the bottleneck notes (84.2) and contract (84.3) sharpen it later.

How to use this starter

Pick one repeatable workflow — publishing a lesson, handling a booking, answering a class of support tickets. Walk the trigger → inputs → work → review/decision → output → record → improvement chain from Lesson 84.1. If a line is hard to answer, that gap is your first finding, not a reason to stop.

Template

# OPERATION-MAP.md — [Workflow name]

## Trigger (what starts it)
- Event or schedule: ___ (e.g. "source collection marked complete," "new inquiry form," "Mondays 08:00")

## Owner (one name + backup)
- Owner: ___ / Backup: ___ / Bus factor today: ___

## Tools (where it runs)
- Runs where: ___ (platform links or repo path) / Records live in: ___

## Inputs (approved in, nothing else)
- Needs to start: ___ / Source/quality bar: ___ / Rejected inputs go to: ___

## Work (steps with green/amber/red)
1. ___ (green — safe to automate)
2. ___ (amber — AI prepares, human approves)
3. ___ (red — human owns; see HUMAN-OWNERSHIP 89.4)

## Review / decision (the gate)
- Gate: ___ checked by ___ within ___ / Reject returns to ___ with ___

## Output (observable result)
- Customer receives: ___ / Internal record: ___ / Healthy looks like: ___

## Failure point (where it breaks today)
- Most likely break: ___ / Lands in: ___ (queue location + reviewer)

## Success signal (one metric)
- ___ (e.g. "draft in folder by 09:00," "first reply < 4h") — baseline: ___

## Next constraint (one line, from 84.2)
- ___ — first improvement candidate, not a tool purchase.

Worked example (ByeBuy lesson workflow)

Trigger: outline approved. Owner: editor + illustrator backup. Inputs: research packet with dated sources. Work: draft (amber) → artwork (amber) → editorial review (red gate). Output: published lesson + changelog entry. Failure point: artwork review waits — lands with the editor, SLA 3 days. Success signal: publish on schedule with zero post-publish corrections. Next constraint: reviewer capacity, not drafting speed — so automation effort goes to review prep, not more drafts.

Finish by dating the map and scheduling its first bottleneck read (BOTTLENECK-NOTES.md, five observations). Revisit monthly or whenever the failure point moves.

Common mistakes (and fixes)

Mapping the wish, not the work. Writing how the workflow *should* run instead of following five real jobs (84.2). Fix: shadow real runs first — note waits, questions, and corrections, then map what actually happens. The map documents reality; improvement changes it.

No named owner. "The team owns it" means nobody does. Fix: one owner plus one backup, both named, bus factor stated honestly. If the factor is one, say so — that's the finding that justifies the runbook (89.3).

Skipping the failure point. Every map needs one — the step that breaks today and where the break lands. A map with no failure point hasn't been tested. Name the queue, the reviewer, and the SLA; link the contract (84-B) once written.