# 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_id`s, 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.