# ROOT_ Pilot Readiness Standard

Phase 6C §2 — the explicit bar a module must clear to be called READY for the first paid ROOT_
pilot. Extends `docs/COURSE_AUTHORING_STANDARD.md` with a pass/fail checklist rather than
general authoring guidance, and replaces ad hoc judgment calls with a documented rule every
module in `docs/ROOT_PILOT_CURRICULUM.md` is checked against.

## The standard is about sufficiency, not a fixed activity count

Phase 6A/6B's gold-standard pattern (lesson → demonstration → knowledge check → guided exercise
→ lab → reflection) is a strong DEFAULT for an operational skill module, not a mechanical
checklist to force onto every module regardless of subject. The actual test is:

> **Does the learner have enough instruction and scaffolding to reasonably perform the practical
> work, understand why it matters, and check their own understanding — without an instructor
> filling a gap the content itself should have closed?**

A module can be READY with fewer activities if the subject genuinely doesn't need all six. A
module can have all six activities and still not be READY if any of them fails its own bar
below (a "lab" with no framing, a "knowledge check" that only tests recall of the immediately
preceding paragraph).

## The READY checklist

A module is READY only if ALL of the following are true:

1. **Concept instruction exists and is substantive.** A `lesson` (or equivalent) activity
   explains the underlying mental model — what problem this solves, how it actually works, what
   goes wrong when it's misunderstood — not a restated scenario description or a bullet list of
   commands with no explanation of why.
2. **The learner sees the reasoning demonstrated, not just described**, wherever the subject
   involves diagnosing or configuring something non-trivial. This can be a `demonstration`
   activity, OR — for a purely conceptual/orientation module where there's nothing to
   diagnose — folded into the lesson itself with a worked example. A module that skips this
   entirely for an operational/troubleshooting subject is not READY.
3. **The learner can check their own understanding** before attempting independent work — a
   `knowledge_check` (or, for an orientation module with no lab, a reflection that serves the
   same self-check purpose) that tests INTERPRETATION and REASONING (see
   `docs/COURSE_AUTHORING_STANDARD.md` §9's examples), not trivia.
4. **The learner is not dropped into a lab cold.** Where a `lab` activity exists, either a
   `guided_exercise` bridges lesson to lab, OR the lesson/demonstration already gave the learner
   everything they need to attempt the lab's specific task without guessing at the mechanism
   being tested. A bare lab reference with a one-line "go do this" intro and no prior teaching
   of the concept it tests is NOT READY, regardless of how good the lab's own hints are — Labs
   are the laboratory, not the whole course (Phase 6A's own founding principle).
5. **The module closes with operational context**, where the subject has real production
   consequences — a `reflection` connecting what was practiced to why it matters beyond passing
   validation (see `docs/COURSE_AUTHORING_STANDARD.md` §15's Real Ops takeaway examples). A
   purely conceptual orientation module (e.g. Capstone Readiness) may satisfy this through its
   own closing content rather than a separate reflection activity.
6. **Instructor notes exist wherever a live class would benefit from them** — at minimum on the
   lesson and any demonstration/guided-exercise activity: timing, a likely misconception, and
   (for a demonstration) a demo plan. Not required on every activity type (a bare lab activity
   with no `content_path` has nothing to attach notes to).
7. **Self-paced sufficiency**: nothing in the module says or implies "your instructor will
   explain this" for content available to self-paced students. If an activity is genuinely
   instructor-only (rare in this content model — everything self-paced students can reach uses
   the same file), it must be excluded from self-paced delivery structurally, not by a
   disclaimer.
8. **Every reference resolves** — `scenario_id` points at a real scenario file,
   `assessment_definition_id` at a real definition, `content_path` at a real file that actually
   loads (`infra/scripts/validate-course-content.js` proves this mechanically; a human read-
   through confirms the CONTENT itself, not just that the file exists).

## What does NOT make a module READY

- Having a `lab` activity. A scenario reference is necessary, never sufficient.
- Having headings that look like a lesson. Prose volume is not instruction quality.
- Existing in the database with `status = 'ready'`. That field is the AUTHOR's claim — this
  document is the actual bar it's checked against, and `docs/ROOT_PILOT_CURRICULUM.md` is where
  every claim gets verified against this checklist by a human, not just by the field's value.
- Passing `e2e-phase6c.js`'s structural checks alone. Automated tests prove the DATA MODEL is
  correct (references resolve, completion derives correctly) — they cannot judge whether a
  lesson's explanation is actually good. That judgment is made once, explicitly, per module,
  and recorded in the pilot manifest.

## DEFERRED / NOT IN PILOT is not a failure

A module that doesn't meet this bar is not a defect to apologize for — it's an honest status.
`docs/ROOT_PILOT_CURRICULUM.md` uses DEFERRED (real content exists, not yet pilot-quality) and
NOT IN PILOT (deliberately excluded — e.g. ROOT 01-04, most of ROOT 11) as first-class,
legitimate outcomes. Marking something READY that isn't is a worse outcome than an honestly
smaller pilot.