rootnode-academy/docs/ROOT_PROGRAM_ARCHITECTURE.md

ROOT_ Program Architecture

Phase 6A §2 — the canonical course architecture for root_ (Linux → systems → containers → Kubernetes → DevOps/platform engineering, ages ~15-18+/college/adult per the youth ladder — see docs/PHASE6A_ROOT_COURSE_FOUNDATION.md §1). This document is the design; the actual seed data lives in platform/api/migrations/022_course_content.sql, generated to match this exactly.

All 13 rows below are courses under the ONE existing program, root-kubernetes-foundations (programs table, unchanged — see §"why one program, not thirteen" below). Every status claim here is grounded in docs/ROOT_CURRICULUM_INVENTORY.md, not aspirational.

Updated for Phase 6B (platform/api/migrations/023_phase6b_curriculum.sql, docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md): ROOT 08 and 09 moved from PLANNED to PARTIAL, and 6 courses gained new teaching modules — the module-level detail and evidence for every new placement lives in docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md, not duplicated here.

Updated for Phase 6D (platform/api/migrations/025_phase6d_root_foundations_root01.sql, docs/PHASE6D_ROOT_FOUNDATIONS.md): ROOT 01 fully authored and moved to READY — see docs/ROOT_FOUNDATIONS_ARCHITECTURE.md for its module-level design and docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md for why no new activity type was needed. ROOT 02-04 remain PLANNED (architecture designed, content not yet authored) but now carry a real prerequisite chain (01→02→03→04→05) enforced server-side.

Course sequence

#	Course	Status	Why
1	Computing & Linux Foundations	READY	Phase 6D: 6 modules, real Linux/shell scenarios using the existing generic scenario engine, a wired assessment — see docs/PHASE6D_ROOT_FOUNDATIONS.md.
2	Linux Administration & Networking	READY	Phase 6E: 6 modules, real Linux/networking scenarios, a wired assessment — see docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md. Real prerequisite: ROOT 01 complete.
3	Git & Collaborative Development	READY	Phase 6E: 6 modules, real local-Git scenarios (including a real merge conflict and a real local-bare-remote push), a wired assessment. Real prerequisite: ROOT 02 complete.
4	Containers & Docker	READY	Phase 6E: 8 modules using the nested Docker Engine (built and verified Phase 6D, docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md §3), real container scenarios, a wired assessment. Real prerequisite: ROOT 03 complete.
5	Kubernetes Foundations	READY (Phase 6F)	Phase 6B added a READY front-door module (root-05-m00-kubernetes-mental-model) sequenced before the 20-scenario bare-lab bank (root-05-m01), which itself already carried a lesson+reflection wrapper — Phase 6F's audit found both modules genuinely ready and corrected the stale course-level status.
6	Kubernetes Application Workloads	READY (Phase 6F)	Phase 6B's READY root-06-m02 and root-06-m03 remain unchanged; Phase 6F gave the practice-bank root-06-m01 a real intro-lesson activity, closing the last gap.
7	Kubernetes Networking & Configuration	READY (Phase 6F)	Phase 6C already converted root-07-m02 to a full teaching module; Phase 6F gave the practice-bank root-07-m01 a real intro-lesson activity, closing the last gap.
8	Kubernetes Storage & Scheduling	PARTIAL — excluded from ROOT_ V1	Phase 6B's two PARTIAL modules are unchanged; Phase 6F excluded the whole course from ROOT_ V1 (visibility=draft) since nothing downstream requires it — see docs/ROOT_V1_CURRICULUM_MANIFEST.md.
9	Kubernetes Security	READY (Phase 6F)	Phase 6B's four modules (all real CKS-style content) were already individually ready; Phase 6F's audit corrected a stale course-level status field. Now also a required Capstone prerequisite (Step 7).
10	Kubernetes Troubleshooting & Observability	READY (Phase 6F)	The Phase 6A gold-standard module and Phase 6C's root-10-m03 remain unchanged; Phase 6F gave the practice-bank root-10-m02 a real intro-lesson activity, closing the last gap.
11	DevOps & Platform Engineering Foundations	PARTIAL, by design	One real orientation module exists (lesson/knowledge-check/reflection); Phase 6F repositioned it explicitly as an optional bonus module, not a promise of a full course — see docs/ROOT_V1_CURRICULUM_MANIFEST.md. Deeper CI/CD/IaC/GitOps content remains unbuilt, unchanged.
12	RootNode Real Ops	READY (Phase 6F)	Phase 6B's framing lesson/reflection wrapping the existing 4-scenario module was already complete; Phase 6F's audit corrected a stale course-level status.
13	ROOT Capstone — Operate and Recover a Production-Like Environment	READY (Phase 6F)	Phase 6B's Capstone Readiness module was already complete; Phase 6F's audit corrected a stale course-level status and added ROOT 09 as a joint course-level prerequisite alongside ROOT 12 — see docs/ROOT_CAPSTONE_READINESS.md §1b.

No course is marked READY at the course level in Phase 6A — that's honest: a course only earns READY once every module in it has real teaching content, and Phase 6A deliberately built exactly one complete module (the gold standard) as the authoring template, not a finished curriculum.

Prerequisite chain

01 Linux Foundations → 02 Linux Admin/Networking → 03 Git → 04 Containers/Docker
                                                                    │
                                                                    ▼
                                                    05 Kubernetes Foundations
                                                                    │
                                                                    ▼
                                                06 Application Workloads
                                                          │         │
                                    ┌─────────────────────┤         │
                                    ▼                     ▼         ▼
                        07 Networking/Config   09 Security   10 Troubleshooting
                                    │                              │      │
                                    ▼                              │      ▼
                        08 Storage/Scheduling                      │  11 DevOps/Platform
                                                                    ▼
                                                        12 RootNode Real Ops
                                                                    │
                                                                    ▼
                                                        CAPSTONE — Operate & Recover

Updated for Phase 6D: 01→02→03→04→05 became a real, server-side prerequisite chain (courses.prerequisites). At that point ROOT 01 was real content and 02-04 remained PLANNED, so ROOT 02 was the only course the chain actually locked; 03/04/05 stayed vacuously satisfied until their own prerequisite course was authored — see docs/COURSE_CONTENT_MODEL.md's "prerequisite/locking rule" for why a PLANNED/content-free prerequisite never actually blocks anything.

Updated for Phase 6E (docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md): ROOT 02, 03, and 04 are now real, authored, READY courses — the ENTIRE 01→02→03→04→05 chain now genuinely gates for a real student, verified live on both a fully-completed student and a fresh one. A pre-existing gap in the direct-API completion route (found while proving this chain, unrelated to any single phase's own content) is also fixed this phase — see that document for detail.

Updated for Phase 6F (docs/ROOT_V1_CURRICULUM_MANIFEST.md): ROOT 05, 06, 07, 09, 10, 12, and Capstone all reached genuine course-level READY status (a stale-status audit correction plus real intro-lesson authoring for three practice-bank modules). ROOT 08 was excluded from ROOT_ V1 (visibility=draft). ROOT 11 stays PARTIAL by design, repositioned as an optional orientation bonus. root-capstone's own prerequisites now also require ROOT 09 (Security) complete, alongside the pre-existing ROOT 12 requirement. A new required orientation module (root-01-m00-welcome-to-root) now precedes ROOT 01's original first module.

Deviations from the spec's suggested sequence, and why

The authorization's suggested sequence listed Security (09) after Storage/Scheduling (08) and before Troubleshooting (10). This document keeps that numbering for continuity, but the prerequisite graph branches 09 and 10 both directly off 06 (Application Workloads) rather than chaining 08→09→10 linearly — the existing content doesn't actually build 09 on top of 08's concepts (RBAC/PSA/network-policy security content is orthogonal to PV/PVC/scheduling content), so a straight linear chain would impose a false dependency. This is exactly the case the authorization's "if existing content suggests a better grouping, document the reasoning" line anticipated.

Real Ops and Capstone placement

Real Ops (12) sits after Troubleshooting (10), matching the existing curriculum's own stage order (rootnode-path.json's real-ops stage already comes after troubleshooting) — Real Ops scenarios assume the diagnostic skills Troubleshooting teaches. The Capstone sits after Real Ops alone, not after every course, because that's what the existing rootnode-capstone assessment definition's own unlock_rule already requires (all 6 content stages of rootnode-path.json complete — which necessarily includes 05-06-07-10-12's underlying scenarios, plus networking/ configuration). 08, 09, and 11 are not currently gating the capstone, because their scenario content isn't part of rootnode-path.json's stage list at all yet — see docs/COURSE_CONTENT_MODEL.md for how course-level completion is computed independently of that assessment-engine unlock_rule (the two systems currently agree by construction, not by a shared implementation).

Why one program, not thirteen

programs (Phase 5B) models the commercial/academic unit a student enrolls in. root_ is described by this authorization as one continuous ladder — "Linux → systems → containers → Kubernetes → DevOps/platform engineering" — not thirteen separate purchases. Attaching all 13 courses to the single existing root-kubernetes-foundations program means:

• Zero changes to the programs table, enrollment model, or entitlement logic — an enrolled student automatically has structured access to the whole ladder as it's built out.
• No renaming/redefinition of the existing program (which would risk a real, if cosmetic, break for anyone already enrolled) — see Phase 6A's explicit "do not redesign working systems" constraint.

If a future phase needs root_ split into separately-purchasable programs (e.g. "Kubernetes Foundations" sold standalone from "DevOps"), that's a programs-table decision to make deliberately later, informed by real pricing/business requirements — not something to guess at here.