IEP Casemate · District review
District procurement
Student data handling
Where personally identifiable information enters Casemate, how it is stripped, when it is deleted, and what remains on the caseload record. Last updated: September 19, 2026.
Document pipeline
Applies to IEP, assessment, student work-sample, and lesson-plan PDFs. Each step is enforced in Cloud Functions, not in the browser.
- Step 1
IEP uploaded
An educator uploads an IEP, assessment, work-sample, or lesson PDF. The file is written to encrypted Google Cloud Storage for processing only. A full name may be sent in object metadata so the stripper can match it; that name is not stored as a caseload field.
Next: PII stripped
- Step 2
PII stripped
Google Document AI reads the PDF in memory. Server-side stripping then replaces the student name with initials and redacts SSN-like patterns, phone numbers, email addresses, and street addresses. School names, when supplied, are replaced with [SCHOOL]. IEP date fields needed for service timelines are kept after the name is reduced to initials.
Next: Data processed
- Step 3
Data processed
Only the cleaned text is used for extraction or storage. AI prompts are built from de-identified data and pass a second structured PII scrub before they are sent to Vertex AI. Google Cloud terms prohibit using this customer content to train models.
Next: PII deleted
- Step 4
PII deleted
The source PDF is deleted from Cloud Storage after processing. For IEP jobs, the temporary OCR text and name-variant fields are then removed from the processing record so they do not remain after extraction completes.
What is deleted vs. what remains
Deleted after processing
Source PDFs
IEP, assessment, work-sample, and lesson files are deleted from Cloud Storage after processing.
Full names
Used only during stripping (upload metadata and name matching). Not stored on the student record.
Direct identifiers in text
SSN-like patterns, phone numbers, emails, and street addresses are redacted before persistence.
Transient OCR payload
IEP job documents drop cleanedText and nameVariants after extraction completes.
Retained on the caseload
Student identifier
Initials only (for example, J.M.). Full names are not a caseload field.
Program data
Grade, IEP goals, services, accommodations, schedules, and timeline dates.
Optional transition field
Birth month only, used to calculate secondary-transition timelines. Full dates of birth are not collected.
Evidence of instruction
Service logs, progress statements, and meeting-prep drafts linked to initials and goal IDs.
Extracted document text
PII-stripped OCR text from work samples or lesson materials. The PDF is not kept.
Assessment results
Type, date, scores/percentiles, and domains. The source PDF is not kept.
Named exceptions — no hidden residual data
Two paths sit outside the automatic strip-and-delete pipeline. Both are disclosed in the product and on this page. They are not silent leftovers.
| Exception | What happens | How you see it | Residual exposure |
|---|---|---|---|
| Failed IEP or assessment upload | If processing stops before the delete step, the encrypted source file stays in Cloud Storage. Work-sample and lesson PDFs are deleted even when OCR fails. | The educator sees a failed job and a notice that the PDF was not deleted, with a retry action. The job is not marked complete. | Same teacher/school/district access controls as the rest of the account. Cleared by a successful retry or by student/account deletion of the uploads/ prefix. Not written into the caseload record. |
| Family-portal files | An educator may share a copy with a family. That copy is kept as uploaded — it is not OCR’d or PII-stripped — so the family can download the file they were meant to receive. Parents cannot upload files. | The share screen states the file is kept as-is until the educator removes it or the student/account is deleted, and warns not to share a full IEP unless district policy allows it. | Intentional, educator-initiated, and scoped to that portal link. Deleted with the student or account (storage prefix parentPortals/{portalId}/). Not mixed into AI prompts or the caseload strip pipeline. |
Districts review this table on this page, in the Trust Center procurement package, and in security questionnaires. In-product notices match this language so a teacher and a privacy officer see the same exceptions.
Controls that make this happen every time
Server-side only
Upload processing, PII stripping, source-file deletion, and student/account deletion run in Cloud Functions. The browser cannot skip a step or rewrite the audit log.
Minimized student records
Teachers enter initials, not names. Firestore rules and callable authorization keep access inside the teacher, school, or district that owns the record.
Second AI scrub
Prompts to Vertex AI are built from de-identified caseload data and pass an additional structured PII scrub (phone, email, address, SSN-like patterns) before they leave Casemate.
Encryption and region
TLS 1.2+ in transit; data encrypted at rest by Google Cloud. Default AI processing is pinned to a configured Google Cloud region under the Google Cloud DPA.
Deletion verification process
Casemate does not keep the original identifiers in order to prove they were removed. Verification is by immutable process logs and audit records, which a district can request under the DPA.
- Per-upload function log. After stripping, the processor writes a Cloud Logging entry with the count and categories of items removed (for example, “student name → initials”, “phone number”). The log stores categories, not the underlying values.
- Per-upload deletion log. After the Cloud Storage object is deleted, the processor logs the storage path (IEP: “Deleted processed IEP file”). Work-sample and lesson uploads delete the object in a finally block so a failed OCR still does not leave the PDF.
- IEP job field deletion. When extraction completes, the processing job removes the temporary OCR text and name-variant fields. The job result that remains is initials, goals, services, and related structured fields — not the source document.
- Student deletion audit. Deleting a student cascade-deletes nested records (documents, assessments, lesson materials, activities, tutor sessions, and related evidence) and writes a server-side
student_deletedaudit event with actor, owner, and resource path. - Account deletion audit. A confirmed account deletion request wipes user subcollections and remaining storage prefixes (
uploads/,assessmentUploads/,workUploads/,lessonUploads/), then writesaccount_delete_requestandaccount_deleted. Account data is deleted within 30 days of a valid request, except where retention is required by law.
Audit log (what districts can request)
A server-side audit record is written for student-record changes, deletions, and transfers; delivery-evidence exports; student audit-folder views; leadership student rosters, delivery records, and every session note a leader opens; gap status changes; and access to leadership reports, forecasts, and analyst answers. Records cannot be written or altered from the browser. Districts may request audit records for their organization under the signed DPA.
Failed uploads and family-portal copies are listed in Named exceptions so they are not treated as silent residual PII.
See also the Trust Center, Security & Data Practices, Privacy Policy, and DPA. Questions: privacy@iepcasemate.com.