rootnode-academy/docs/ROOT_PILOT_READINESS_STANDARD.md

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.