Student data

Where the data goes, stated plainly

Real student work moves through this system. This is the honest version of our posture, including the parts most vendors leave out.

§ 1

What we do

Identifiers are stripped before any submission is sent to an AI provider. The model sees the work, not the student.
Isolation per instructor and per organization, enforced on every request by the application.
An audit trail of who accessed what, and automatic cleanup of temporary files that contain student work.
Deletion on demand. A grading job and everything it produced can be purged.
A fully local option. Point the platform at a model running on your own hardware and no submission leaves your network.

§ 2

What we will not claim

FERPA-aligned, not certified

There is no FERPA certification to hold, so we do not say we have one. Your institution should run its own assessment against its own deployment, and we will hand over whatever detail that takes.

Cloud providers see de-identified work

When a cloud provider is selected, de-identified submission content is sent to that provider for evaluation. That is a real trade-off. It is why the local option exists, and it is set per function rather than once for the whole platform.

Isolation is in the application today

Database-level row security arrives with the move to PostgreSQL. Until then the isolation is enforced by the application, and we would rather say so than imply otherwise.

§ 3

Choosing where the AI runs

Setting	What leaves your network	Good for
Local model	Nothing	Programs with strict data rules, or work you would not send anywhere
Cloud provider, per function	De-identified submission content, for that function only	Judgements that need a larger model, such as essay feedback
CourseOps on a laptop	Only what you choose to send to your own AI account	An instructor building a course alone

Questions from your IT or compliance office are welcome before a pilot starts. Request a pilot and say that you would like a data review first.