rootnode-academy/docs/ROOTNODE_ACADEMY_BUSINESS_AND_PRODUCT_ARCHITECTURE.md

RootNode Academy — Business & Product Architecture

Phase 7 Step 1 — the canonical bridge between RootNode's business strategy and its platform architecture. This is where "what RootNode Academy sells and to whom" and "what the codebase actually implements" are kept in one place, deliberately separated into BUILT NOW / PHASE 7 BUILT / FUTURE so nobody has to guess which parts are real.

Course families

INIT_, COMPILE_, ROOT_, and BOOTCAMP_ are product positioning and technical-depth families, not a rigid age ladder and not a mandatory sequence:

Family	Typical audience (guidance, not a gate)	Status
INIT_	~ages 5-10	Not yet authored (BUILT NOW: programs.family accepts it; PHASE 7 BUILT: nothing else; FUTURE: real curriculum)
COMPILE_	~ages 11-14	Same as INIT_
ROOT_	~ages 15+ through adult	Fully authored, V1 pilot-ready (Phase 6F)
BOOTCAMP_	short/intensive seasonal or specialty offerings	BUILT NOW: programs.family accepts it; PHASE 7 BUILT: the offering/curriculum-package machinery a bootcamp needs; FUTURE: an actual bootcamp program row

INIT → COMPILE → ROOT is explicitly NOT a mandatory path. A student's access to any given course depends on that course's own prerequisites (already real and server-enforced within ROOT_ — see docs/ROOT_V1_PREREQUISITE_MAP.md), not on which family they've touched before.

COMPILE_ / ROOT_ overlap

These two families intentionally cover overlapping technical territory at different depths — an adult is not blocked from an electronics/robotics/IoT course merely because it's positioned under COMPILE_, and a COMPILE_-age student is not blocked from later revisiting the same domain at ROOT_ depth. Example: COMPILE_ might teach "ESP32 + a sensor + introductory MQTT"; ROOT_ might teach "Linux + networking + a real broker/service + a containerized IoT workload + observability" — same domain, different technical floor. BUILT NOW: nothing prevents this architecturally — programs/offerings carry no family-based authorization check anywhere in the codebase. FUTURE: the actual COMPILE_ electronics/robotics content itself (explicitly out of Phase 7's scope).

Program vs. Course vs. Offering

Three previously-conflated levels, now distinct:

• Program (programs table, Phase 5B, unchanged): the educational product/path itself — e.g. "ROOT Kubernetes Foundations." Carries family and a default delivery_mode.
• Course (courses table, Phase 6A, unchanged): a curricular unit inside a program — e.g. "ROOT 02 Linux Administration & Networking."
• Offering (offerings table, new this phase): a specific purchasable/enrollable instance of delivering a program (or a curriculum-package subset of one) — e.g. "Winter Break Linux & Systems Camp — December 2026," "ROOT Foundations Cohort — Spring 2027," "ROOT Self-Paced." A program can have many offerings across time; an offering always points at exactly one program.

A workshop and a cohort are both just delivery_mode values on an offering, not separate tables — see "Delivery modes" below. A curriculum package (new this phase) is an optional, named, versioned SUBSET reference into an existing program's courses, for when an offering (like a camp) intentionally teaches only part of a program — see docs/OFFERING_AND_REGISTRATION_MODEL.md.

Age guidance, not a gate

offerings.recommended_min_age/recommended_max_age and each course family's typical-audience description are display/marketing guidance only. No API authorization check anywhere in this codebase reads either value — enrollment and course access remain governed entirely by prerequisites, entitlement (enrollments.status), and (new this phase) offering capacity/ registration status. Verified explicitly in platform/test/e2e-phase7.js.

Delivery modes

Curriculum and delivery are separate concepts. offerings.delivery_mode (new this phase) is a single column supporting: self_paced, cohort, hybrid, camp, workshop, school, after_school, homeschool, community, one_to_one. No curriculum content is duplicated per mode — the same program/courses/course_modules/module_activities are read regardless of which offering enrolled the student into them, exactly the same principle docs/REMOTE_AND_SELF_PACED_ARCHITECTURE.md already established for self-paced vs. instructor-led delivery of ROOT_ V1.

Organizations and locations

Organization (new this phase): a business/delivery relationship — a school, library, homeschool group, community organization, or workforce-development partner. Not SaaS multi-tenancy: RootNode Academy remains one Academy, one database, one set of students/ instructors; an organization is metadata an offering can optionally reference, not a data partition. Location (new this phase): a physical or virtual delivery site, optionally tied to an organization (a rented community-center room needs no partner org; "online" needs neither an org nor a physical address). See docs/SCHOOL_AND_COMMUNITY_DELIVERY_ARCHITECTURE.md.

Guardians and minors

Guardian (new this phase, guardians/student_guardians): a real, separate identity from a student's own account — not a login/auth identity yet (no password, no session), just a contact/relationship record. Replaces the Phase 5C enrollments.metadata.contact_email workaround as the proper foundation, while leaving that workaround functioning unchanged for backward compatibility with the live website integration. See docs/STUDENT_GUARDIAN_DATA_MODEL.md.

Registration, enrollment, and agreements

Registration (new this phase, offering_registrations): pre-enrollment interest/application information for a specific offering — separate from enrollments (academic entitlement, unchanged). A registration becomes a real enrollment only once confirmed, via convertRegistrationToEnrollment(). Agreement (new this phase, agreement_definitions/agreement_acceptances): a versioned ACCEPTANCE RECORD, never legal text authored by this codebase. See docs/OFFERING_AND_REGISTRATION_MODEL.md.

Commerce boundary — real as of Phase 9

The boundary itself is unchanged: the website owns marketing/pricing DISPLAY and the hosted checkout experience, RootNode's platform owns the actual price (server-controlled, never browser-supplied), payment verification, and everything after a verified commerce event. Phase 7 documented the flow; Phase 9 built it for real: an offering can carry a price (offerings.price_amount/price_currency), a payment-provider abstraction (Stripe or a deterministic in-process test provider — see docs/PHASE9_COMMERCE_AND_LAUNCH.md) creates a hosted checkout session server-side, and a verified, idempotent webhook is the ONLY thing that ever confirms payment and drives registration confirmed → enrollment activated — a browser ?paid=true redirect proves nothing and is never trusted. See docs/ WEBSITE_REGISTRATION_AND_CHECKOUT.md for the website's contract and docs/ STRIPE_INTEGRATION_RUNBOOK.md for going live with real Stripe.

First commercial target: Winter Break Camp

Per docs/WINTER_BREAK_CAMP_CURRICULUM_OPTIONS.md's Option A (Linux & Systems Foundations, ROOT 01-02, ~12.4 hours), Phase 7 models this as a real, if still DRAFT, offering (docs/OFFERING_AND_REGISTRATION_MODEL.md's worked example) — proving the platform CAN represent and operate it, without inventing dates, venue, price, or seat count that aren't already decided.

Future memberships/subscriptions and institutional delivery

Recurring (self-paced subscriptions, after-school programs, school/community contracts) and institutional (schools, libraries, workforce partners) revenue channels are FUTURE — the organizations/locations/offerings model this phase builds is deliberately general enough to represent them later without a schema redesign, but no billing/subscription code exists or is planned this phase.

BUILT NOW / PHASE 7 BUILT / FUTURE — summary

Concept	Status
Programs, courses, ROOT_ V1 curriculum	BUILT NOW (Phases 1-6F)
programs.family accepting bootcamp	PHASE 7 BUILT (schema widening only)
Organizations, locations	PHASE 7 BUILT
Guardians, student-guardian relationships	PHASE 7 BUILT
Offerings, capacity, server-defined status transitions	PHASE 7 BUILT
Curriculum packages (subset references)	PHASE 7 BUILT
Registrations, registration lifecycle	PHASE 7 BUILT
Agreement definitions/acceptances (record-only, no legal text)	PHASE 7 BUILT
Admin routes for all of the above	PHASE 7 BUILT
Admin UI (Offerings/Registrations screens)	PHASE 8 BUILT — /admin → Offerings, with launch readiness, roster, agreements, and per-registration detail (communications, agreement status).
Guardian communications (5 new notification templates, guardian recipient fallback)	PHASE 8 BUILT
Public offering read API + website registration submission contract	PHASE 8 BUILT (docs/WEBSITE_ENROLLMENT_INTEGRATION.md)
Offering agreement requirements + conversion blocking	PHASE 8 BUILT
Offering pricing, payment-provider abstraction, hosted checkout, verified webhook	PHASE 9 BUILT (docs/PHASE9_COMMERCE_AND_LAUNCH.md) — Stripe test-mode + a deterministic in-process test provider; real Stripe live-mode validation is pending real credentials.
Agreement acceptance on the public registration contract	PHASE 9 BUILT — closes the gap Phase 8 left open.
Refund/cancellation recording (commerce status only, never auto-cascading)	PHASE 9 BUILT
Abandoned-reservation reaper, reservation expiry for paid offerings	PHASE 9 BUILT
Admin payment UI (price, payment/refund status, no card data)	PHASE 9 BUILT
A real website-side registration/checkout form (rootnodeacademy.com itself)	FUTURE — contract ready, form not built in this repo (separate repo, not RootNode-owned).
Live Stripe validation (real credentials, real card, real webhook from Stripe's servers)	FUTURE — application layer is done and Stripe-test-mode-tested; pending real Stripe credentials.
Subscriptions, membership billing, coupons, gift cards, installment plans, tax automation	FUTURE, explicitly out of scope
INIT_/COMPILE_ curriculum	FUTURE
School/library SIS integrations, parent portal, guardian login	FUTURE, explicitly out of scope