Lesson 43.2 showed what must fit. This lesson determines where the project needs more design, review, testing, and human approval before it moves. Planning attention is scarce. Reviewer time is scarce. Your job as the director is to spend both where being wrong is expensive — not where the code looks interesting.

Risk is not difficulty

Beginners confuse risk with technical difficulty. They are different axes.

A one-line permission change — allow: all instead of allow: owner — is trivial to write and catastrophic to ship. A complicated loading animation is difficult to perfect and nearly harmless if it fails. The first needs a written design, a direct code review, an approval gate, and a rollback plan. The second needs a preview glance.

Assess risk by consequence, not cleverness. Ask six questions:

• Harm. Could a user be misled, blocked, or lose work?
• Privacy. Does it touch identity, private data, or access rules?
• Money. Does it move funds, trigger charges, or create billing state?
• Irreversibility. Can the change be undone cleanly, or does it migrate, delete, or publish?
• Reputation. Is it public, indexed, or attributed to the product's trust?
• Recovery. If it breaks, how hard is detection, rollback, and repair?

If any answer is uncomfortable, the task carries that risk regardless of how few lines it takes.

The Part IX ladder, formalized

Part IX introduced the risk ladder for directing AI. Class 43 makes it operational — every roadmap phase and every task card carries a risk level with a required response:

Put the risk column directly in ROADMAP.md and in each task card. It is not decoration. It tells the worker what process to follow and tells the reviewer what evidence to demand. A high-risk task with low-risk evidence ("looks fine in preview") is an unfinished task.

Copy this smaller decision version into your task template:

Why the plan may stop

Here is the discipline most AI-assisted builders resist: sometimes the valid output of a task is not code. It is a stop.

If a high-risk task reveals unknown data handling or authorization behavior — the provider's retention policy is unclear, the auth rule for shared items is undecided, the migration cannot be reversed — the correct result is "blocked pending decision," not AI code that guesses its way through.

Guessing through a high-risk unknown converts uncertainty into shipped behavior. The next agent treats the guess as fact. The decision log from Class 42.3 stays empty. The bug, when it surfaces, looks like a security incident rather than a planning gap — because it is one.

Teach your workers the stop sentence explicitly: "I stopped because X is undecided; here is what I need to proceed." Reward it. A blocked task with a named owner and a clear question is progress. A guessed implementation is debt with a fuse.

The save button that is not simple

Use the running example. Adding private watchlists looks like a simple save button. It is high risk.

The button introduces user identity (who is saving?), authorization (whose items can whom see?), stored user data (what is kept, for how long?), retention and deletion (what does "remove" actually erase?), and privacy promises (is anything shared, indexed, or visible to another account?). None of that is visible in the button's layout.

The roadmap responds structurally, not cosmetically:

• Separate it from low-risk brief-layout work. Different phase, different branch, different reviewer bar.
• Raise the evidence. Staged test with two accounts proving isolation, permission review, logs showing save/remove behavior, independent review before merge.
• Gate it. No merge until the access rule is written in SECURITY.md, the decision is recorded in DECISIONS.md, and the rollback path is named.

A layout tweak to the brief card stays low risk in its own lane: preview walkthrough, done. Mixing the two lanes — one branch, one review, one "looks good" — is how a cosmetic change smuggles an auth change past review.

Exercises

1. Score five upcoming tasks by risk. List five real tasks from your roadmap — for the dashboard, try: brief copy edit, citation-date display, provider mapping change, watchlist save, scheduled refresh. Assign each low, medium, or high using the six consequence questions. Then write the additional evidence the highest-risk task needs beyond "preview looks fine."

Finish line: a roadmap with a visible risk column and explicit approval gates instead of one generic "test before launch" line.

Verify it: for your highest-risk task, confirm you can name the reviewer, the approval gate, the rollback path, and the exact evidence (test names, log checks, permission review). If any answer is "we'll figure it out," the task is not ready to start.

Common failure: scoring by effort ("it took all afternoon, so it must be high risk"). Recovery: re-score by consequence — harm, privacy, money, irreversibility, reputation, recovery — and let a one-line change outrank a week of styling.

Check your understanding

• Why can a one-line permission change be high risk while a complex animation is low risk?
• What planning and evidence does each risk level require?
• When is "blocked pending decision" the correct task output, and why must the AI not guess through it?
• Why does the watchlist save button belong in a separate, higher-evidence lane than brief layout work?

You now have the full Class 43 system: a roadmap that orders the work, interface contracts that let parallel workers fit their pieces together, and risk planning that aims attention where error costs most. In Class 44 you will turn each phase into small tasks — vertical slices with clear cards, dependencies, and a delivery loop a human and an AI can run every day.