Privacy & Data Architecture

Built around security.
Not bolted onto it.

GradientEdu was designed from the first line of code with one non-negotiable constraint: student data never leaves the closed research ecosystem between the researcher, the school, and the teacher.

λ   λ   λ
🔒
Principle 01

Student names never reach the analysis engine.

At the moment of data intake, student identifiers are separated from scores. Names are replaced with anonymous tokens before any data is processed. The AI engine never sees a student's name — only their response patterns.

Principle 02

Zero retention. Data lives only as long as the session.

Assessment data is processed in temporary server memory and deleted within minutes of report generation. Nothing is written to a permanent database. No student record persists beyond the analysis window.

🏫
Principle 03

A closed ecosystem. Researcher, school, teacher — and no one else.

Data flows only between three parties: the teacher who uploads it, the research pipeline that analyzes it, and the school that authorized the pilot. No third-party data sharing. No advertising. No external access.

📋
Principle 04

FERPA compliance is architectural — not a policy document.

Most platforms write a FERPA policy after they build the product. GradientEdu's FERPA compliance is the product. The data flow itself makes violations structurally impossible.

🔑
Principle 05

Authentication before anything.

The research application is fully behind a login wall with JWT-secured routes. No data, no analysis, no output is accessible without authenticated credentials. Every session is verified independently.

🚫
Principle 06

No student data ever reaches a third-party AI.

The Anthropic API powers language generation in the pipeline. Student names, scores, and identifiers are stripped before any prompt is constructed. The AI receives anonymized patterns only — never student records.

How data moves through
the research pipeline.

Every step in the data flow is designed to minimize exposure, strip identifiers early, and leave nothing behind. Here is exactly what happens from upload to output.

1

Teacher uploads assessment data

The teacher exports a CSV from their gradebook or SIS — rows are students, columns are items. This file is uploaded directly to the secure research server over encrypted HTTPS.

Encrypted in transit
2

Names stripped at intake

The first operation on every uploaded file is identifier separation. Student names are replaced with anonymous tokens. The name column never enters the analysis pipeline.

Names never reach AI
3

PCA runs on anonymized response matrix

Principal Component Analysis and SVD decomposition are applied to the anonymized item response matrix in temporary server memory. All computation happens server-side in an isolated session.

In-memory only
4

Report generated and delivered

The diagnostic report is returned directly to the authenticated teacher. The output contains anonymized profiles that the teacher maps back to their own roster — locally, never on the server.

Teacher-side mapping only
5

All session data deleted

Upon session completion, all temporary files are deleted from server storage. No student record, no score, no identifier persists. The server retains no trace of the analysis.

Zero retention confirmed

This is not a compliance checkbox.
It is the architecture.

The Family Educational Rights and Privacy Act (FERPA) requires that educational institutions protect the privacy of student education records. Most EdTech platforms achieve FERPA compliance through policy — terms of service, data processing agreements, and privacy notices.

GradientEdu achieves FERPA compliance through architecture. Because student names are stripped before analysis, because data is never written to a persistent database, and because the ecosystem is closed between researcher, school, and teacher — there is no mechanism by which a FERPA violation could occur. The data flow makes it structurally impossible.

This was not a retrofit. It was the design requirement that preceded every other build decision.

Student names never reach AI processing
Zero persistent student records
Closed ecosystem — no third-party data sharing
Encrypted in transit (HTTPS)
JWT authentication on all protected routes
Session data deleted post-analysis
No advertising. No data monetization. Ever.

Questions about data handling?
Ask directly.

GradientEdu is an independent applied research project. The researcher is directly accountable for every data handling decision. If you have questions about how your school's data would be managed in a pilot, reach out.

Data Privacy Inquiry →