ced4568/rootnode-academy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(phase7): document the business/product architecture foundation

Browse Source 
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]>
This commit is contained in:
ced4568
2026-08-26 22:44:13 -05:00
co-authored by Claude Sonnet 5
parent 7d870d8e2b
commit df5e39f767
7 changed files with 591 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/WEBSITE_ENROLLMENT_INTEGRATION.md
+31 -4
View File
@@ -171,10 +171,37 @@ email — otherwise the enrollment is created but nobody is notified automatical
instructor has to relay the activation link manually. `contact_email` is stored only against
that specific enrollment, never copied into the student's own identity record.
There is no guardian/parent account system yet — the enrollment is created directly against the
student identity you provide. If you need to support "a parent manages multiple children's
enrollments" as a first-class concept later, talk to the RootNode team before building around a
workaround; the schema has room for it but it isn't implemented.
**As of Phase 7, a real guardian/parent record now exists** (`guardians`/`student_guardians` —
see `docs/STUDENT_GUARDIAN_DATA_MODEL.md`), but this endpoint's contract is UNCHANGED and does
not yet create or link one — `student.contact_email` still works exactly as described above,
stored only on the enrollment. If you need "a parent manages multiple children's enrollments" as
a first-class concept in this endpoint, talk to the RootNode team before building around a
workaround; the schema now has the real tables for it, they're just not wired into this
endpoint yet.
## Future flow: offerings and registrations (Phase 7, not yet live on this endpoint)
RootNode Academy is now (rootnodeacademy.com, live separately from this repository) building
toward representing specific purchasable deliveries — camps, cohorts, self-paced access — as
first-class **offerings**, with a **registration** step before final enrollment (see
`docs/OFFERING_AND_REGISTRATION_MODEL.md`). The eventual intended flow:
```
Website: learner selects an offering (e.g. "Winter Break Linux & Systems Camp")
-> Website collects registration info (student/guardian, readiness, agreements)
-> Website checkout/payment (future — not built yet)
-> Verified commerce event -> RootNode confirms the registration
-> RootNode activates the enrollment (reusing this exact endpoint's machinery)
-> Student receives their existing activation email, unchanged
-> Student/camp access begins
```
**This is documentation of an intended future shape, not a live contract change.** The endpoint
below is unaffected — it continues to work exactly as documented, program-slug-based, with no
concept of an offering. A future phase will either extend this endpoint with an optional
`offering_slug` field or add a parallel endpoint once the website's actual checkout flow is
designed; that decision has not been made. Idempotency (`event_id`) will remain the mechanism
either way.
## What the student experiences after you call this (as of Phase 5C)