ced4568andClaude Sonnet 5
df5e39f767
New: ROOTNODE_ACADEMY_BUSINESS_AND_PRODUCT_ARCHITECTURE.md (canonical business/platform bridge — course families, delivery modes, BUILT NOW/PHASE 7 BUILT/FUTURE), OFFERING_AND_ REGISTRATION_MODEL.md (lifecycle diagrams, capacity mechanics), STUDENT_GUARDIAN_DATA_ MODEL.md (data minimization, RBAC, legal-review items), SCHOOL_AND_COMMUNITY_DELIVERY_ ARCHITECTURE.md (organization/location mapping, explicitly not multi-tenancy), PHASE7_PRODUCT_ARCHITECTURE.md (phase summary). Updated: WEBSITE_ENROLLMENT_INTEGRATION.md (documented future offering/registration flow, current live contract unchanged), platform/README.md (test list). Co-Authored-By: Claude Sonnet 5 <[email protected]>
65 lines
3.7 KiB
Markdown
65 lines
3.7 KiB
Markdown
# 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.
|