Approval working pack — not legal advice and not approval by itself. Complete this pack before real student information is entered, staff outside the controlled pilot are invited, QR cards leave teacher control, student/family access is enabled, microphone features are enabled, or the service is connected to a school system. Current operating boundary: Prototype — fictional demonstration data only. A signature on this unfinished pack does not remove that boundary or bypass Queensland Department of Education, school-system, procurement, privacy, information-security, records-management or child-safety processes.

A. Document and Decision Record

1. Approval Is a Chain, Not One Signature

The school decision owner must identify every required approval. For a Queensland state school, a principal’s support may be necessary but may not be sufficient for an external application handling student information. Confirm the applicable Department procurement, information-security, privacy, records, contracted-service-provider and technology-approval pathways.

For a non-state school, confirm the governing body or school-system process, Australian Privacy Principles position, contract authority, records obligations and child-safe requirements. For a home studio, confirm the business/privacy position, child-safe obligations and family terms rather than treating “small business” as automatic exemption.

No row may be marked complete with “see app” or a screenshot alone. Evidence must identify the reviewed release and responsible person.

2. Proposed Purpose and Explicit Exclusions

Approved purpose to describe

Record the precise problem the deployment is intended to solve:

[For example: teacher-managed instrumental lesson/rehearsal attendance, scheduling and progress for a defined pilot cohort.]

Confirm the service will not be treated as

• the school’s sole official student or attendance record;
• an emergency or child-protection reporting system;
• a medical, disability, behaviour or welfare record;
• a covert monitoring or general classroom recording tool;
• a verified practice-detection system;
• an automated grading or high-impact decision system;
• an advertising, analytics or student-profiling platform; or
• a general parent/carer communication or student messaging system.

Record the approved official system and manual fallback for attendance and essential records: [system/process].

3. Current Product Facts to Acknowledge

The reviewers acknowledge that the current implementation:

• uses a local SQLite database selected by deployment configuration;
• provides invite-based Administrator, Teacher and Read-only staff accounts;
• still has a transitional email-only pilot sign-in that is not verified authentication;
• has no open Student or Parent/Carer account registration;
• can run teacher and restricted public-QR services separately;
• exchanges a random QR token for a short-lived student session and requires a four-digit security code to be entered or established before unlock;
• keeps progress and attendance read-only in the student area but permits narrow session-bound security, friend, practice timer/tracking, mission/sight-reading, fixed-catalogue avatar, server-scored theory/bonus-round and challenge-bound Tuning Darts updates;
• permits a bounded student-authored Contact subject and message to be stored as a school-scoped support/correction request, which is not approved for real-data use until its privacy, moderation, support, retention and deletion process is approved;
• labels manual practice Manual practice log — unverified;
• prepares timetable-linked Lesson Note Drafts and, only after deliberate teacher arming and every approval/technical gate, can process temporary audio with an approved authenticated loopback engine on the app host without AI or retained raw content;
• records account-deletion review requests but does not technically delete an account or school data; and
• displays the prototype banner and permits fictional demonstration data only at the current stage.

Any reviewer relying on a different fact must identify the code/configuration evidence and resolve the discrepancy before approval.

4. Data-minimisation Decision

Minimum proposed student fields

Approve only fields necessary for the documented purpose. The narrow baseline is:

• first name and surname initial;
• instrument, instrument year and class only where needed;
• lesson type, lesson group and ensemble membership;
• schedule and timetable-exclusion information;
• attendance and teacher-assessed progress;
• manual practice and approved practice-tool results;
• approved fixed-catalogue avatar/reward state and bounded game-result metadata;
• random barcode/profile token; and
• factual, necessary music-programme notes.

Prohibited fields under the current boundary

• student photos;
• date of birth;
• home address;
• medical, disability or medication details;
• school identification number;
• private family circumstances;
• unnecessary parent/carer details;
• unrelated behaviour or welfare records;
• sensitive custom statistics; and
• covert audio, raw transcripts or stored student voice samples.

Blocking implementation mismatch

The current database and roster/import/export screens include optional student email and home-contact name/email/phone fields. These fields must remain empty for any prototype. Before a real-data pilot, choose and evidence one of the following:

• [ ] remove or disable those fields and their import/export/search paths; or
• [ ] formally approve a necessary purpose, authority, collection notice, role access, security, family process, retention and deletion treatment for each retained field.

Do not approve real-data use while this item is unresolved.

Free-text control

Nominate who reviews free-text templates and spot-checks notes: [owner]. Confirm teachers are told not to enter restricted information into notes, support requests, custom statistics, imports or deletion-request text. The student Contact route also persists bounded free text as a school-scoped support/correction request; separately approve or disable that intake before real student use, and record its moderation, safeguarding escalation, staff access, response, retention and deletion owner.

5. Data Flow and Provider Register

Attach a release-specific diagram showing collection, browser/client processing, application server, SQLite, exports, backups, support, monitoring, QR service and any native client.

For Queensland state-school information, procurement/legal review must decide whether the operator is a contracted service provider and bind it where required. The service arrangement must cover QPPs, section 33 overseas disclosure, subprocessors, access/amendment, incidents, audit, return and disposal.

6. Account and Role Approval

Role scope

Access evidence

• [ ] every staff user is named and assigned only required schools/roles;
• [ ] at least two approved Administrators exist or a sole-owner recovery plan is documented;
• [ ] account disablement, lockout and session revocation have been tested;
• [ ] wrong-school access tests cover pages, server actions and API routes;
• [ ] invitations are one-time and shared through an approved channel;
• [ ] access review owner and frequency are recorded; and
• [ ] departure/role-change notification and completion targets are recorded.

Attach the completed Role Access Matrix and latest access-review output.

7. QR Card and Student-view Approval

The school must decide separately whether cards are used only at school or may go home.

Approve only after confirming:

• QR content is a random token, not identity data;
• token exchange, security code, expiry, rate limits and revocation are tested;
• the QR-only deployment cannot open teacher/admin routes;
• pages use private/no-store and no-index protections;
• the visible student information is suitable for that student and cohort;
• attendance shows percentages only, not scan details or notes;
• leaderboard and friend features have been reviewed for indirect identification, social pressure and misuse;
• student writes are limited to the documented session-bound allow-list, including fixed-catalogue avatar changes and server-scored theory, bonus-round and Tuning Darts results;
• student Contact free text is disabled or its purpose, staff access, moderation/escalation, response, correction, retention and deletion process is explicitly approved and tested;
• cards contain only approved fields and no photo/contact information;
• families receive simple lost/copied-card instructions; and
• a teacher can immediately reissue access and regenerate the card.

QR decision

• [ ] Not approved.
• [ ] Approved for supervised school use only.
• [ ] Approved to go home for the named cohort, subject to attached notice and reissue process.

Approver, conditions and evidence: [details].

8. Student and Family Information

Provide an age-appropriate student explanation and a family-facing notice before student access. The material should explain:

• what the app is for and what it is not for;
• what the school records and why;
• what the QR card reveals and why it should not be shared;
• which actions the student can perform;
• that manual/timed practice is unverified;
• when a microphone may be requested and what happens to audio;
• that Contact stores their subject and message for authorised school support staff and is not a private or emergency channel;
• how to correct a mistake, replace a card or raise a concern;
• who can see school records;
• that the app is not an emergency or private messaging channel; and
• how the student can speak to a trusted adult if something feels wrong.

Do not assume parent/carer “consent” is always the correct or only legal basis. The privacy/legal owner must determine the applicable authority, notice and choice for the school and feature. Record any alternative available to a student who does not use a QR card or microphone feature.

9. Child-safe Design Review

Map the proposed use to Queensland’s 10 Child Safe Standards and the Universal Principle, with particular attention to:

• leadership accountability and staff conduct;
• children’s voice and accessible explanations;
• family/community information;
• equity, diversity and cultural safety;
• suitable and supported staff;
• child-focused complaints;
• staff knowledge and training;
• safe physical and online environments;
• recurring review and improvement; and
• documented policies and procedures.

Confirm the service does not add open profiles, public search, direct student messaging, public media uploads, precise location, advertising or child-directed behavioural profiling.

Urgent child protection matters must follow the Department/school student-protection process. The app support and privacy queues are not emergency or mandatory-reporting channels.

Child-safety approver, conditions, training evidence and review date: [details].

10. Microphone and Audio Feature Decisions

Practice tools

Optional tuner, mission, sight-reading and Tuning Darts pitch-analysis functions may request microphone access only after deliberate user action. They process pitch locally in the browser without recording, uploading or storing audio. Approved derived result fields may be stored; Tuning Darts keeps challenge-bound target, score and bounded pitch-attempt metadata rather than audio. Practice logging remains manual and unverified, and verified automatic practice detection is not included. The Lesson Note workflow is the sole permitted microphone recording/transcription exception and does not assess students or replace teacher assessment.

• [ ] local-processing/no-storage behaviour tested on every supported browser/client;
• [ ] permission explanation and active-use indicator are clear to children;
• [ ] stopping/unmounting releases microphone access;
• [ ] no audio, raw pitch stream or device label appears in logs/exports/backups;
• [ ] non-microphone alternative or teacher process documented; and
• [ ] native permission declarations match shipped behaviour.

Local pitch-analysis decision: Not approved / Approved with conditions: [details]. This does not approve recording, transcription or automatic practice detection.

Timetable-prepared, microphone-assisted Lesson Notes

The workflow stores a name-minimised Prepared Draft when an authorised teacher opens a teaching date. It uses a privacy-neutral label and opaque occurrence link and always accepts typed content. Microphone assistance is a separate gated option: the teacher deliberately arms the selected teaching date once, covering the combined list of writable lessons and rehearsals, after which active scheduled sessions may start/stop local temporary capture at timetable boundaries. Capture has a persistent indicator and Stop/Discard. Only a privacy-filtered Candidate Draft may be saved; no cloud transcription, generative AI, assessment, automatic sign-off or delivery is used.

• [ ] educational purpose and necessity approved;
• [ ] Teacher/Administrator edit access and signed-only Read-only visibility approved;
• [ ] Prepared, Draft and Signed Off states understood;
• [ ] untouched Prepared Draft review/archive period decided;
• [ ] edited and signed retention/correction process decided;
• [ ] copied/shared channel and recipient authority decided;
• [ ] cross-school, cancelled-session, duplicate and identifier tests evidenced; and
• [ ] staff training explains that preparation does not prove a session occurred.

Typed Lesson Note decision: Not approved for real data / Approved with conditions: [details].

Microphone-assistance evidence

Normal startup stays audio-free. Only the explicit Lesson Notes opt-in mode may start the approved authenticated loopback engine. Completing or ticking this checklist records evidence; it does not itself create legal authority, participant consent, school approval, or technical enablement.

• [ ] educational purpose and necessity approved;
• [ ] authority, notice/consent position and appropriate lesson-room practice documented;
• [ ] the current built-in engine is restricted to an authenticated loopback address on the app host;
• [ ] audio and raw transcript are absent from database schema, browser storage, logs, exports and backups;
• [ ] normal, error, cancellation, timeout and restart deletion paths tested;
• [ ] page load and scheduled time alone cannot request permission or arm capture;
• [ ] teacher deliberately arms one selected teaching date for the combined lesson-and-rehearsal list and can stop/discard immediately;
• [ ] persistent Armed/Capturing state is visible and announced accessibly;
• [ ] names and prohibited content are blocked/removed and teacher review remains mandatory;
• [ ] no automatic family delivery exists;
• [ ] privacy check and school-specific readiness checks pass; and
• [ ] incident process covers unintended capture.

Lesson Note microphone decision: Not approved / Approved for the named date, cohort, room, host and conditions: [details].

Keep microphone assistance locked unless the signed external school/privacy/child-safety/participant-notice evidence, data-minimisation and correction controls, local-engine/no-storage evidence, current school access, and explicit environment opt-in all pass. Keep typed notes available regardless.

11. Security Approval

Attach evidence rather than relying on intended architecture.

• [ ] trusted HTTPS verified from a separate device;
• [ ] secure cookies enabled for non-local HTTPS;
• [ ] teacher and QR services exposed only on approved routes;
• [ ] operating system, database file and backup permissions reviewed;
• [ ] administrator accounts use strong unique credentials and no sharing;
• [ ] secrets are outside source control and recoverable by authorised owners;
• [ ] sign-in lockout and rate limits tested across the real process topology;
• [ ] logs exclude passwords, tokens, student content and temporary transcripts;
• [ ] dependency, build, native-foundation and release checks pass;
• [ ] patch and vulnerability-response owner/frequency recorded;
• [ ] endpoint/device loss process recorded;
• [ ] penetration/access review completed proportionate to deployment; and
• [ ] open security findings have owners, due dates and acceptance authority.

Security approval does not convert an unapproved public-production deployment mode into an approved service.

12. Backup, Recovery and Continuity Approval

The school must know who operates recovery and what records can be restored.

• [ ] authenticated encrypted backup configuration verified;
• [ ] backup destination and access list approved;
• [ ] encryption-key custody and recovery tested separately from the backup;
• [ ] automatic schedule and failure alert observed in the intended host;
• [ ] integrity verification and temporary-copy restore rehearsal passed;
• [ ] recovery time/data-loss expectations documented as measured targets or commitments;
• [ ] retention and deletion apply to backups and temporary restore copies;
• [ ] off-site or host-failure recovery considered without creating an unapproved disclosure; and
• [ ] manual attendance fallback rehearsed.

Record the latest backup, verification and restore-rehearsal evidence: [details].

13. Records, Retention and Deletion Approval

Identify whether Band Licence is a working copy, supporting record or authoritative record for each data class. Do not use one retention period for every table.

The current deletion screen is review-only. Do not approve public accounts until an end-to-end technical process is implemented and tested across live data, roles, sessions, QR tokens, providers, exports and backup lifecycle.

14. Access, Correction and Complaint Path

Publish the real contacts and rehearse these scenarios:

1. family reports an incorrect attendance percentage;
2. teacher has access to the wrong school;
3. student’s QR card is lost or shared;
4. requester seeks access to a child’s information;
5. requester asks for account deletion and school-record deletion;
6. teacher accidentally enters prohibited information; and
7. privacy complaint names the school and operator.

The process must verify identity and authority proportionately, protect third-party information, preserve necessary history, give a reasoned outcome and identify the applicable external review path.

For Queensland state-school information, coordinate formal access/amendment and privacy complaints with the Department process. Current Queensland guidance allows the agency 45 business days before an unresolved privacy complaint may be taken to the OIC. For an APP entity, OAIC guidance generally expects the organisation to receive the complaint first and treats 30 days as a usual reasonable response period.

• School privacy/RTI contact: [details]
• Operator privacy contact: [details]
• Support/correction contact: [details]
• Child-safety/emergency pathway: [details]

15. Incident and Data-breach Readiness

• [ ] 24/7 or defined-hours incident intake is monitored;
• [ ] operator-to-school notification target is contractual and shorter than any regulatory assessment limit;
• [ ] decision authority for Queensland MNDB/Commonwealth NDB assessment is named;
• [ ] serious-harm assessment considers children, family safety and QR exposure;
• [ ] containment includes session/account/QR revocation and exposed-export recovery where possible;
• [ ] provider notification and evidence-preservation duties are contractual;
• [ ] family communication is coordinated with the accountable school and avoids further disclosure;
• [ ] incident register and post-incident review are ready; and
• [ ] a tabletop exercise has been completed with actions closed.

Record exercise date, scenario, participants, outcome and evidence: [details].

16. Pilot Plan and Success/Stop Rules

If approvals permit a real-data pilot, keep it narrow and reversible.

Approval for a pilot is not approval for public registration, app stores, additional schools, new providers or broader student/family access.

17. Conditions Register

An “Approved with conditions” decision is not permission to start while any blocking condition remains open.

18. Approval Outcome

Decision

• [ ] Declined.
• [ ] Deferred pending the conditions register.
• [ ] Approved for fictional demonstration only.
• [ ] Approved for the defined real-data pilot only, after every blocking condition is closed.

Sign-off

19. Review and Change Control

Repeat approval before changing the cohort, school, deployment mode, public routes, data fields, retention, providers, hosting country, account roles, QR capabilities, microphone behaviour, online/group-session features, school-system integration, payments or native permissions.

At minimum, review at the pilot end, annually while in use, after a material incident and before contract renewal. Record withdrawn approvals and ensure access, QR tokens, exports, backups and provider copies follow the approved offboarding decision.

Authoritative Review Sources

• Queensland OIC — Queensland Privacy Principles
• Queensland OIC — contracting and privacy
• Queensland OIC — privacy and technology
• Queensland OIC — mandatory notification of data breaches
• Queensland Government — privacy rights
• Queensland Department of Education — OneSchool information-security model
• Queensland Department of Education — student protection
• Queensland Government — Child Safe Standards and Universal Principle
• Queensland Family and Child Commission — implementing the Child Safe Standards
• eSafety Commissioner — Safety by Design
• OAIC — children and young people
• OAIC — Australian Privacy Principles