Everything converges here: the person and job, the map, the memory, the boundaries, the release, the route, the evidence, the operations — told as a concise narrative a collaborator, customer, or advisor can challenge constructively. Not a pitch. A review document that invites gaps to surface while they are still cheap.

The nine-section narrative

Hold each section to a tight limit — a paragraph plus its artifact link. Brevity forces the clarity a reviewer needs:

1. The person and job — user, buyer, workaround, pain (→ 90.1 one-pager). 2. The narrow first outcome — the changed condition plus proof (→ narrowness paragraph). 3. The system map and why each component exists — used layers with reasons, deferred layers with triggers (→ 90.2). 4. Context files and project-control plan — memory set, branch and review habit (→ 90.3). 5. Agent/automation boundaries and human ownership — spectrum placements, gates, kill switch (→ 90.5). 6. First-release scope, quality checks, and risks — flow, criteria, non-goals, preview, rollback (→ 90.6). 7. Distribution route and monetization hypothesis — audience, channel, proof, action, exchange (→ 90.8). 8. Evidence loop, cost controls, and operating plan — hypotheses, four-signal mix, caps, playbook (→ 90.7, 90.9). 9. The single decision or next action needed — one ask: approve the pilot cohort, fund the cost cap, confirm the preview user, grant the calendar scope. Not three asks. One.

Section 9 is the point of the other eight. A review without a decision is a reading group. Name the decider, the options, the date, and what happens under each option. "Approve five pilot analysts by Friday; if yes, preview Monday; if no, narrow to three and re-review."

The six review questions

Give the document to an AI collaborator or human reviewer with one instruction: challenge gaps, do not flatter the plan. They interrogate with six questions:

• What problem is real? Is the pain observed (quotes, numbers, workarounds) or asserted?
• What assumption is untested? Which load-bearing belief has no signal yet — and which hypothesis tests it first?
• Which component is unnecessary? What can be deleted or deferred without breaking the one path?
• What could cause harm if wrong? Bad advice, leaked data, wrong charge, false claim — and which gate stops it?
• What needs human approval? Every external action should trace to a named approver and log.
• How will the builder know it worked? The behavior, quality, question, and cost signals with dates — not vibes.

A credible plan survives these with artifact pointers, not adjectives. "Harm is bounded: drafts never publish without Maya's source-check (AGENT-BOUNDARIES §gate, log at …). Cost is capped: pause at $X/day (PLAYBOOK §costs)." Each answer should name a file and a line, not a hope.

Run the review twice: once with an AI reader primed to find gaps, once with a human who knows the user. The AI catches missing branches, vague criteria, and unlogged permissions. The human catches false jobs, wrong buyers, and promises nobody wants. Log both rounds as decisions in PROJECT-MEMORY.

Exercise: assemble FINAL-PROJECT-REVIEW.md and challenge it

Create FINAL-PROJECT/FINAL-PROJECT-REVIEW.md using the nine sections. Then run the challenge:

# FINAL-PROJECT-REVIEW — [Project], [date]

## 1. Person and job
[3 lines + link to PROJECT-ONE-PAGER.md]
## 2. Narrow first outcome
[changed condition + proof]
## 3. System map (why each part exists)
[diagram reference + one line per component + deferrals]
## 4. Memory + control
[memory files + branch/review habit]
## 5. Boundaries + human ownership
[spectrum placements + gate + kill switch owners]
## 6. First release + risks
[flow + criteria + non-goals + preview + rollback]
## 7. Route + exchange
[audience + channel + proof + action + payment test]
## 8. Evidence + operations
[3 hypotheses + cost caps + weekly review]
## 9. Single decision needed
[ask + decider + date + options + consequences]

## Review log
- [reviewer + date + hardest question + change made]

Deliver it with the instruction: "Challenge gaps, do not flatter. Use the six questions. Mark anything you cannot verify." Record every gap found as a task or decision — a review that changes nothing was entertainment.

Finish line: a credible system plan ready for a controlled first release — nine sections, one decision, two review rounds logged, gaps converted to tasks.

Verify: the stranger test, final form. Hand only the review to an outsider. Can they state the user, the outcome, the proof, the cost cap, and the one ask? Can they name what is deliberately excluded and what stops harm? If yes, the folder is a living control surface — usable by you, handable to a collaborator, submittable as the course's final artifact.

Common failure mode: the pitch deck — adjectives where acceptance criteria belong, vision where rollback belongs. Reviewers cannot challenge adjectives. Its mirror is the endless review: incorporating every suggestion until the scope re-expands. The review serves the single decision. Anything beyond that decision goes to the backlog with a trigger.

Check your understanding

1. Why does the review allow only one decision — and what happens to everything else raised? 2. Which of the six questions catches unlogged agent permissions, and which catches vanity metrics? 3. What distinguishes a pitch from a reviewable system narrative?

Next

Class 90 is complete. Your FINAL-PROJECT/ folder now holds the one-pager, system map, project memory, stack choices, agent boundaries, first-release plan, learning loop, go-to-market plan, operations playbook, and this review — the living control surface the course promised. Use the six appendices (90.A–90.F) as fillable companions whenever any section needs a fresh pass.