FairCall MVP Data Flow Map (Pilot Template)
Last updated: February 18, 2026

Purpose
- Provide a school-ready, implementation-grounded map of personal-data flows for pilot DPIA review.
- Scope: FairCall MVP (Sprints 1-15), teacher-facing workflows only.

Data Classification
- Controller (typical school deployment): School/Trust
- Processor: FairCall
- Data subjects: Teachers and students (students do not login)

Flow 1: Teacher authentication
1) Teacher submits email + password in app.
2) Backend validates credentials and issues JWT.
3) Token stored client-side for authenticated API requests.
4) Password remains hashed at rest in backend datastore.

Data handled
- Teacher email (personal data)
- Password hash (credential derivative)
- Auth metadata (timestamps, token claims)

Flow 2: Class and student setup
1) Teacher creates class.
2) Teacher adds students manually or via CSV import.
3) Optional student ID and photo URL may be stored.

Data handled
- Class name
- Student name
- Optional student external ID
- Optional student photo URL

Flow 3: Live lesson operations
1) Teacher starts lesson for class.
2) Ask events are appended per selected student.
3) Outcome logging is optional.
4) Undo removes most recent ask event (append-only-consistent behavior).
5) Lesson end captures duration/count metadata.

Data handled
- Lesson timestamps
- Student selection events
- Optional outcomes (correct/partial/incorrect/none)
- Lesson absence markers

Flow 4: Analytics and pilot metrics
1) Frontend emits schema-scoped analytics events.
2) Backend validates/normalizes and persists accepted events.
3) Internal pilot report aggregates metrics from raw events.

Data handled
- Teacher/class/lesson identifiers (UUID)
- Timing metrics (for performance and adoption KPIs)
- No student names in analytics payloads

Flow 5: Support and feedback intake
1) Teacher opens in-app issue/feature flow.
2) Structured payload captures context (route/device/network/timezone).
3) Optional screenshot may be attached.
4) Submission stored in authenticated support requests table.

Data handled
- Structured support metadata
- Optional screenshot payload
- No free-text notes in MVP support schema

Flow 6: Export, sharing, and deletion
1) Teacher can export CSV/PDF/PNG where applicable.
2) Cover-sharing uses signed token and view-only restrictions.
3) Teacher can delete account/data using in-app controls.

Data handled
- Exported teacher-owned records
- Share token metadata (hashed token storage)
- Deletion confirmation metadata

Storage and transfer map
- Client device: local session state, offline queue, auth token
- API backend (NestJS): processing, validation, auth, ownership checks
- PostgreSQL (Prisma): classes, students, lessons, events, analytics, support
- Optional analytics forwarding: PostHog when configured
- Transport: HTTPS/TLS in hosted production environments

Security and minimization anchors
- Teacher-only tenancy boundaries enforced in backend ownership checks.
- No free-text student notes in UI/API/DB.
- Student-facing app features are excluded in MVP.
- Authentication and role boundaries required for data access.

DPIA reviewer checklist
- Confirm controller identity and lawful basis.
- Confirm retention period and deletion expectations.
- Confirm transfer regions and subprocessor stance.
- Confirm support/incident contact and breach-response workflow.
- Record residual risk and sign-off date.