A records request came back with assistant transcripts nobody could redact

Assistant transcripts became part of the education record the moment they were stored and could be traced back to a named student. Nothing had to be decided for that to happen, which is exactly why nobody noticed: logging is infrastructure work, and infrastructure work is not where anyone expects a records classification to change. The request that surfaces it — a parent asking to inspect, a student asking for deletion, a district asking what you hold — simply reads the boundary as it actually is.

The observable is always the same. Someone asks for everything you hold about one student, and the team can produce the obvious tables in an hour and then spends a week arguing about conversation logs, error payloads and an analytics warehouse nobody has looked at since it was built. That week is the finding. Where the boundary sits legally is the institution's counsel's call under FERPA and, for younger learners or European operations, the applicable child-data rules. What is yours is knowing which stores are in play — and the definition work behind that sits in where the education record starts and stops, in the schema.

Inventory the logs by resolvability, not by system

The useful question is not whether a store is a student data store. It is whether a row in it can be resolved to a named student using joins you control. Two hops still count: a transcript keyed only by session id is resolvable if a login event 200 milliseconds earlier in another log carries the same session id and a user id. Teams call that pseudonymous. A records request does not.

1. List every destination a request can write to: application logs, the conversation store, the error tracker, analytics, the data warehouse, search and vector indexes, message queues, object storage, session replay, and anything the model provider retains.
2. For each one, take a real row and try to reach a named student from it using only systems your team can query. Write down the join path and how many hops it took.
3. Grep a week of each store for the identifier formats that actually appear in your product — student number patterns, email domains, the local phone format — because free text is where the surprises live rather than in structured columns.
4. Record who owns each store, its current retention setting, and whether a deletion request today would reach it.
5. Mark every store where the answer to the resolvability test is yes but the retention setting was chosen by whoever set the tool up. That intersection is the actual exposure.

That last row deserves its own reading, because a no-retention term does less than teams assume and covers fewer paths than they check — what a no-retention term actually covers walks through the three places data still lands.

How identifiers actually get into a log

Ranked by how often they turn out to be the culprit, rather than by how alarming they sound.

• Authenticated sessions logged verbatim. The transcript is written with the user id attached because that is what makes the conversation resumable. Entirely reasonable, and it is the single largest store in scope.
• Identifiers typed into free text. A student writes their own name, roll number and date of birth into a question about fees; a staff member pastes a whole email thread. No schema anticipates this, and no column-level rule catches it.
• Third-party observability. Error trackers capture request bodies by default, and one unhandled exception in the message handler copies a conversation into a system with its own retention, its own access list and its own subprocessors.
• Prompt and response caches. A cache keyed by prompt hash still stores the prompt, and caches are usually built for latency by someone who was not in the privacy conversation.
• Analytics payloads. Someone adds question text to an event so the product team can see what people ask, and the education record quietly acquires a copy in a warehouse with a different access model — which is also how staff end up able to see students outside their caseload through a reporting view.

Redact at write, tokenise, or do not log it

Every store in the inventory resolves to one of three answers. Choosing per store is the work; choosing one answer for everything is what produced the problem.

Producing the export when the request lands

Two structural problems make transcript exports harder than table exports, and both are cheaper to solve before a request arrives than during one.

1. Segment at the utterance, not the thread. A conversation between a staff member and an assistant can name several students, and an institution releasing records to one family usually releases only the part relating to that student. A thread stored as a single blob cannot be split under time pressure.
2. Attach the subject of each utterance where it is known — which student the message is about, not just who typed it. Author and subject are different fields and only one of them is on the session.
3. Keep retrieved passages alongside the answer. If the assistant quoted a record back to someone, the export needs to show what was disclosed, and that is not reconstructable later from a prompt template.
4. Rehearse it. Pick a test student, run the full export across every store in the inventory, and time it. A rehearsal that takes 6 hours is a system that works; one that takes 3 days is a system that will fail its first real request.
5. Write down the stores deliberately excluded from the export and why, and have that list reviewed by whoever answers the institution's questionnaires. Silence about an excluded store is what turns a routine request into an incident.

A log is not outside the education record because it was written by a framework. It is inside the moment somebody can start from a row and end up at a child.

What to change in the build

• Make the log destination list a reviewed artefact. New destinations are added constantly, and a list that is not owned goes stale within a quarter.
• Enforce the classification in continuous integration: a new field on an event schema that carries free text should fail the build unless it is declared and treated.
• Set retention per store deliberately rather than accepting a vendor default of 30 or 90 days, and hold the deletion path to the same standard as the primary database — the failure pattern when you do not is deleted student records reappearing after the next sync.
• Push logging configuration into the deployment rather than the code, so an institution can lower it. Where the product is installed centrally through Jamf or Intune, that belongs in the managed configuration — the same surface as shipping an app a school can deploy silently.
• Keep retention scheduling itself where it belongs, as a per-record-type policy with a named clock owner rather than a global number: retention clocks per record type covers that decision.

None of this is expensive if it is decided at design time and most of it is painful afterwards, which is the honest argument for treating logging classification as part of the first build rather than a hardening pass — the way we scope MVP and product builds for institutional buyers. The rest of this silo sits under student data privacy, engineered, within our education and edtech work.

• student privacy
• logging
• records requests
• assistant design