rootnode-academy/docs/SCHOOL_AND_COMMUNITY_DELIVERY_ARCHITECTURE.md

School & Community Delivery Architecture

Phase 7 Step 27 — how a future school, library, homeschool organization, or community partner maps onto the platform's new organization/location/offering model. This is architecture documentation for an asset-light delivery strategy — RootNode favors partner/temporary venues over building permanent classrooms everywhere, at least initially.

The mapping

Organization (e.g. "Oxford Community Library")
  └─ Location (e.g. "Library — Community Room B", or "Online")
       └─ Offering (e.g. "After-School ROOT Foundations — Library Branch, Spring 2027")
            ├─ program_id → an existing program (ROOT_ V1, or a future family)
            ├─ curriculum_package_id → optionally, a subset (Step 20)
            ├─ delivery_mode → 'after_school' / 'community' / 'school' / 'homeschool'
            ├─ cohort_id → the real classroom/roster mechanism, unchanged
            └─ instructor_offerings → who teaches it

A school, library, or homeschool organization is represented as ONE organizations row. It may have multiple locations (a school with two campuses; a library system with several branches). Each real delivery of curriculum at that organization is its own offerings row — this lets one organization run several different offerings (different programs, different cohorts, different semesters) without any of them being confused for each other, and without needing a new mechanism for "an organization has many offerings" (it's the same one-to-many organization_id foreign key locations and offerings already both carry).

What this is NOT

Not multi-tenancy. No table in this schema is partitioned by organization_id the way a true multi-tenant SaaS product would be — students, instructors, courses, and progress are not scoped to an organization. An organization is a business/delivery context an offering can optionally reference, nothing more. RootNode Academy remains one Academy with one shared platform, one curriculum, and one set of students — a student who attends via a school partnership is a normal RootNode student, indistinguishable in the data model from a self-paced student, except for which offering(s) they registered through.

Multi-location operation

Two offerings at two different locations coexist with no special isolation mechanism needed — they're just two rows in offerings with different location_ids, each with its own cohort/ roster/registrations. platform/test/e2e-phase7.js proves this concretely: two offerings, two locations, verified to never leak state into each other. This is operational separation (two independent business records), not a security/tenant-isolation claim.

What was explicitly NOT built this phase

• No school SIS integration (no roster import/export, no grade-passback, no LMS interoperability standard like OneRoster or LTI).
• No Google Classroom integration.
• No organization-specific portal or branding — every organization's students see the same RootNode Academy platform; there is no white-labeling.
• No organization-level admin role — an organization contact does not get their own login or visibility into the platform; all administration remains through RootNode's own instructor/admin accounts, same as any other offering.

Future extension points (not built, but not blocked)

If a future phase needs an organization contact to see their own offering's roster/progress (e.g. a school liaison checking on their students), that's a new, scoped RBAC role — the organizations/offerings model here doesn't need to change to support it, only the authorization layer would need a new role definition, deliberately deferred rather than guessed at now.