You deleted the student, and the next roster sync put them back

A student who reappears after being deleted has taken one of four routes back, and the fix for each is different: the upstream roster re-created them on the next import, a downstream copy never received the deletion, a restore brought the row back, or a derived artefact still holds the content under a different key. Running the delete job again resolves none of them, and it hides the evidence you need.

So the first job is a measurement rather than a remediation. Deletion in a system with an upstream source of truth and half a dozen downstream copies is a distributed operation, and the question worth answering is which participant did not play its part. Two probes settle it.

The probe: check every store twice

Delete one test student, then run an existence check across every store you own — immediately, and again after the next scheduled import. The pattern across those two checks names the cause without any further investigation.

1. Enumerate the stores first: Postgres or whatever the primary database is, the search index, the cache, the warehouse, the vector store, object storage holding exports and generated documents, queues with unprocessed events, and any device-side copy. On a typical build that is 7 or 8 destinations.
2. Record the student's identifiers in every form they appear — internal id, source system id, email, and any hashed variant — because a store that missed the delete usually keyed on a different one.
3. Run the delete through the same path a real request would take, not through a console. A console delete tests a code path nobody will use again.
4. Probe every store immediately. Anything present now was never deleted, and that is an incomplete-deletion problem confined to that store.
5. Wait for the next scheduled sync — most run nightly, between 01:00 and 03:00 local time — and probe again. Anything absent at the first probe and present at the second was re-created by an upstream import.
6. Record both results per store in a table. It is the evidence a school's reviewer will ask for, and it is faster to produce now than to reconstruct after the second complaint.

Re-created by the upstream roster

This is the most common answer, and it is not a bug in your importer. The student information system is the system of record; your product holds a projection of it. If the student is still in the feed — through OneRoster, a connector such as Clever or ClassLink, a direct pull from PowerSchool or Banner, or a nightly file drop — then every import correctly re-creates what the source says exists. The transport itself is a separate subject, covered by direct SIS pull versus a managed roster sync.

The design answer is a tombstone the importer consults before it creates anything. Keep the tombstone minimal: a salted hash of the source system id, the deletion timestamp, the requesting institution, and the reason class. That is enough to recognise a returning row and refuse it, without retaining the identifiers you were asked to remove — and the salted hash matters, because an unsalted one over a small, guessable identifier space is not much protection, for the same reason set out in why removing names does not de-identify a class of eleven.

• Decide who is allowed to lift a tombstone, and make it an explicit action with a recorded reason. Students legitimately return — a withdrawal reversed, a transfer that fell through.
• Surface refused rows in the sync report. A silent skip looks identical to a broken integration when the school's data lead is counting seats.
• Distinguish deletion at the institution's request from a student simply leaving. They have different triggers, different clocks and different reversibility, which is the distinction retention clocks per record type exists to hold.
• Watch what re-creation does to access. A resurrected student reappears in section membership and caseloads, which quietly re-grants permissions — a variant of staff being able to see students outside their caseload.

Never deleted: the copies that never got the message

The second family is quieter, because nothing reappears in the interface. The row simply never left one of the derived stores, and it surfaces later in a report, a search result or an export.

• Warehouse and analytics pipelines that replicate inserts and updates but treat deletes as an edge case. Append-only loading into Snowflake or BigQuery is the usual shape, and it needs an explicit delete propagation rather than an assumption.
• Search indexes and caches, which are rebuilt from sources rather than mutated, so a delete has to be a positive action against them.
• Embeddings and any fine-tuning corpus. Content that entered a training or retrieval pipeline needs its own removal path and, for training in particular, may not be removable at all — which is why the decision about what may enter one has to be taken first: can student work train the model, and where the line sits.
• Generated artefacts: PDF reports, exported spreadsheets, emailed attachments and scheduled dumps sitting in object storage under a filename nobody indexes by student.
• Copies on devices. A spreadsheet a teacher exported and a cached record inside an app on a personal handset are both outside your deletion path entirely — the exposure described in staff using personal phones for school work.

Restored: backups, and the honest way to describe them

Backups reintroduce deleted rows by design, and no architecture removes that property. Rewriting historical backups to excise one student is both technically fragile and self-defeating, because it undermines the integrity the backup exists to provide. The workable position is that deletion from backups happens by expiry, and any restore is followed by a re-application of the deletion log.

Suppression or deletion: pick one deliberately

Both are legitimate. Calling one by the other's name is not, and it is the specific thing that costs an institution's trust when it comes out.

Deleting a student is not a statement about one table. It is a claim about every copy, including the ones built by people who were not in the room when the request arrived.

What to build so this is answerable next time

1. A deletion service, not a delete button. One entry point that fans out to every store, records what it touched, and reports partial failure loudly instead of returning success.
2. A store registry that the deletion service iterates over, so adding a new store means registering a deletion handler rather than remembering one.
3. A tombstone table with a lifting procedure and an owner.
4. An automated test in continuous integration: seed a student, delete them, assert not-found across every registered store, and fail the build if any store answers otherwise. This is the check that keeps the guarantee true after the fourth new data pipeline.
5. A deletion receipt for the institution: what was deleted, when, from which stores, what is suppressed rather than deleted, and the date the last backup copy expires.

That receipt is usually the most valuable artefact in the whole exercise, because it converts an argument into a document — and building the fan-out, the registry and the report is exactly the kind of narrow internal system we scope under internal tools and ops. Where transcripts and logs fit into the same deletion path is covered separately in a records request that came back with assistant transcripts. The rest of this silo sits under student data privacy, engineered, within our education and edtech work.

• student privacy
• data deletion
• roster sync
• data architecture