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.

Course sequence

#	Course	Status	Why
1	Computing & Linux Foundations	PLANNED	No lab content exists in this repository — every scenario is Kubernetes/CKS.
2	Linux Administration & Networking	PLANNED	Same — no Linux-admin scenario content exists.
3	Git & Collaborative Development	PLANNED	No Git scenario content exists.
4	Containers & Docker	PLANNED	No Docker-specific scenario content exists (the Lab itself runs k3s, but no student-facing "learn Docker" scenarios exist).
5	Kubernetes Foundations	PARTIAL	Phase 6B added a READY front-door module (root-05-m00-kubernetes-mental-model — full lesson/demo/knowledge-check/guided-exercise/lab/reflection) sequenced before the existing 20-scenario bare-lab bank (root-05-m01), which now sits behind it.
6	Kubernetes Application Workloads	PARTIAL	Phase 6B added a READY root-06-m02-deployments-scaling-updates and a PARTIAL root-06-m03-jobs-cronjobs-daemonsets, both in front of the existing bare-lab bank.
7	Kubernetes Networking & Configuration	PARTIAL	Phase 6B added a READY root-07-m03-services-and-service-discovery and a PARTIAL root-07-m04-ingress-networkpolicy-foundations. The existing configuration bank (root-07-m02) still has no authored teaching content — an honest, documented gap.
8	Kubernetes Storage & Scheduling	PARTIAL	Phase 6B wired the real scenario content the inventory identified (PV/PVC, StorageClass, taints/tolerations, PDB, quotas/limits) into two new PARTIAL modules — moved off PLANNED for the first time.
9	Kubernetes Security	PARTIAL	Phase 6B built the 22-scenario CKS-style bank into four modules (Security Model & SecurityContext — READY; ServiceAccounts & RBAC, Network & Supply Chain Security, Cluster Hardening & Runtime — all PARTIAL), classifying scenarios CORE/GUIDED/INDEPENDENT/ADVANCED/ASSESSMENT-BANK rather than exposing them as 22 disconnected tasks — moved off PLANNED.
10	Kubernetes Troubleshooting & Observability	PARTIAL	The Phase 6A gold-standard module (READY, unmodified) plus a new PARTIAL root-10-m03-troubleshooting-framework (the generalized Observe/Evidence/Hypothesis/Test/Repair/Validate/Prevent framework) and the existing bare-lab bank, now sequenced last.
11	DevOps & Platform Engineering Foundations	PLANNED	No CI/CD/IaC/GitOps scenario content exists anywhere in this repository — unchanged, out of Phase 6B's authoring scope.
12	RootNode Real Ops	PARTIAL	Phase 6B added an incident-response framing lesson and a post-incident reflection wrapping the existing 4-scenario module — the incidents themselves are unchanged, still deliberately un-guided.
13	ROOT Capstone — Operate and Recover a Production-Like Environment	PARTIAL	Phase 6B added a READY Capstone Readiness module (orientation, no answers) sequenced before the existing capstone assessment module — see docs/ROOT_CAPSTONE_READINESS.md.

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

01-04 have no prerequisite chain enforced against each other yet (all PLANNED, zero content — locking a PLANNED course behind another PLANNED course would just be decorative). 05 is the first course with a real prerequisite gate. See docs/COURSE_CONTENT_MODEL.md's "prerequisite/ locking rule" for why a PLANNED/content-free prerequisite never actually blocks anything.

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.