Run the production readiness review

The prototype now has a protected URL and a clear purpose. Rather than begin with a checklist, begin with failure.

Incident review

For each incident, write four things: the first action that stops further harm, the missing evidence, the person responsible, and the control that would prevent a repeat.

1. The original builder leaves. Nobody can change production environment variables.
2. A protected preview works for engineers, but Procurement cannot sign in without joining the deployment team.
3. The model calls a restricted-data request “low risk.” The request is routed without Security review.
4. A user double-clicks Submit and two review processes begin.
5. Three months after launch, the technical owner cannot tell whether anyone still uses the application.

Open the Failure review section of docs/readiness.md. For every incident, name the first action, missing evidence, owner, and control. Mark the control implemented, demonstrated, planned, or not applicable. Never use a checkmark for something the team merely discussed.

Use these states throughout the course:

• Implemented: configured and verified in your deployment
• Demonstrated: inspected in a reference or a recorded enterprise environment, but not configured in your deployment
• Planned: required before the application reaches its intended audience, with a named owner and expected result
• Not applicable: excluded by a written requirement, with the reason recorded

“Understood,” “discussed,” and “available in the product” are not evidence states. A control can move between states only when its evidence changes.

Ownership

• Which organization owns the project and source repository?
• Is the technical owner a person, a team, or an unmanaged personal account?
• What happens when that person leaves?

Access

• Who can build and deploy?
• Who can use the application?
• What company systems can the application or model reach?
• Can those answers be reviewed without reading the entire codebase?

Decisions and actions

• Which outcomes come from deterministic policy?
• Which outcomes come from model judgment?
• Which outcomes require a human?
• Can the same submission accidentally start the same work twice?
• Is the reviewer’s identity recorded from a trusted source?

Evidence

• Are inputs, outputs, model choice, policy version, and human decisions retained?
• Can the team measure usage, errors, latency, quality, and cost?
• Is there a response when any of those signals move outside an acceptable range?

Rollout

• What evidence is required before the test group expands?
• Who makes the rollout decision?
• When will the application be reviewed again?
• How will the team contain or roll back a harmful change?

Turn gaps into work

Add an owner and target state to every gap. Do not attach product names yet. “Employees need access without deployment privileges” is a useful requirement. “Buy Passport” skips the reasoning the course is meant to teach.

Commit the review. This is the last planning-only commit; the rest of the course should change a control, a test, or a runnable behavior.

git add docs/readiness.md
git commit -m "docs: record production gaps"

Summary

A readiness review begins with the failure the team needs to prevent, then asks for ownership and evidence. Product choices come after the requirement is clear.

The remaining chapters resolve this assessment in order. Create One Governed Path begins with three access questions that are often collapsed into one: who builds, who uses, and which systems the application can reach.

Check your work

Pick the restricted-data incident. Starting from the bad model result, point to the exact rule that should still route the request, the person who receives it, and the record you would inspect afterward. Any missing link is now a concrete task for the next chapters.