# Student & Guardian Data Model

Phase 7 Step 28 — why student and guardian identities are kept separate, what data-minimization
principles govern the new `guardians`/`student_guardians` tables, and what still needs
professional/legal review before any of this touches a real minor's data in production.

## Why separate identities

A student's own identity (`students` table — `email`/`login_identifier`, unchanged) is their
academic account. A guardian (`guardians`, new this phase) is a real, separate identity: a
parent with three enrolled children is **one** guardian row linked to three students via
`student_guardians`, not a guardian email copy-pasted into three student records. This mirrors
exactly the reasoning `docs/WEBSITE_ENROLLMENT_INTEGRATION.md` already gave for keeping
`contact_email` off `students.email` — a contact address is not an academic identity, and now a
guardian is a real relationship, not a workaround field.

## What this phase deliberately did NOT build

- **No Parent Portal.** A guardian record has no login, no password, no session — it cannot
  authenticate into anything yet. Building that is a real, separate future decision.
- **No child-activity surveillance.** Nothing in this schema or its routes lets a guardian (once
  they could log in, in some future phase) see a student's Lab activity, scenario attempts, or
  detailed learning analytics by default. A guardian relationship is a contact/authorization
  record, not a monitoring grant.
- **No automatic broad access.** `student_guardians.can_receive_communications` and
  `is_primary_contact` govern notification targeting only (a future concern — this phase writes
  the rows but does not wire them into `notifications.js`'s resolveRecipient yet), never
  authorization to student data.

## Data minimization

Only fields with a genuine, near-term operational purpose were added: `display_name`, `email`,
`phone`, and a free-text `notes` field for a guardian; `relationship`
(`parent`/`guardian`/`authorized_contact`/`emergency_contact`), `is_primary_contact`, and
`can_receive_communications` for the relationship itself. Registration-time fields
(`readiness_notes`, `accessibility_notes`, `emergency_contact_name`/`emergency_contact_phone`)
were chosen because a real camp/cohort genuinely needs them operationally — **no medical-record
functionality was built**, and `accessibility_notes` is a free-text operational note (e.g. "uses
a screen reader," "needs extra Lab time"), never a structured health/diagnosis field.

## RBAC

Guardian records and registration detail (readiness/accessibility/emergency-contact notes) are
admin/owner-only routes — a plain instructor's existing cohort-scoped access to a student's
academic progress is unchanged, but they do not automatically see guardian contact information
or registration notes through the new routes. See `admin-offerings-routes.js`'s own RBAC
comment and `platform/test/e2e-phase7.js`'s guardian-RBAC test.

## Adult vs. minor enrollment

An adult learner registers and is their own `registrant_email`/eventual student identity — no
guardian row is created or required. A minor's registration requires a `guardian_id` (enforced
by a database CHECK constraint on `offering_registrations`, not just application logic). Neither
path writes a guardian's email into `students.email` — a minor with no email of their own still
gets `login_identifier`-based identity (the same mechanism `docs/WEBSITE_ENROLLMENT_INTEGRATION.md`
already established), preserving the identity semantics Phase 5A/5C set up.

## Retention — flagged, not decided

This phase does not implement a data-retention or deletion policy for guardian/registration
records. **Requires future legal/business review**: how long registration data (especially
accessibility/emergency-contact notes for a minor) should be retained after an offering
completes or a registration is cancelled, and what a guardian's/family's data-deletion request
process should look like.

## Items explicitly requiring professional/legal review before production use with real minors

- Whether the current field set (name/email/phone/relationship) is sufficient or whether
  jurisdiction-specific requirements (e.g. COPPA-adjacent consent language, state-specific camp/
  minor-supervision regulations) require additional structured fields.
- The actual legal text of any participation agreement, media consent, or liability waiver —
  `agreement_definitions.body_summary` is a plain-language placeholder for admin-UI display
  only, never a substitute for attorney-reviewed legal language.
- Data retention/deletion policy for guardian and registration records.
- Whether `emergency_contact_name`/`emergency_contact_phone` need to be encrypted at rest beyond
  Postgres's existing storage (no additional encryption was added this phase).

None of the above is resolved by this phase's work — they are named here specifically so they
are not silently assumed away.