Children's data and safeguarding

The school is the data controller for every pupil record held here. We are a processor acting on the school's instructions. Consent and the lawful basis for holding children's work sit with the school and, where relevant, parents and carers — never with the pupil, and never with us.

Pupils are records, not users. Children do not have accounts and cannot sign in. Every user of the service is a member of school staff.

Photographs or scans of pupil writing, the pupil's name, class, year group, an optional UPN, optional group markers the school chooses to record, the tags and comments teachers add, and the teacher's assessment judgement and rationale.

Children's writing is unusually revealing. A story can carry a disclosure, a home circumstance, or a sign of an unidentified need. We treat every scan as if it might.

Every child whose work appears here is under 11 and many are under 7, so the ICO's Age Appropriate Design Code applies at its highest standard. In practice: no profiling of children, no nudge techniques, no advertising, no third-party analytics on pupil data, and data collection kept to what an assessment portfolio actually needs.

Where a school leaves it enabled, an uploaded scan is sent once to Google's Gemini API to propose candidate evidence regions. The output is a proposal only: nothing enters a pupil's record until a teacher accepts it, and the teacher is recorded as the author of the tag.

Scans are not used to train general-purpose models, by us or by the AI provider under the paid API terms we use. Any transcription produced is stored as low-trust text for search only and is never shown as the thing being assessed. A school can turn AI reading off entirely in Safeguarding → Retention and processing; tagging then works exactly as before, by hand.

Each school sets how long pupil work is kept, defaulting to 36 months — a key stage plus a moderation cycle. Where automatic deletion is enabled, scans and their tags are removed once that period expires while the judgement and its written rationale are kept as the assessment record.

Teachers see full pupil records only for classes they are allocated to. Wider reading is limited to moderators, senior leads and safeguarding leads. Every time a pupil record is opened, a concern is read, or data is exported, an entry is written to an access log that cannot be edited or deleted from within the app.

Any member of staff can flag something they have noticed in a child's writing. The concern goes to the school's designated safeguarding lead, is visible only to them, senior leadership and the person who raised it, and cannot be withdrawn or rewritten — corrections are added underneath. Acknowledgement, escalation and closure are all recorded with the name of the person who acted.

This is a record, not a referral. Urgent matters must still be reported to the designated lead in person, through the school's own procedures.

A school can export everything held about one child as a single file, and can erase a child's record entirely at a parent or carer's request. Erasure removes the scans, the tags and the judgements; only the fact that an erasure happened, and why, is kept.

Pupil data is held in the school's own Supabase project in the EU, with row level security enforcing school and class boundaries at the database, not just in the interface. Scans sit in a private storage bucket and are served only through short-lived signed links.