The life of the data, start to finish

Default behavior: nothing expires on its own. Rows stay in the school's Sheet until someone deletes them; device-local records stay in the browser until erased or until the browser's own site-data policies clear them.

Recommendations:

• Review at year end. Put a calendar entry in June: decide, class by class, what the coming year's teachers actually need.
• Archive or delete synced rows per your records schedule. These rows are education records under your district's records-retention schedule; treat them as you treat any other student record of the same kind. If your schedule calls for archiving, export the Sheet (File › Download) into your records system and then delete the live rows.
• Keep the live Sheet small. A Sheet holding only the current year is easier to reason about, easier to audit, and a smaller exposure if editor access is ever misconfigured.

Sheet rows (synced records)

The school deletes them — the rows are the school's records, in the school's Sheet, and any Sheet editor can delete them at any time: select the rows, right-click, Delete rows. For a whole-year purge, export first if your records schedule requires it, then delete the data rows (keep the header row — the script expects it). Deletion in the Sheet is subject to Google's own version history; see section g.

Device localStorage (the browser's own records)

The on-page Erase button clears what the app stores in that browser. A fuller sweep is the browser's site-data clear: Settings › Privacy › Clear browsing data (choose "Cookies and site data" for architectureofgrace.org). On managed devices, IT can force this — see section d.

What the founder can delete

Nothing — because he holds nothing. There is no operator copy to request deletion of. A deletion request sent to the founder can only be answered with: delete the rows in your own Sheet, and erase the device. That is not a limitation of the deletion path; it is the deletion path.

The request goes to the school — the school is the records custodian, and the ordinary FERPA request path applies. The founder cannot fulfill a records request because he has no records.

How a school produces a student's rows:

1. Open the Sheet and use Data › Create a filter on the student-code column; filter to the student's code (from your roster mapping).
2. Copy the visible rows into a new Sheet or document, or print the filtered view (File › Print prints what the filter shows).
3. Check each instrument's tab — home check-ins, daily check-ins, and reflections land in separate tabs, and a complete response covers all of them.
4. Include the school's explanation of what the domain scores mean; a bare number is not a meaningful disclosure to a parent.

Records on a classroom device (anything not synced) can be shown to the parent from the device itself, or printed with the app's own print views.

The rule for any shared device: end the session with the on-page Erase button, so the next student does not inherit the last student's work. Build it into the routine the way you build in logging out.

Note the trade: a device that clears at sign-out keeps no local history, so anything the school wants longitudinally must be synced before the session ends. That is the intended division — the Sheet is the record, the device is the workspace.

The prevention is worth more than the cure: the Sheet should live in an organization-owned account from day one — a role account or the district's admin account, not a personal teacher account. If it already does, a teacher's departure barely touches this system. If it does not, run this now, not at departure:

1. Transfer Sheet ownership to the organization account (Share › transfer ownership), or copy the Sheet into the organization account if transfer is not possible across account types.
2. Redeploy or re-key the Apps Script. The Web App executes as its deploying user; a deployment made by the departing teacher should be replaced by one deployed from the organization account (the setup guide's steps 2–4, run once in the new account's copy).
3. Rotate the write key — change BACKEND_AUTH_KEY in Script properties. Old links stop working the moment you do; that is the feature. Any link the departing teacher generated, wherever it now lives, is dead.
4. Re-issue classroom links from a dashboard connected to the new deployment and new key, through your own channels.
5. Rotate the pull key (ADMIN_PULL_KEY) as well if the departing teacher held it, and re-enter it on the staff computers that read results.
6. Record who now holds the admin pull key — write the names down where the district AoG lead and IT can find them. An unrecorded key holder is the gap every later audit falls into.

Name a district AoG lead. One named person holds the key inventory: which Sheets exist, who owns each, who holds each write key and each pull key, and when each was last rotated. Custody that belongs to "the team" belongs to no one.

Treat every classroom link like the key itself. Classroom links carry the write key inside them — that is how a student Chromebook posts without signing in. It also means the key lands everywhere links land: browser history, chat logs, email threads, and LMS link stores. So:

• Distribute links through channels scoped to your own students, never on a public page.
• Assume any link that left your controlled channels is compromised, and rotate.
• Remember the blast radius is bounded: the write key can only append rows — it cannot read, change, or delete anything. A leaked write key means the risk of fake-looking rows, not exposed students. The pull key is the one that reads data back; it never rides in a link and should be held by the fewest possible people.
• Rotate the write key on a schedule (each term is reasonable), at every staff departure, and on any suspicion. Rotation is cheap: change the Script property, re-enter it in the dashboard, regenerate links.

Be clear-eyed about what a Google Sheet is: rows are editable by anyone with editor access to the Sheet. There is no append-only ledger, and a determined editor can alter or delete records without the app knowing. The honest mitigations:

• Restrict editor access to the smallest set that genuinely needs it — usually the AoG lead and IT. Staff who only read results need the pull key, not Sheet editor rights; staff who only administer instruments need neither.
• Use Sheets version history (File › Version history) as your audit trail — it records who changed what and when, and allows restoration. It is Google's history, subject to Google's retention of it, and it is the audit mechanism this design actually has.
• For records your schedule requires you to hold immutably, export to your records system on your archive cadence; the Sheet is the working store, not the vault.