FERPA & Student Privacy
How the Classroom (institutional) plane protects student educational records.
BeaconUAV's Classroom workspace is built for schools and districts. It is a separate, isolated workspace from your personal logbook, designed around FERPA principles: minimum necessary data, strict tenant isolation, and an auditable trail for every record access.
What we collect (and what we don't)
Collected: the operational minimum
| Data | Why |
|---|---|
| Account username / callsign | To display you in rosters (never derived from your email) |
| School-issued email | Enrollment matching only; staged temporarily, deleted once linked |
| Flight sessions | The educational record: sim and real stick time |
| Equipment check-outs | Squadron gear accountability |
| Instructor assignments | Who may view a student's record |
Never collected: off-duty location data, personal contact details, birthdates, discipline records, or any non-educational metadata. Personal squadron/gear data lives in a separate, isolated workspace that institutional roles cannot reach.
Tenancy isolation
Districts → schools → memberships. Every piece of institutional data is scoped to its district, and the access check is a single rule: same district, or no access. A District A user, whether student, instructor or admin, cannot query, view, or touch District B records. The rule is enforced by BeaconUAV itself, not the app, so a bug in the UI cannot leak across tenant schools.
Role matrix
| Role | Can do |
|---|---|
| Student | View and log their own flights and gear only |
| Instructor | View the students assigned to them (view-only) |
| School Admin | Manage their school's roster, queue enrollments |
| District Admin | Create schools, assign staff, archive members, aggregate dashboards |
District admin dashboards are aggregate-only: counts and totals, never per-student rows. Opening an individual student record is a deliberate, separately-audited action.
Every record access is logged
When staff open a student's educational record, the access is written to an access log: who, which student, the relationship that authorized it, and when. The log is append-only from the application's point of view: no client-facing role can insert, edit or delete entries, and even identity severing (for erasure requests) is restricted to platform staff. Log access is restricted to security review.
"Permanent" here means the application never offers a path to remove a record. Immutability against a database administrator, retention for a stated period, and off-site copies are properties of the hosting arrangement, not of this code; see Controls you can verify below for what to request as evidence.
Records lifecycle
- Export: a student's educational record (sessions, stats, checkouts) can be assembled into a structured export on district request.
- Archive: ending a membership preserves the record (FERPA retention) while ending all access.
- Contract termination / year rollover: district data can be purged; identities are pseudonymized before deletion so no backup snapshot ever contains a usable student identity.
Encryption & residency
Data is encrypted in transit and at rest, and the project is hosted in U.S. regions. These are properties of the platform and of the specific hosted project rather than of this repository, so they are stated here as provider-asserted and should be confirmed against the project's own settings before they are relied on contractually:
- In transit: HTTPS everywhere, with HSTS on the application origin; object downloads use short-lived signed URLs rather than public buckets.
- At rest: provider-managed encryption for the database and object storage.
- Residency: the project's region and its backup configuration, read from the project rather than assumed from this document.
- What this repository does guarantee: private buckets, per-object authorization on every download, and no plaintext student data on a device transport used beyond the browser's own cache (which is cleared on sign-out).
Record the date and the project evidence for each line above when a district asks; the security assessment lists the infrastructure claims that still need that evidence.