Storing student data responsibly

The moment a product remembers anything about a student across sessions, a real question follows immediately: remembers what, exactly, and for how long? “We store what’s needed to personalize, nothing more” is easy to say and means very little without specifics. So here’s what that actually means to us in practice, while our full data policy is still being finalized with the people who need to sign off on it.

Remember the pattern, not the transcript

There’s a meaningful difference between “this student struggles with distinguishing horizontal and vertical velocity components” and a verbatim log of every message they’ve ever sent. The first is exactly what personalization needs — a durable, structured signal about where a student’s understanding actually is. The second is a growing pile of raw conversation data that mostly isn’t needed for anything, and is pure liability sitting in a database.

A memory layer built around structured signals — insights, strategies, error patterns — rather than raw transcripts starts from a smaller, more defensible footprint by construction. Not because raw logs were scrubbed after the fact, but because they were never the thing being stored in the first place.

Identity should be derived, not just assigned

A student record needs to be found reliably the next time that student shows up — but it doesn’t follow that the identifier needs to be a database row someone could enumerate or guess. Deriving a student’s identifier deterministically from information only their own organization holds, in a way that can’t be reverse-engineered from the identifier alone, is a small design choice with an outsized effect: identity becomes something a system can compute correctly, not something that has to be separately protected as its own leak surface.

Deletion has to actually mean deletion

Committing to “we can delete a student’s record” only means something if deletion is a real, tested operation — not a soft flag that quietly leaves data behind in a cache, a backup, or a downstream index. If a platform can’t tell you exactly what disappears when a deletion request comes in, the commitment isn’t complete yet, no matter how it reads in a privacy policy.

Fewer people should ever need to look

The best access control for sensitive student data is usually not “who’s authorized to view it,” but “how rarely does anyone need to view it at all.” A system built so that personalization happens automatically — without a human ever needing to browse a dashboard of individual students’ struggles to make it work — needs far fewer people with access in the first place. Fewer people with access is a stronger privacy property than a longer list of people who are merely trusted with it.

None of this is a substitute for a real, specific, published policy — retention windows, sub-processors, the exact legal basis for processing, all of it. That’s coming, and it’s being written carefully rather than quickly, precisely because a document like that shouldn’t be filled in loosely and fixed later. These are the principles we’re writing it around.