rootnode-academy/docs/ROOT_V1_CURRICULUM_MANIFEST.md

ROOT_ V1 Curriculum Manifest

Phase 6F — the canonical technical definition of what ROOT_ V1, the first sellable version of the ROOT_ program, actually includes. Where this disagrees with an older doc (ROOT_PILOT_ CURRICULUM.md, ROOT_PROGRAM_ARCHITECTURE.md), this document is the current source of truth; those documents have been updated to point back here.

V1 course list

#	Course	In V1?	Status	Required?	Prerequisite(s)	Duration (38-40 activities/course avg)
1	Computing & Linux Foundations	Yes	READY	Required	—	353 min (38 activities)
2	Linux Administration & Networking	Yes	READY	Required	ROOT 01	388 min (37)
3	Git & Collaborative Development	Yes	READY	Required	ROOT 02	312 min (31)
4	Containers & Docker	Yes	READY	Required	ROOT 03	444 min (43)
5	Kubernetes Foundations	Yes	READY	Required	ROOT 04	403 min (28)
6	Kubernetes Application Workloads	Yes	READY	Required	ROOT 05	299 min (23)
7	Kubernetes Networking & Configuration	Yes	READY	Required	ROOT 06	356 min (28)
8	Kubernetes Storage & Scheduling	No	PARTIAL	Excluded	—	250 min (15) — excluded from V1 total
9	Kubernetes Security	Yes	READY	Required for Capstone	ROOT 06	745 min (40, includes CKS-depth optional labs)
10	Kubernetes Troubleshooting & Observability	Yes	READY	Required	ROOT 06	280 min (21)
11	DevOps & Platform Engineering (orientation)	Yes	PARTIAL (by design)	Optional bonus	ROOT 10 (non-gating)	35 min (3)
12	RootNode Real Ops	Yes	READY	Required for Capstone	ROOT 10	115 min (6)
—	ROOT Capstone	Yes	READY	Terminal	ROOT 12 AND ROOT 09	120 min (5)

ROOT_ V1 total: 3,850 minutes = 64.2 structured hours (12 courses, excludes ROOT 08's 250 min). Program-wide total including the excluded ROOT 08: 4,100 minutes = 68.3 hours. Full per-module breakdown in docs/ROOT_PROGRAM_DURATION_MODEL.md.

Every V1-included course's real per-module evidence (activity counts, lab list, assessment wiring) lives in docs/ROOT_FOUNDATIONS_PILOT_READINESS.md (ROOT 01-04) and docs/ ROOT_CURRICULUM_COVERAGE_MATRIX.md (ROOT 05-13). This manifest is the scope decision; those documents are the evidence.

ROOT 08 — excluded from V1 (Step 2)

ROOT 08 (Storage & Scheduling) exists with 2 PARTIAL modules (bare scenario banks, no lesson scaffolding) but critically is not required by anything downstream — ROOT 09 and ROOT 10 both branch directly off ROOT 06 by design (see ROOT_PROGRAM_ARCHITECTURE.md's "deviations from the suggested sequence"). Leaving it visible mid-sequence (course #8, between two READY courses) would look to a self-paced student like a course they skipped, when V1 was never designed to require it.

Mechanism: visibility = 'draft' on the course and both its modules — the existing hard gate (COURSE_CONTENT_MODEL.md §6), excluded from every student-facing query, still fully visible/manageable for instructors. No content was deleted; this is reversible the moment ROOT 08 gets the same authoring pass ROOT 01-04 got.

ROOT 11 — included, repositioned as orientation-only bonus (Step 3)

ROOT 11 has exactly one real, finished, self-paced-ready module (lesson + knowledge check + reflection) bridging "systems administration" to "platform engineering thinking." The other six designed modules (CI/CD, GitOps, IaC) require lab infrastructure not yet built and are explicitly out of Phase 6F's scope (per the authorization's own DO-NOT-BUILD list).

Decision: keep it in V1, but its course description was rewritten to say plainly that it is a single orientation module, not a full DevOps course, and that the remaining six are designed but not yet built. It stays status = 'partial' (honest) and visibility = 'published' (real, finished content worth keeping visible). Nothing downstream requires it — a student who skips it loses nothing gating-wise.

The three instructor-led-only practice banks (Step 4)

root-06-m01-deployments-and-workloads, root-07-m01-services-and-networking, and root-10-m02-general-troubleshooting were flagged in Phase 6E as instructor-led-only: bare scenario banks with zero lesson/demonstration/knowledge-check framing.

Critical finding before any fix was applied: these three modules' scenario_ids are not generic supplemental practice — they are the literal content of the pre-existing scenarios/rootnode-path.json "workloads"/"networking"/"troubleshooting" stages, the older, separate mechanism that gates whether a student can even start the rootnode-capstone assessment. An initial attempt to reclassify them is_required = false (making them optional for course completion) was caught during this phase's own audit before being committed: it would have let a self-paced student reach a course-tree-"complete" state while remaining silently, confusingly blocked from the Capstone by the older stage gate. See platform/api/migrations/ 030_phase6f_capstone_gate_correction.sql for the full self-correction record.

Actual fix (Option A, not B): each module kept its activities is_required = true and received one short intro-lesson activity (*-a00-lab-bank-intro) explaining what the bank is, why it has no per-scenario teaching, and how to use it — the minimum real authoring needed to be honestly self-paced-ready, not a reclassification. All three modules, and their parent courses (ROOT 06, 07, 10), now genuinely earn status = 'ready'.

Course-level status audit correction (Step 0)

Auditing courses.status against actual module-level status (not trusting prior phase reports) found it had drifted stale for ROOT 05, 06, 07, 09, 10, 12, and Capstone — every module in each had already reached real ready content, but the course-level field was never bumped. Corrected in 029_phase6f_root_v1_integration.sql; no new content was required for ROOT 05, 09, 12, or Capstone (already fully authored), only for 06/07/10 (the practice-bank intro lessons above).

Capstone gate review (Step 7)

Two separate, independent gates protect the Capstone:

1. The legacy stage-based gate (scenarios/rootnode-path.json's unlock_rule, checked by POST /api/assessments/rootnode-capstone/start): six K8s scenario stages (foundation, workloads, networking, configuration, troubleshooting, real-ops). Left unchanged this phase — it has no natural "security stage" without new scenario-bank authoring, out of scope.
2. The course-layer gate (courses.prerequisites on root-capstone, checked by buildCourseTree()): previously {root-12-real-ops} only.

Decision: strengthened. root-capstone.prerequisites now also requires root-09-kubernetes-security. Evidence: the Capstone's own scenario pool (assessment_definitions.pool_spec) has zero overlap with the security assessment's CKS-style pool — a student could pass the Capstone having never touched a security scenario. ROOT 09 only reached genuine ready status this same phase, so requiring it any earlier would have gated on unfinished content. ROOT 09 and ROOT 12 are already sibling courses (both prerequisite = ROOT 06), so this adds no new sequencing burden — either order, or in parallel. See 031_phase6f_ capstone_security_prerequisite.sql.

Program + Lab orientation (Steps 9-11)

No orientation content existed anywhere before this phase (audited by grep across content/root). Added root-01-m00-welcome-to-root, a new required front-door module — the same pattern root-05-m00 already established — with two lessons (program overview and Lab lifecycle) and a knowledge check, sequenced before what was previously ROOT 01's first module. See 032_phase6f_root_v1_orientation.sql.

ROOT_ V1 curriculum version (Step 26)

No second versioning system was built — this manifest reuses the existing per-row version integer (courses/course_modules/module_activities), unchanged in convention from COURSE_CONTENT_MODEL.md §6b. "ROOT_ V1" itself is a scope label (which course/module ids are included, defined by this document), not a new database concept. What's frozen for a historical enrollment is exactly what was already true pre-Phase-6F: a student's activity_completions row stays valid across a later semantic edit to the same activity_id, keyed by the stable id, not a snapshot. A future "V1.1" content correction follows the same rule COURSE_CONTENT_MODEL.md §6b already documents — bump version on the changed row for a semantic edit, skip it for a typo-only fix. A future V1 SCOPE change (adding/removing a course from the manifest) is a change to this document plus a visibility/prerequisites migration, exactly like ROOT 08's exclusion this phase — not a new mechanism to build.

What this manifest deliberately does not cover

Pricing, registration, marketing copy, and camp scheduling are out of scope for this document — see docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md and docs/ROOT_V1_INSTRUCTOR_LED_PILOT.md for delivery packaging, and Phase 7 for the business/product architecture layer.