Collect less
BridgeBack needs to know which earlier ideas support the lesson. It does not need medical details, family circumstances, or the reason for absence.
Support a pupil without building a profile of them.
BridgeBack minimises data, separates responsibilities, and keeps educational decisions with the teacher.
The guiding principle
Use what the lesson needs. Leave everything else out.
A learning route should not require a detailed account of a child's life or reason for absence.
Start with the child’s interests.
Pupils may have limited choice over technology selected by a school. Privacy, agency, transparency, and human support must therefore be product requirements.
Keep teachers responsible
Generated structures begin as drafts. A teacher approves the graph before it can shape a diagnostic.
Do not infer hidden traits
The system does not infer emotion, motivation, disability, behaviour, or safeguarding risk from responses.
Avoid identity in model work
Lesson analysis uses curriculum material without pupil names, attendance histories, Clerk details, or absence reasons.
What the AI sees at each stage
The AI gets only the information it needs for that job. It does not receive pupil identity, decide marks, or choose the learning route.
Lesson analysis
Needed
Upcoming lesson, objectives, source text or supported lesson files
Excluded
Pupil name, absence record, reason for absence, diagnostic history
Result
Draft concept graph with source references
Diagnostic creation
Needed
Teacher-approved concept graph and references
Excluded
Pupil identity, selected answers, attendance information
Result
Closed questions, options, and correct indexes
Choosing the route
Needed
Approved concept map plus the correct or incorrect results
Excluded
An AI opinion about the pupil
Result
Up to three concepts chosen by BridgeBack code
Micro-lesson creation
Needed
Approved concept path, source context, concept key, and correctness
Excluded
Pupil name, selected option, reason for absence
Result
Explanation, example, and closed check
BridgeBack does not collect free-form pupil chat, precise location, contacts, biometrics, photographs, audio, health information, family information, safeguarding records, or absence reasons.
How access is checked
Hiding a page is not enough. BridgeBack checks a person's identity and school access again whenever protected data is read or changed.
Sign-in and school access
Clerk handles sign-in. Convex then checks that the person belongs to the right school before protected work can continue.
Separate school workspaces
Organisation-scoped access prevents a teacher or pupil from opening another school's classes, lessons, or pathways.
Secret keys stay private
Clerk, Convex, and OpenAI keys stay on the server or inside the service settings. They are never sent to the browser.
Private resources
Lesson files remain in managed private storage. Browser uploads are size and type checked and are never placed in the public directory.
Audit evidence
Administrative actions create append-only events without copying tokens, request bodies, or lesson content into the audit record.
Sending and storing data
Production deployments require HTTPS. Clerk, Convex, OpenAI, and the hosting platform provide managed encryption controls.
AI generation is separated from educational decisions.
Models help transform source material into inspectable drafts. They do not authorise access, grade responses, choose sanctions, or approve their own work.
Draft, then approve
The concept graph is saved as a draft and cannot drive a pupil diagnostic until a teacher approves it.
Validate every structure
Zod Structured Outputs constrain fields. Application checks reject invalid references, cycles, and unsupported shapes.
Mark with fixed rules
BridgeBack compares each response with the correct answer saved by the teacher. The AI does not decide whether a pupil is right.
Choose steps with fixed rules
BridgeBack follows the approved concept map and shows no more than three next ideas.
Preserve sources
Concepts and micro-lessons retain references so a teacher can compare generated content with lesson material.
Keep big school decisions out
BridgeBack cannot decide grades, sets, admissions, exclusions, sanctions, safeguarding referrals, or access to teaching.
OpenAI request controls and their limits
BridgeBack reduces persistence, but it does not describe store false as Zero Data Retention.
Store false
OpenAI requests use store false, so the response is not kept as saved application history in the Responses API.
Request-scoped files
Lesson files are sent as request inputs rather than created as persistent OpenAI File objects.
Hashed safety identifier
A SHA-256 hash of the authenticated subject is used instead of sending the raw Clerk identifier.
What store false does not mean
OpenAI's standard safety-monitoring retention may still apply. Some personal data about under-18s requires approved Zero Data Retention controls first.
What every school rollout must put in place
Responsible use starts with named owners, tested controls, clear information, and approval from the right people.
Complete a child-specific DPIA and establish the lawful basis for every purpose.
Write down who is responsible for each use of data across the school, BridgeBack, and its service providers.
Set clear time limits for keeping data, and build deletion, export, correction, and school offboarding tools.
Configure appropriate OpenAI retention controls for the pupil ages and data involved.
Run security reviews, penetration tests, software checks, and tests that prove one school cannot see another school's data.
Publish age-appropriate privacy information and a clear human help and reporting route.
Evaluate curriculum quality, accessibility, and unequal performance across pupil groups.
Obtain named safeguarding, privacy, security, and education approval.
More information
This page explains our product choices. It is not legal advice, and a school rollout needs expert review.