Purpose and current boundary
This is the operating runbook for a teacher-controlled local or private-network pilot. It turns the app's existing checks into a repeatable routine, but it is not evidence that the service is ready for public registration, subscriptions, Student accounts or Parent/Carer accounts.
The repository and prototype must continue to use fictional demonstration data only. A saved readiness checkbox or school approval record is evidence that a discussion occurred; it does not override that prototype restriction or replace a school recordkeeping, privacy or legal decision.
The current app provides:
- a local SQLite database selected by SQLITE_PATH, defaulting to data/band-licence.sqlite;
- timestamped backups in BACKUP_DIR, defaulting to the git-ignored backups folder;
- optional authenticated encryption for backups;
- backup verification, restore rehearsal and guarded restore commands;
- migration rehearsal and version checks;
- the non-sensitive /api/health endpoint, the /launch status page and Daily Review;
- school-scoped support/correction requests, account-deletion review requests, account audit logs and teaching-record audit logs;
- nine Operations Readiness confirmations in Settings → Global Settings → Operations Readiness.
It does not currently provide a backup scheduler, remote backup service, automated retention/destruction job, legal-hold engine, production monitoring service, public support desk or a command that completes account-and-school data deletion. Those remain operational or product gates.
Owners and separation of duties
One person may hold several pilot responsibilities, but record the role being performed for each action.
| Responsibility | Accountable owner | Operator | Independent check |
|---|---|---|---|
| Teaching records and Daily Review | School Administrator | Teacher or Administrator | Another authorised teacher where practical |
| App access and school roles | School Administrator | Administrator | Quarterly least-privilege reviewer |
| Host, database, backup and update commands | Host Operator | Trusted local operator | School Administrator |
| Retention and disposal authority | School Records/Privacy Delegate | Administrator follows the decision | Principal or delegated approver |
| Support and corrections | Support Coordinator | Administrator | Requester or second teacher confirms result |
| Security/privacy incident | Incident Lead | Host Operator and Administrator | School leadership/privacy contact |
The Host Operator is not an in-app role. Anyone who can read the live SQLite file, backup folder or encryption key can bypass app permissions and must therefore be treated as privileged.
Operating cadence
| When | Required action | Owner | Evidence |
|---|---|---|---|
| Before every live teaching day | Open /launch; check database, schema version, backup freshness and host state; confirm the intended school | Teacher | Launch result and local day checklist |
| After each rehearsal or lesson day | Complete Daily Review, then create and verify a backup | Teacher, then Host Operator | daily_review_signoffs row; backup file and matching JSON metadata; command result |
| Before and after roster, card or major setup work | Create and verify a backup | Host Operator | Backup file, metadata and verification result |
| Weekly during an active pilot | Verify the newest backup and confirm the protected second copy is reachable | Host Operator | Dated operations log entry |
| Monthly during an active pilot | Run a restore rehearsal and review open support/deletion requests | Host Operator and Administrator | tmp/restore-rehearsal-latest.json copied or summarised into the approved operations record |
| At least each school term | Review access, discontinued-student records, retention decisions, backup inventory and recovery contacts | Administrator and Records/Privacy Delegate | Signed review record and decision-register updates |
| Before every build that can change schema | Backup, verify, rehearse migration and obtain go/no-go approval | Release Owner | Migration rehearsal status and release record |
| After staff departure or suspected access error | Disable/restrict access immediately and perform an out-of-cycle access review | Administrator | Account audit log and access-review record |
| After any privacy, integrity or availability incident | Preserve evidence, follow the incident plan and repeat recovery/access checks | Incident Lead | Incident record and corrective-action record |
The generated files under tmp are local status snapshots and may be overwritten. They are useful evidence inputs, not a durable evidence repository. Record the date, operator, result and follow-up in a school-approved register or in the minimal notes fields supplied by the app.
Backup Routine
Start of day
- Confirm the correct host, deployment mode and school.
- Open /launch and check for a blocked database, stale backup or failed restore-rehearsal warning.
- Check /api/health only for non-sensitive host status. Do not add student details to health output or monitoring notes.
- If the database, schema or access boundary is uncertain, stop and escalate before entering records.
- Keep a manual attendance fallback available whenever the host or network is unreliable.
End of day
- Complete the attendance checks and sign-off in Daily Review.
- Resolve or record any missing marks, manual entries, guests, absences, schedule variance and without-instrument marks.
- Run:
deploy\windows\Backup Database.cmd
deploy\windows\Verify Backup.cmd- Confirm the command names the expected database and backup folder.
- Confirm the latest backup opens cleanly and the date is the current Australia/Brisbane teaching date.
- Record any unresolved problem in Settings → School Settings → Support and Correction Log.
Severity and escalation
These are pilot triage levels, not contractual service levels.
| Severity | Examples | Immediate action | Escalation target |
|---|---|---|---|
| Critical | Suspected unauthorised disclosure; wrong-school access; live database corruption; lost backup key with no recoverable copy; restore cannot recover required records | Stop affected use, preserve logs and files, do not repeatedly retry, revoke/disable access where safe | Incident Lead, Principal/delegate, privacy/records contact; use the Incident Response Plan |
| High | Backup or verification repeatedly fails; newest usable backup is outside the approved RPO; failed migration; Administrator access unavailable; material import error | Stop risky writes, use manual fallback, create a protected evidence copy, assign an owner | Administrator and Host Operator the same working day |
| Medium | Isolated attendance/progress correction; QR card issue; one user invitation or lockout problem | Open a support/correction record, contain affected workflow, correct through supported UI | Administrator within the pilot response target |
| Low | Guidance, training or cosmetic issue with no data/access impact | Record for planned review | Product/support owner |
Never put raw passwords, invitation tokens, reset links, encryption keys, student family details, raw audio or raw transcripts in an incident or support note.
Retention
Retention must be decided by the school or legal operator before real-world use. Do not copy a period from this guide and treat it as legal approval.
The decision maker must:
- identify the business purpose and record owner;
- determine whether the school is subject to a Queensland disposal authorisation or another legal hold;
- set a trigger, minimum period and disposal action;
- document exceptions for litigation, Right to Information, complaint, investigation, child-safety or incident holds;
- cover live data, exports, temporary files and every backup generation;
- prefer de-identification or destruction once information is no longer needed and no obligation requires retention;
- re-approve the schedule after material feature, hosting, school or legal changes.
For a Queensland government-school deployment, start with the Office of the Information Commissioner Queensland overview of the Queensland Privacy Principles, in effect from 1 July 2025. QPP 11 requires reasonable security and, subject to public-record and other legal requirements, destruction or de-identification when personal information is no longer needed. The OAIC APP 11 guidance is relevant where the legal operator is an APP entity; do not assume the Commonwealth and Queensland regimes apply identically.
Queensland public authorities must also use an applicable disposal authorisation. Start with the Queensland retention and disposal schedule search, the current Education and Training Sector schedule and the Queensland Records Governance Policy, then obtain the school's records advice.
Retention decision register
Create one row for every category below. Decision required means the app does not currently enforce a disposal period.
| Record category | Current location/behaviour | Decision to record |
|---|---|---|
| School profile, settings and release approvals | SQLite; school profile and readiness tables | Owner, retention trigger, export/transfer and disposal approval |
| Staff accounts and school roles | app_users, user_school_roles | Employment/access end trigger, audit needs, disablement versus deletion |
| Account sessions | account_sessions; usable sessions expire after 12 hours, but expiry is not the same as row destruction | Cleanup period for expired/revoked rows and evidence required |
| Invitations and recovery tokens | Invitation 14 days; verification 14 days; reset 24 hours; expired rows may remain | Cleanup period and exception/incident hold |
| Native sign-in handoffs | Code usable for 2 minutes; entries older than 24 hours are removed when a new handoff is created | Whether additional scheduled cleanup evidence is required |
| QR profile sessions | Usable for 30 minutes or until revoked; no general purge job is documented | Cleanup period for expired/revoked rows |
| Student profiles | Current or Discontinued; profiles are preserved by design | School record class, trigger and whether de-identification is permitted |
| Attendance, lesson, progress, Licence, method-book, pass-off and practice records | SQLite teaching records | Applicable schedule class, trigger, minimum period and authorised disposal |
| Printable/exported reports | Outside the database once downloaded or printed | Custodian, storage location, copy control and disposal method |
| Teaching and account audit logs | audit_logs, account_audit_logs | Security/recordkeeping purpose, period and legal-hold rules |
| Support and correction requests | support_correction_requests with Open/Reviewing/Resolved/Dismissed states | Closure trigger, period after closure, minimal-note review |
| Account deletion review requests | account_deletion_requests with Requested/Reviewing/Completed/Denied/Cancelled states | Evidence period and what Completed must prove |
| Delete/undo payloads | delete_undo_events usable for 30 minutes; payload rows are not automatically purged | Short cleanup period and secure disposal |
| Lesson Note Prepared Drafts, teacher-edited Drafts and signed Summaries | A name-minimised Prepared Draft may be stored when a teaching date is opened; stale untouched records are archived, while edited/signed history is preserved | Separate review limits and deletion triggers for each state, correction process and school-approved teaching purpose |
| Lesson Note audio/raw transcripts | Must never be persisted | Immediate discard; any discovery is an incident |
| Backups and metadata | backups as SQLite or encrypted SQLite plus JSON metadata | Generations, on-site/off-site copies, key lifetime, hold and verified destruction |
| Temporary rehearsal/migration files and status snapshots | Temporary database copies are removed; latest JSON status remains in tmp | Operational evidence period and secure cleanup |
For each row record: decision ID, scope, owner, legal authority/schedule reference, trigger, period, action, backup treatment, approved by, approval date, next review date, hold status and evidence location.
Deletion
Important limitation
The current Account Deletion workflow records and audits a request. Changing a request to Completed does not itself erase the account, school records or backups. The app also preserves Discontinued student profiles. Do not claim deletion has occurred without separate evidence of the actual approved action.
Procedure
- Receive the request through the authenticated account flow or an approved support channel.
- Verify identity and authority without collecting extra identity documents in the support note.
- Identify whether the request is account-only or account-and-school-review.
- Find every affected school, live table, export, local file and backup generation.
- Check the retention register and any legal, complaint, incident, child-safety, litigation or records hold.
- Place the request in Reviewing while ownership and retention are decided.
- Create and verify a protected pre-change backup if the approved correction can affect teaching records. A backup is not permission to retain deleted information forever; apply the backup schedule and document delayed expiry.
- Use supported in-app correction, disablement or discontinuation controls where they meet the approved outcome. Do not run ad hoc cascading SQL against the live database.
- If physical deletion or de-identification is required but no supported workflow exists, treat that as a blocked engineering/data-migration task. Rehearse it on a copy, obtain explicit approval and preserve an audit trail.
- Verify the result from a second account or report, including wrong-school and QR-profile access.
- Record the live-data result, backup treatment, approver, operator, verification and any residual copies.
- Only then set the request status to Completed. Use Denied or Cancelled with a minimal reason when appropriate.
Backup retention and destruction
- Do not use git as backup storage; backups is intentionally ignored.
- A local backup on the same host is not sufficient protection from host loss. Any second copy must be school-approved, encrypted and access-restricted; the app does not create it automatically.
- Do not delete the only verified recovery point.
- Do not destroy a generation subject to a documented hold.
- Retire an old encryption key only after every backup requiring it has been destroyed under the schedule or re-encrypted and verified.
- Record filename, metadata filename, date range, authority, operator, destruction method and verification. Never record the key.
See Protected Backups for recovery objectives and exercises.
Update Routine
Before a new build is used:
pnpm test
pnpm lint
pnpm typecheck
pnpm build
deploy\windows\Install Update.cmd
pnpm release:check
deploy\windows\Check Deployment Readiness.cmdRun deploy\windows\Check Account Beta Readiness.cmd only as an account-beta readiness report; a passing script does not authorise account beta. Dedicated hosts must follow Database Migrations and keep automatic migrations disabled.
Current monitoring is manual:
- /launch for database, backup, restore and readiness status;
- /api/health for non-sensitive host health;
- Daily Review after live use;
- pnpm monitor:check where the configured host-monitoring routine is being exercised;
- support, correction, access and incident records for human follow-up.
Public production still requires durable external monitoring, alert routing, after-hours ownership, tested incident response and approved retention for monitoring records.
Evidence record template
Record at least:
- event/review ID and Australia/Brisbane date/time;
- environment and exact SQLITE_PATH/BACKUP_DIR labels without secrets;
- school or global scope;
- operator, approver and independent checker;
- command or UI workflow used;
- backup filename and whether it was encrypted/verified;
- RPO/RTO target and measured result where recovery was tested;
- affected record categories and count checks;
- result, severity, residual risk and follow-up owner/date;
- links to support, incident, access-review, migration or deletion records.
Readiness gate
Do not mark the nine Operations Readiness items complete until the relevant owner can produce current evidence for backup, restore rehearsal, update routine, monitoring, retention, deletion, support/correction, privacy/terms and school approval. Re-open the review when the host, school, data categories, authentication, transcription, payments, mobile clients or public exposure changes.
The ACSC regular-backup guidance supports coordinated backups, restore testing and protection from unauthorised modification. It is a useful control reference, not a substitute for the school's recovery and records decisions.