Launchable is not operable. Part XVI taught the difference: a live project needs an owner, a support route, quality checks, cost guardrails, a failure plan, and a review that turns operations into learning. This lesson builds the smallest viable version of that system — light enough to run weekly, serious enough to catch real harm.

The vocabulary of staying alive

• Operations playbook — the one document saying how the system runs week to week.
• Support boundary — what you help with, where, how fast — and what is out of scope.
• Quality sample — the small, regular human check on real outputs (e.g., every 10th brief source-checked).
• Alert — the signal that pages a human: error spike, cost spike, quality failure, abuse.
• Cost cap — the number that pauses work before the bill surprises you.
• Runbook — the step-by-step for a named failure: what to check, what to do, who decides.
• Owner — the single person accountable for each risk. Shared ownership is no ownership.
• Weekly review — the dated meeting where evidence, costs, support, and risks become decisions.

The smallest viable operating system answers six questions in one page: what runs; where it runs; how it is observed; who responds; what gets paused; how the project learns. If any answer is "we will notice," it is not a system yet.

For the running examples the answers stay deliberately small. Sonariq: one scheduled fetch, one workspace host, logs in one place, the founder reviews every 10th brief, cost alerts at 2× pilot average, publishing pauses on any source-check failure. The launcher: form host plus calendar integration, SMS log plus review queue, owner confirms slots within four hours, pause bookings when the queue exceeds six. The Classroom: static host, lesson feedback inbox, monthly link-and-fact recheck, rollback is a git revert.

Costs, quality, and the stop button

Three controls carry disproportionate weight for AI projects.

First, cost guardrails. Model, tool, and hosting spend scale with use — including misuse. Set per-run budgets, daily caps with alerts, and a hard pause. Log spend per output from day one so Lesson 90.7's cost signal is real data, not an estimate. Know the kill order: which automation pauses first when the cap trips.

Second, quality sampling. No team reviews everything forever, and no AI project should publish everything unchecked. Define the sample (rate + method), the bar (e.g., every claim linked, every slot confirmed by human), and the consequence (pause the step that produced the failure). Record results in the decision log.

Third, the emergency stop. Every automation with external effects needs a named control, owner, and tested path: pause the scheduler, revoke the key, revert to the last good deploy, message affected users. Write the runbook before the incident. Test the stop the way Lesson 90.6 tests rollback — tired, at midnight, on paper first.

Support closes the loop: one inbox or queue, one promised response time, one owner, one boundary ("we help with brief accuracy and access; we do not give investment advice"). Every support thread is evidence for Lesson 90.7 — file the quote, count the category, change one thing.

Exercise: create OPERATIONS-PLAYBOOK.md

Create FINAL-PROJECT/OPERATIONS-PLAYBOOK.md:

# OPERATIONS-PLAYBOOK — [Project], [date]

## What runs / where (5 lines max)
- [component — host — owner]

## Observed how (logs + alerts)
- Logs live at: … / Reviewed: …
- Alerts: [condition → who → how]

## Support (boundary + ownership)
- Channel + response promise: …
- Owner: … / Out of scope: …

## Quality sample
- [rate + method + bar + consequence of failure]

## Top risks + runbooks (3 max)
1. [risk — likelihood/impact — runbook steps — owner]
2. …
3. …

## Cost thresholds
- Per-run budget: … / Daily alert at: … / Hard pause at: …
- Pause order: …

## Emergency stop
- [control — owner — what pausing preserves — user message]

## Weekly review agenda (30 min)
1. Evidence (90.7 decisions due) 2. Quality sample 3. Support themes
4. Costs vs caps 5. Risks + logs 6. One change for next week

Finish line: a project understandable after launch — what runs, where, how observed, who responds, what pauses, how it learns — all on pages a tired owner can follow.

Verify: simulate one failure per risk. Walk the runbook step by step without improvising. If a step says "check logs" without a location, or "contact owner" without a name, the playbook fails the simulation. Fix the line, re-run.

Common failure mode: the monitoring mirage — dashboards nobody reads, alerts routed to an unowned inbox. One log location, one reviewer, one alert path per risk. Its mirror is the hero operator: everything lives in one person's head. If the owner is unreachable, the playbook must still work. Write it for the substitute.

The weekly review that earns its thirty minutes

Run the agenda in order and timebox each item: evidence decisions first, because learning outranks reporting; quality sample second, because trust outranks growth; support themes third, because user words diagnose faster than metrics; costs fourth, because caps are vetoes; risks and logs fifth; one change for next week last. End with the decision written in the log with owner and date. Skip any section lacking fresh data rather than performing it — an honest skip exposes missing instrumentation, which becomes next week one change. Over two months these thirty-minute sessions produce the operations history no dashboard can fabricate.

Check your understanding

1. Why does a quality sample need a pre-written consequence, not just a score? 2. What three numbers make a cost guardrail real, and what happens at each? 3. How does support evidence feed the learning loop from Lesson 90.7?

Next

The system runs and learns. Lesson 90.10 turns it into a narrative a collaborator, customer, or advisor can challenge — the final project review and the single next decision.