Working draft — not legal advice and not ready for publication. This document records the intended privacy boundary and known implementation facts for school, privacy, child-safety and legal review. It must be checked against the exact released build, hosting arrangement, provider contracts and school authority before it becomes a public privacy policy. Current operating boundary: Prototype — fictional demonstration data only. No statement below authorises entry of real student or family information during the prototype stage.

Document Control

All bracketed fields are release blockers, not optional publishing text.

1. What Band Licence Is For

Band Licence is designed to support authorised instrumental music administration, including:

• student, ensemble and lesson-group setup;
• rehearsal and lesson scheduling and attendance;
• teacher-assessed licence, method-book and pass-off progress;
• manual practice records and selected practice-tool results;
• student reports and licence cards;
• limited QR-linked student views; and
• anonymous teacher-reviewed lesson or rehearsal summaries where separately enabled.

It is not designed for general student surveillance, medical or wellbeing records, behaviour monitoring, emergency reporting, advertising, unrelated school administration or automated high-impact decisions about children.

2. Which Privacy Framework Applies

The applicable law and accountable organisation depend on the customer and service arrangement. The final policy and contract must identify the position for each deployment.

Queensland state schools

The Queensland Department of Education, including its state schools, is a Queensland Government agency subject to the Information Privacy Act 2009 (Qld) and the Queensland Privacy Principles (QPPs). Where an external operator handles personal information to perform a Department function, the Department must assess whether it is required to take reasonable steps to bind that operator as a contracted service provider under Chapter 2, Part 3 of the Act.

If the operator is bound, the arrangement should address QPP compliance, section 33 overseas disclosure, access and correction, privacy complaints, data-breach cooperation, subcontractors, document control, audit, return and disposal. The words “data owner”, “controller” and “processor” do not replace those statutory and contractual responsibilities.

Non-state schools and private studios

The Commonwealth Privacy Act 1988 and Australian Privacy Principles commonly apply to private schools and may apply to a private studio or operator depending on its activities and circumstances. Other contractual, school-system, child-safe, records, consumer and professional requirements may also apply.

The service operator and customer must obtain advice for their actual arrangement. This draft does not declare an exemption or decide which entity is legally accountable.

3. Proposed Responsibility Allocation

Subject to final contract and legal review:

• the school, employing authority or authorised studio teacher decides the approved educational purpose, people in scope, authorised data fields, users and retention requirements;
• the service operator handles information only to provide, secure, maintain and support the agreed service, on documented instructions and as required by law;
• School Administrators manage invitations, roles, school access, QR reissue, exports and first-line review requests;
• teachers keep records relevant, accurate and appropriate for the music programme;
• the privacy owner maintains notices, provider and data-flow registers, incident response, complaints and request handling; and
• the child-safety owner ensures online access, complaints and microphone features fit the school’s safeguarding framework.

The contract must state who answers individuals, who makes notification decisions, who communicates with families and regulators, and which party holds or controls documents for access and amendment purposes.

4. Current Deployment and Feature Status

The repository currently provides a local SQLite application, local/private deployment options, a separately restricted public-profile process, invite-based staff accounts, audit records, backup tooling and release-readiness checks. Those capabilities do not prove that a particular host is approved, secure, monitored or production-ready.

Current limitations include:

• public self-registration is not approved;
• Student and Parent/Carer accounts are not open;
• the transitional email-only pilot sign-in is not verified email authentication;
• the account-deletion workflow records review status but does not perform deletion;
• final operator, support and privacy contacts are missing;
• provider, hosting, overseas-location and retention decisions are not final; and
• real student or family data remains outside the prototype boundary.

5. Information the Current Design Can Hold

The final public policy must be generated from a release-version field and data-flow inventory. The current design can hold the following categories.

School and programme setup

• school profile and selected-school settings;
• teacher-managed instruments and licence terminology;
• ensembles, rehearsal schedules, lesson groups and lesson availability;
• term dates, exclusions and timetable settings; and
• method-book titles and checkpoint metadata, without storing reproduced notation or pages.

Student music-programme records

• first name and surname initial;
• instrument, instrument year and optional class;
• lesson type, groups and ensemble memberships;
• random barcode/profile token and hashed student security-code material;
• attendance, punctuality, absence and without-instrument marks;
• teacher-assessed progress, awards, pass-offs and method-book checkpoints;
• manual practice entries, practice-timer outcomes and selected practice-tool results;
• lesson-swap and scheduling records;
• student report summaries, optional custom statistics and teacher notes; and
• current/discontinued status and associated administrative notes.

Staff accounts and access

• staff email address and display name;
• password hash and salt, verification/recovery status and failed-sign-in/lockout state;
• school roles and account status;
• expiring web/native session and sign-in-handoff records; and
• account and security audit entries.

Passwords, profile security codes and session tokens are intended to be stored as hashes or protected session values rather than readable credentials. Release verification must confirm that remains true.

QR and student-session activity

• random profile-access token associated with a student;
• hashed short-lived QR session token, student/school binding, expiry, last-seen, unlock and revocation times;
• rate-limit/security events associated with token or network identifiers, where implemented;
• student-selected friend links;
• practice-tracking preference and practice timer runs;
• locally assessed mission and sight-reading results;
• fixed-catalogue avatar inventory/equipment and reward transactions;
• server-owned theory/bonus challenges, submitted answers and server-computed results;
• challenge-bound Tuning Darts targets, scores and bounded pitch-attempt metadata, but no audio; and
• bounded student-authored Contact subjects/messages stored as school-scoped support/correction requests.

Operations and requests

• support/correction request details and review notes;
• account-deletion review request identity, type, status, dates and reviewer;
• Daily Review and readiness evidence;
• operational, access and account audit records;
• subscription-entitlement and billing-readiness records, although live payments are not enabled; and
• database backups containing copies of live records.

Lesson summaries

Durable lesson/rehearsal records contain the summary type, date, privacy-neutral session label, opaque occurrence link, Draft origin/version, Prepared or teacher-edited Summary text, sign-off checklist and audit dates. The teacher identifier is added only after deliberate teacher save. Audio and raw transcript fields are not part of the saved design.

6. Blocking Data-minimisation Mismatch

The current roster schema and some import/export and editing screens contain optional studentEmail and home-contact name, email and phone fields. That is inconsistent with the present prototype instruction not to collect parent/carer details or unnecessary real student identifiers.

Until the scope is deliberately changed and approved:

• leave those fields empty;
• do not import, export or search real contact details;
• use fictional demonstration values only where testing requires the fields; and
• treat removal or disabling of the fields as a release gate.

If a future product decision retains any contact field, first document the necessity, authority, notice, access, disclosure, security, retention, correction and family-support process. The privacy policy must then be updated from verified behaviour. The existence of a database column is not permission to collect data.

7. Information That Must Not Be Collected

Under the current approved boundary, users must not enter or upload:

• student photographs or photo placeholders;
• dates of birth, home addresses or school identification numbers;
• medical, disability, health or medication information;
• private family circumstances or unnecessary parent/carer details;
• unrelated behaviour, welfare, disciplinary or counselling information;
• sensitive custom statistics;
• government identifiers, financial information or identity documents;
• advertising identifiers or tracking profiles;
• student-to-student private messages;
• covert recordings or stored student voice samples; or
• personal stories in lesson summaries or support notes.

Free-text fields, documents and custom statistics do not create an exception. If prohibited or unsolicited material is received, access must be restricted immediately and the privacy/records owner must decide the lawful correction, return, quarantine or disposal response.

8. How Information Is Collected

Information may be created when an authorised user:

• configures a school, programme, timetable or method book;
• manually enters or imports a roster;
• records attendance, progress, pass-offs, practice or notes;
• creates or accepts an invitation and signs in;
• scans a barcode, exchanges a QR token, or pairs a hashed school access code with a licence card for a student session;
• uses a student practice timer, friend, avatar, theory/bonus, Tuning Darts or result-saving feature;
• generates a card, report, export or backup;
• submits a support, correction or deletion review request; or
• deliberately uses an approved microphone feature.

The final service must provide a clear collection notice at or before each materially different collection, including any roster import, QR issue, student-facing use, microphone permission, support request and account registration. A generic privacy-policy link alone may be insufficient for an unexpected collection.

Band Licence must not obtain student data from advertising networks, data brokers, social media or unrelated third-party databases.

9. Purposes of Handling Information

Information may be handled only as reasonably necessary to:

• identify the correct school, account or student record;
• administer instrumental lessons, rehearsals and schedules;
• record and correct attendance and teacher-assessed progress;
• provide reports, cards and limited student views;
• support manual practice and approved practice tools;
• administer invitations, roles, sessions and security;
• investigate support, correction, deletion and security matters;
• maintain audit, backup, restore and operational reliability; and
• administer entitlements and lawful billing if subscriptions are later enabled.

Information must not be sold, used for targeted advertising, unrelated profiling, training a general AI model, unrelated analytics or automated decisions that determine a student’s educational opportunity. A new purpose requires authority, compatibility assessment, notice and approval before implementation.

10. QR Cards and Limited Student Access

QR codes contain a random profile token, not a name, instrument, school identifier or internal student ID. The implemented exchange creates a 30-minute, HTTP-only, same-site session bound to one active student and school. The session can be revoked, and changing the student’s profile token invalidates prior cards/sessions. Secure-cookie protection depends on the deployment setting and must be enabled for trusted HTTPS deployments.

A teacher may also issue a revocable, expiring family access code. Band Licence stores only an HMAC digest of that code. It must be paired with the student's existing same-school licence card and then the student's PIN; it is not a public roster search and does not require a student email or payment.

The student must enter or establish the four-digit profile security code before the session unlocks. The code is rate-limited and stored using derived security material rather than plain text.

The student area can display approved student-view information such as:

• first name plus surname initial, instrument and instrument year;
• licence, method-book and pass-off progress;
• manual practice summaries;
• lesson and rehearsal attendance percentages without private notes or scan times;
• privacy-filtered leaderboards and friends; and
• practice, mission, sight-reading, theory, avatar, Tuning Darts and related student tools.

Progress and attendance remain read-only. Narrow student writes currently include first-use security setup/check, friend choices, practice timer/tracking, locally assessed mission and sight-reading results, fixed-catalogue avatar purchase/equip actions, server-scored theory challenges and bonus rounds, and challenge-bound Tuning Darts results. The public policy and school notice must not incorrectly call the entire QR area read-only.

The student Contact action is a separate free-text collection. It persists a bounded subject and message as a school-scoped support/correction request and is rate-limited and session-bound. It is not private or emergency messaging. Before real student use, the school and operator must approve and explain its purpose, staff access, moderation/safeguarding escalation, response, correction, retention and deletion. An implemented route is not evidence of that approval.

A QR card remains a bearer credential. The school must approve take-home use, explain safe handling, provide a lost-card path and reissue access promptly. QR pages must remain non-indexed, non-cached and separated from teacher routes; these controls require deployment testing and do not make a shared link harmless.

11. Microphone and Audio Handling

Tuner, mission, sight-reading and Tuning Darts tools

Optional tuner, sight-reading, mission and Tuning Darts pitch-analysis tools 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 data may be sent to the server; Tuning Darts stores 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 below is the sole permitted microphone recording/transcription exception. Each supported browser and client must be retested because platform behaviour and permission indicators differ.

Timetable-prepared, microphone-assisted Lesson Notes

When an authorised teacher opens a teaching date, the app may create one school-scoped Prepared Draft for each active scheduled lesson or rehearsal. The record stores the school, date, session type, privacy-neutral time/type label, opaque occurrence link, Draft origin/version, privacy-filtered Candidate Draft or teacher-typed Summary, and later edit/sign-off metadata. It does not store student names, instruments, class, barcode, roster, attendance counts or attendance notes in the prepared/shareable text.

Normal startup and page opening do not request a microphone or start transcription. Only an explicit Lesson Notes opt-in start mode may enable the approved authenticated loopback engine on the app host. If every school, privacy, child-safety, data-minimisation, correction, access and environment gate passes, an authorised teacher may deliberately arm the selected teaching date once. That single arm covers the combined list of writable lessons and rehearsals; active scheduled sessions may then start and stop temporary capture at their timetable boundaries. A persistent indicator and immediate Stop/Discard controls remain available.

Temporary audio and raw transcript text are destroyed after processing or any terminal event and must never enter the app database, browser storage, logs, analytics, notifications, exports, support records or backups. The workflow uses no cloud transcription or generative AI. Only a privacy-filtered Candidate Draft may be saved, and no Summary is signed off or sent automatically. An in-app checkbox records evidence only; it does not create legal authority, consent or school approval.

An untouched Prepared Draft is visibly distinguished from a teacher-edited Draft and a signed-off note. Timetable reconciliation may archive an untouched Draft when its occurrence is cancelled, removed or rescheduled. It must not silently overwrite or archive teacher-edited or signed records.

The teacher must review the complete note and confirm it contains only relevant music content, goals and next steps—not names, initials, contact, health, family, behaviour or other identifying stories—before controlled sharing. The app's identifier checks are aids, not guaranteed anonymisation.

Use the Lesson Note Privacy Readiness and Lesson Note Architecture before real-data use.

Custom feedback sounds

An Administrator can configure small feedback sound files. These are stored settings, unlike temporary microphone processing. They must contain no student voice or personal information, and the uploader must have permission to use the sound.

12. Sharing and Service Providers

The current prototype must not share real student data. Before wider release, the operator must maintain a provider register covering at least:

Student data must not be sold. Providers must not use it for advertising, their own product development or general model training. Contracts must address confidentiality, access control, incident notification, subcontractors, audit, assistance with requests, retention, return/deletion and legal demands.

13. Overseas Disclosure and Access

No final overseas-handling statement can be made until every production provider, support location, diagnostic system and subcontractor is known.

For Queensland Government information, section 33 of the Information Privacy Act 2009 (Qld) applies to disclosure outside Australia. The school/Department and operator must distinguish remote access, use and disclosure and must not rely on a generic cloud-provider statement.

For an APP entity, APP 8 and related provisions may require reasonable steps before overseas disclosure and may leave the entity accountable for the recipient’s acts. The final policy must identify likely recipient countries where practicable.

If support personnel, backups, logs or subprocessors can access data from overseas, record that fact in the data-flow and provider registers before rollout.

14. Security and Data Location

The codebase contains security foundations including password hashing, expiring sessions, role checks, temporary lockouts, hashed QR/native handoff tokens, school scoping, audit logs, non-cache headers for public profiles, backup/restore tooling and deployment checks. These are implementation controls, not a guarantee that a live deployment is secure.

Before handling real data, verify and record:

• trusted HTTPS and secure cookies;
• host, database and backup access controls;
• administrator and service-account least privilege;
• secrets and encryption-key handling;
• patching, dependency review and supported versions;
• monitoring that avoids logging student content or tokens;
• restore tests and recovery ownership;
• rate-limit behaviour across multiple processes;
• QR-only route isolation;
• account disablement, session revocation and access review;
• physical security for self-hosted equipment; and
• incident detection and after-hours escalation.

The live SQLite database and any materialised restore copy contain readable application records and require host-level protection. Backup encryption does not protect an unlocked live database or an authorised export.

15. Retention and Disposal

No final retention periods have been approved. “Keep everything” and “delete immediately” are both unacceptable default policies.

The school/records owner must approve a schedule that distinguishes:

For APP entities, APP 11 requires reasonable security and reasonable steps to destroy or de-identify personal information when no longer needed, subject to lawful retention. Queensland agencies must also comply with public-records and other obligations. De-identification must be assessed for re-identification risk; replacing a name with an ID is not automatically de-identification.

16. Access and Correction

Individuals must have a discoverable way to request access to or correction of their personal information. For a child, the school must apply its lawful authority and identity/relationship checks rather than automatically disclosing records to any requester claiming to be a parent or carer.

The operational process should:

1. record the request without asking for unnecessary identity documents;
2. identify the accountable school/operator and applicable legal pathway;
3. verify identity and authority proportionately;
4. preserve the original record and audit history where required;
5. search live data, controlled provider copies, exports and relevant backups/indexes as required;
6. protect other people’s information;
7. correct inaccurate current data or attach an approved notation where history must remain;
8. explain any refusal, partial response or formal review path; and
9. record completion and evidence.

Routine teaching corrections can use the app’s correction and audited override controls. Formal access/amendment requests for Queensland Government documents must be coordinated with the school/Department’s Right to Information and Information Privacy process. The operator must not make an independent disclosure that bypasses the accountable agency.

17. Account and Data Deletion Requests

The public /account-deletion page is information and navigation only; it does not accept a request. A signed-in secure account can currently submit “account only” or “account and school data review”, and Administrators can set requested, reviewing, completed, denied or cancelled in Global Settings. Status changes are audited. There is no approved external intake for a former user who cannot sign in, so that remains a release blocker.

This workflow does not currently delete an account or any data. A status of completed is only a label unless a separate, evidenced deletion process occurred.

Account deletion, role removal, school-workspace closure, student-record disposal, QR reissue and backup expiry are separate operations. The final response to a requester must say:

• what was in scope;
• what was deleted or de-identified;
• what remains and the lawful/approved reason;
• applicable retention period or event;
• which provider copies were addressed;
• when backup copies become inaccessible or expire; and
• how to complain or seek review.

See Account and Data Deletion.

18. Privacy Questions and Complaints

Final contact details must be inserted and monitored before publication.

Proposed first-line process:

1. contact [school/privacy contact] or [operator privacy contact] with the event, date, information involved, impact and requested outcome;
2. receive a case reference and acknowledgement within [service target];
3. the privacy owner identifies the responsible entity, preserves evidence and coordinates with the school;
4. receive a reasoned written outcome within the applicable legal or promised timeframe; and
5. use the external escalation pathway below if unresolved.

For a complaint about a Queensland Government agency or its bound contracted service provider, the complaint should first be made to the agency/provider through the approved process. Current Queensland guidance provides the agency at least 45 business days before a complaint may be taken to the Office of the Information Commissioner (OIC), and generally requires a complaint within 12 months of learning of the issue.

For an organisation covered by the Commonwealth Privacy Act, the individual must generally complain to the organisation first. OAIC guidance says a person may complain to the OAIC if there is no response within a reasonable time—generally 30 days—or the response does not resolve the matter.

The final policy must link the correct external regulator for the responsible entity; it must not direct every school complaint to the OAIC.

Child-safety allegations and immediate danger must use emergency and school child/student-protection channels. An ordinary privacy or support ticket is not an emergency response.

19. Security Incidents and Data Breaches

Anyone who suspects a lost device, exposed export, copied QR link, wrong-school access, compromised account, malware, unauthorised disclosure or provider incident must report it immediately to [incident contact] and the school’s approved contact.

The response owner must:

• contain the incident without destroying evidence;
• revoke affected accounts, sessions, QR tokens or links as appropriate;
• identify the information, people, systems, providers and time period involved;
• assess likely harm, including child-safety and physical-safety risks;
• notify the accountable school/agency immediately under the service arrangement;
• apply the relevant Queensland MNDB or Commonwealth NDB assessment and notification rules;
• communicate with affected people only through an authorised, safe plan;
• document decisions, notifications, remediation and lessons; and
• review whether collection, access or retention should change.

Queensland’s mandatory notification scheme applies to eligible breaches involving Queensland public-sector agencies under the Information Privacy Act 2009 (Qld). The Department and operator must agree who assesses and notifies; the operator must not delay notification to the Department while deciding whether the operator has a separate duty.

Where the Commonwealth Notifiable Data Breaches scheme applies, a suspected eligible breach must be assessed expeditiously; OAIC guidance describes 30 days as the maximum assessment period, not a target to wait for.

20. Children, Families and Child-safe Design

Children require a service designed around their safety, dignity, participation and evolving capacity—not merely a smaller adult privacy notice.

Before any student-facing rollout, the school and operator must evidence:

• the best interests and safety purpose of each student-facing feature;
• the most private and restrictive practical defaults;
• simple, age-appropriate explanations of QR cards, microphone indicators and reporting;
• no searchable or openly browsable student profiles; only the approved token-bound QR profile surface, with no peer/direct messaging, advertising or location sharing; the bounded Contact support request must not be represented as a private or emergency conversation;
• a child-focused complaint path that does not require legal knowledge;
• family information and involvement appropriate to the school context;
• accessibility and support for diverse needs;
• safe design for online and physical environments;
• training for staff who issue cards or respond to concerns; and
• recurring review against Queensland’s Child Safe Standards and Universal Principle.

The service must not replace mandated school child-protection reporting or create a private channel in which serious concerns are left unreported.

21. Leaderboards, Reports and Small Cohorts

Student-facing names use first name plus surname initial; cross-school/global views must further anonymise other-school students as designed. Teachers should still assess indirect identification risk from instrument, score, school initials, small cohorts, ties or unusual results before publishing or projecting any leaderboard.

Reports and exports can combine enough fields to identify a student even without a full surname. Select the minimum fields, confirm the recipient and apply school-approved storage, printing and disposal controls.

22. Changes to Privacy Practices

This policy must be re-audited before any change involving:

• real student/family contact information;
• public registration or new student/parent accounts;
• hosting, backup, support or monitoring providers;
• a new country of processing or support access;
• payment or subscription services;
• analytics, crash reporting or advertising;
• messaging, video, screen sharing or group sessions;
• microphone, transcription or automated assessment;
• account/data deletion behaviour;
• school-system integration; or
• native mobile permissions and store declarations.

Material changes require a new version, approval record, updated collection notices, provider/data-flow registers and appropriate notice before the changed handling begins.

23. Publication and Release Gate

No gate is complete merely because the application displays a green readiness card or this draft exists.

Authoritative Review Sources

These primary sources support the review framework and must be checked again at release time:

• Queensland OIC — Queensland Privacy Principles
• Queensland OIC — contracting and privacy
• Queensland OIC — privacy and technology
• Queensland OIC — disclosing personal information out of Australia
• Queensland Government — privacy rights and complaint pathway
• Queensland OIC — how to make a privacy complaint
• Queensland OIC — mandatory notification of data breaches
• Queensland Department of Education — privacy statement example and contact pathway
• Queensland Department of Education — student protection
• Queensland Government — Child Safe Standards and Universal Principle
• eSafety Commissioner — Safety by Design
• OAIC — Australian Privacy Principles
• OAIC — APP 11 security, destruction and de-identification
• OAIC — guide to developing an APP privacy policy
• OAIC — children and young people
• OAIC — what is a notifiable data breach?
• OAIC — complain to an organisation or agency first