Purpose and limits

Use this process for the local/private-network pilot and before inviting another teacher. It is a manual Administrator-led workflow, not a public help desk or contractual service-level agreement.

The in-app Support and Correction Log is available in Settings → School Settings and is school-scoped. Creating or updating a request requires Administrator access. The app records the request in support_correction_requests and writes an account audit entry, but it does not send email, page an on-call person, repair records automatically or notify families.

Use fictional demonstration data only. Keep summaries factual and minimal. Never include passwords, invitation/reset tokens, backup keys, student photos, medical information, home details, parent/carer details, raw audio, raw transcripts or private family stories.

For Queensland government agencies, the OIC Queensland overview of the QPPs, in effect from 1 July 2025, describes QPP 10 data quality and QPP 12/13 access and correction requirements. This pilot log is an internal workflow only; it is not a substitute for any formal statutory access, amendment, privacy-complaint or Right to Information process.

Owners

The Host Operator can access database files outside the app and is therefore privileged even if they have no app account.

What the current log supports

The request types are:

• Account Access
• Attendance Correction
• Student Correction
• QR Card
• Import Fix
• Backup or Restore
• Lesson Notes
• Other

The lifecycle states are:

1. Open — captured and awaiting triage.
2. Reviewing — authority, scope, evidence or remedy is being checked.
3. Resolved — the approved remedy has been applied and verified.
4. Dismissed — no change is authorised or required; record a minimal reason.

Changing a status records the resolver and resolution time for resolved/dismissed requests and creates an account_audit_logs entry. It does not prove that every affected record or backup was changed; closure evidence must say what was actually verified.

Severity and pilot response targets

These are internal targets for an active pilot, not promises to customers.

If the risk is privacy, child safety, data loss, suspected intrusion or widespread outage, the support record is secondary to containment and the incident plan.

Minimum intake record

Record:

• school and affected workflow/page;
• request type and date/time in Australia/Brisbane;
• what was expected and what occurred;
• record identifier or account email only where necessary;
• date/term/session affected, not unnecessary student biography;
• whether live use is continuing;
• severity and owner;
• safe reproduction steps;
• screenshots only after checking they contain no unnecessary student data;
• requested outcome and who is authorised to approve it.

Do not paste a full imported roster, database file, backup, system environment, secret or console dump into the support note.

Triage and containment

1. Confirm the selected school before viewing or changing anything.
2. Check whether the requester is authorised for that school and record category.
3. Decide whether this is support, correction, deletion review, security/privacy incident or planned engineering work.
4. For access errors, disable or restrict the account before investigating convenience issues.
5. For suspected corruption or material import errors, stop further writes and create a protected evidence copy before repair.
6. For availability only, switch to the manual attendance fallback and avoid duplicate retrospective entry.
7. Set the request to Reviewing, assign an owner and record the next check time.

Standard correction workflow

1. Define the exact current value, intended value and authority for the change.
2. Check related records and school scope before changing the target row.
3. For significant or multi-record changes, run:

pnpm db:backup
pnpm db:verify-backup

4. Use the supported app workflow wherever possible.
5. Ensure Teacher/Administrator permission is enforced; setup/account work must remain Administrator-only.
6. Preserve the original in audit history when the feature supports correction rather than silent deletion.
7. Re-open the same page, report or Daily Review from a second session/account where practical.
8. Check that another school, a Read-only account and a QR profile did not gain unintended access.
9. Record what changed, who approved it, backup filename, verification result and remaining limits.
10. Set Resolved only after verification. Do not use a green status as a substitute for evidence.

Scenario playbooks

Wrong school or wrong role

1. Treat cross-school access as Critical until disproved.
2. Disable the account or deactivate the incorrect school role from Teacher Accounts.
3. Revoke other account sessions where appropriate.
4. Confirm the intended school and least-privilege role.
5. Create a new invitation if access must be re-established; links are copied manually and are not emailed by the app.
6. Test direct access to the wrong school, not only whether its menu link disappeared.
7. Record the account audit result and perform an out-of-cycle access review.

The pilot email fallback has Administrator-equivalent access without an account role. It must not be treated as a narrow Teacher login and must be disabled before account beta after secure recovery is ready.

Attendance or lesson attendance

1. Confirm rehearsal versus lesson attendance; the two stores are separate.
2. Confirm the selected school, student, session/date and existing mark.
3. Use Daily Review for same-day review and supported resolution where possible.
4. Preserve scan time, entry method, guest status and without-instrument meaning.
5. Verify the student profile/report and Attendance statistics after correction.
6. Record why a historical value changed and who authorised it.

Progress, Licence or pass-off

• Do not collapse Licence progress, method-book progress, pass-offs and practice into one correction.
• Correct a Licence award through the correction workflow so history remains.
• Respect the one-attempt-per-student/item/week and one Not Passed per date rules.
• Recalculate or view the relevant profile and leaderboard after the change.

Student detail

• Prefer Current/Discontinued status over physical deletion.
• Preserve profiles at rollover.
• Keep the display-name rule: first name plus surname initial.
• Never add dates of birth, addresses, medical data, school identifiers, parent/carer data or photos.

Import error

1. Stop importing.
2. Record source format, school, import time and affected rows without attaching the full real roster.
3. Create and verify a backup.
4. Determine whether an in-app undo/correction route covers the affected data.
5. Repair only the affected school and records.
6. Test the corrected file with fictional/sample rows before a full import.
7. Compare counts and spot-check fields after re-import.

QR card or profile

• Confirm the random token resolves only to the intended student's narrow profile.
• Regenerate/revoke profile access when compromise is suspected.
• Confirm the public-profile process cannot open teacher/admin pages.
• Do not expose names beyond first name plus surname initial or add personal information to the barcode.

Backup or restore

• Do not repeatedly retry a failing restore against the live database.
• Use pnpm db:verify-backup and pnpm db:restore:rehearse first.
• A real restore requires the app server to be stopped and CONFIRM_RESTORE=YES.
• Follow Protected Backups and record measured recovery results.

Lesson Notes

• A timetable-created record must remain name-minimised, visibly marked Prepared and restricted to teacher review. Only a signed-off Summary may be copied or shared through the approved channel.
• Correct the wrong timetable link, stale occurrence, duplicate preparation, identifying content or incorrect sign-off through the school-scoped audited process.
• Cancelling, removing or rescheduling a session archives only an untouched Prepared Draft. Never silently overwrite or remove teacher-edited or signed history.
• Microphone assistance requires deliberate teacher arming, a persistent visible state, Stop/Discard, every school/privacy/child-safety/data-minimisation/correction gate, an approved authenticated loopback engine and explicit environment opt-in. A local checkbox is evidence only, not legal approval.
• Temporary audio and raw transcripts may pass only through the guarded in-memory/local-engine path. If either is retained in the app database, browser storage, logs, exports, notifications, backups or support record—or survives its engine request—stop microphone use and escalate as a privacy incident.
• Do not promise automatic family delivery; it is not implemented or approved.

Account or data deletion

• Use the authenticated deletion-review request for account users.
• Completed is a review status, not an erasure engine.
• Follow the retention/hold and evidence process in Operations, Retention and Deletion and the limits in Account and Data Deletion.

Evidence and audit

For every High or Critical issue, and every correction to important teaching/account data, record:

• request ID and school;
• severity, owner and timestamps;
• authority/requester verification;
• before/after values or a minimal count/checksum-style description;
• backup and verification result;
• app action, route or command used;
• audit-log reference where available;
• independent verification;
• affected backups/exports and retention decision;
• root cause, corrective action and prevention owner/date.

The app maintains two relevant audit streams:

• audit_logs for teaching/workflow changes, with action, teacher identifier, optional student/rehearsal, previous/new value and note;
• account_audit_logs for sign-in, invitations, access/readiness, support and deletion-request events.

Not every change is guaranteed to have the desired audit depth. The access review must decide where an audit gap blocks release.

Review cadence and trend review

• Review Open and Reviewing requests weekly during an active pilot.
• Review Critical/High corrective actions until closed.
• Each term, group requests by type and look for repeated import, access, QR, backup or training failures.
• After two failures of the same approach, stop repeating it, diagnose the cause and assign a different remedy.
• Revisit this guide whenever a new API route, account role, import source, public surface, mobile workflow, transcription feature or payment integration is added.

Closure checklist

A request may close only when:

• the correct school and authority were verified;
• immediate risk was contained;
• the approved change was applied through a supported or separately approved method;
• affected views/reports and cross-school boundaries were checked;
• the requester or independent checker confirmed the outcome where practical;
• audit/support evidence is sufficient and minimal;
• backup and retention consequences are documented;
• follow-up work has an owner and date.

Before public release, publish a real support channel, complaint/privacy contact, response targets, availability statement and correction/deletion process. Align them with the Privacy Policy, Terms of Use, school approvals and actual staffing.