Draft status — not terms currently in force and not legal advice. This document is a product, school and legal-review working paper. It must not be presented as an accepted contract until every placeholder, commercial term, contact, privacy statement and operational promise has been approved and verified against the released service. Current operating boundary: Prototype — fictional demonstration data only. The current build is not a public registration service and must not be used to create a false impression that production privacy, support, billing or availability obligations have been completed.

Document Control

1. Purpose and Intended Users

Band Licence is intended to help authorised instrumental music teachers and schools manage programme administration, including:

• student and ensemble setup;
• rehearsal and lesson attendance;
• scheduling and timetable exclusions;
• teacher-assessed progression and pass-offs;
• method-book checkpoint metadata;
• manual practice records and selected student practice-tool results;
• reports, licence cards and limited QR-linked student views; and
• teacher-approved lesson or rehearsal summaries where separately enabled.

The service is not a student information system of record, emergency service, child-protection reporting system, medical record, behaviour-management system, general family messaging service or automated assessor. A school must keep its required official records and fallback processes in the systems approved for those purposes.

2. When These Terms Would Apply

These draft terms are intended to apply only after the service operator has published an approved version and the authorised customer has accepted it through an agreed process. Clicking through an unfinished prototype, receiving a demonstration link or using fictional data does not make this draft a final contract.

The final agreement must identify:

• who is buying or authorising the service;
• whether the customer is a Queensland state school, non-state school, school system, home studio or individual teacher;
• who can accept the terms for that customer;
• which order form, data-processing terms and school policies also apply; and
• which document prevails if the documents conflict.

For a Queensland state-school deployment, school-level approval alone may not be enough. Departmental procurement, information-security, privacy, records-management and contracted-service-provider requirements must be completed before use with real data.

3. Responsibilities for Personal Information

The final agreement must allocate responsibilities without relying only on overseas terms such as “controller” and “processor”, which are not themselves the operative labels under Queensland or Commonwealth privacy law.

The intended allocation is:

• the school or employing authority decides the authorised educational purpose, which people are in scope, what records may be entered, who may access them, and the applicable retention rules;
• the service operator handles school information only to provide, secure, support and lawfully administer the agreed service;
• Administrators configure school access and periodically review roles, exports, QR access, support requests and deletion requests;
• teachers enter and correct only relevant music-programme records; and
• each party remains responsible for its own legal, contractual, child-safety and records-management duties.

For a Queensland Government agency arrangement involving personal information, legal and procurement review must determine whether the operator must be bound as a contracted service provider under Chapter 2, Part 3 of the Information Privacy Act 2009 (Qld). The contract must then address the Queensland Privacy Principles, overseas disclosure, access and correction, security incidents, subcontractors, return/deletion and audit evidence.

For a non-state school or private studio, the parties must determine whether the Privacy Act 1988 (Cth), the Australian Privacy Principles, consumer law, child-safe requirements and any sector or contractual rules apply. These terms do not decide that question.

4. Accounts, Invitations and Authority

Current secure staff accounts are invite-based and school-scoped. Administrator, Teacher and Read-only roles exist; Student and Parent/Carer accounts are future roles and must remain unavailable until separately approved.

Users must:

• provide accurate staff account information;
• use only their own account and keep credentials confidential;
• use school access only for authorised work;
• sign out on shared devices;
• report suspected compromise, wrong-school access or a lost QR card promptly;
• not share invitation, password-reset, verification or native sign-in links; and
• comply with the school’s acceptable-use, records, privacy and child-safety requirements.

Administrators must remove or disable access promptly when a person changes role or leaves. The service operator may temporarily restrict access where reasonably necessary to protect users or data, investigate misuse, comply with law, or maintain the service. The final terms must include notice, review and restoration rules for any suspension.

The transitional email-only pilot sign-in is not verified email authentication and must be disabled before broader account use.

5. Student Information and Data Minimisation

During the current prototype stage, users may enter fictional demonstration data only.

Any later real-data use requires a written school approval that defines the minimum fields. Users must not enter student photos, dates of birth, home addresses, medical information, school identification numbers, private family circumstances, unrelated behaviour information or sensitive custom statistics.

The current codebase contains optional student email and home-contact fields in roster, import and export workflows. That implementation is outside the present prototype privacy boundary. Those fields must not be populated with real details unless the product scope, privacy notice, authority, security, access controls, retention and family-facing process have all been deliberately approved. Otherwise they must be removed or disabled before wider use.

Free-text notes must be factual, respectful, necessary for instrumental music teaching and suitable to be read by the student or family. Users must not use free text to evade the restricted-data rules.

6. QR Cards and Student Views

QR cards are bearer links: anyone who obtains a valid card or copied link may start the profile-access process. They are not a substitute for a fully verified student account.

The implemented flow exchanges a random profile token for a short-lived, school- and student-bound session. A four-digit student security code must be entered, or established on first use, before the session unlocks. Progress and attendance information is read-only. The student area can also perform narrowly scoped updates for practice timers/tracking, locally assessed mission and sight-reading results, friend choices, fixed-catalogue avatar purchase/equip actions, server-scored theory challenges and bonus rounds, and challenge-bound Tuning Darts results.

An authorised teacher may issue a revocable school access code for family entry. The code must be paired with the student's existing licence card and private PIN, does not reveal a school roster, and does not create a paid student account. Students are not charged and do not need email addresses.

The student Contact action can persist a bounded student-authored subject and message as a school-scoped support/correction request. It is not a private conversation or emergency channel. Before real student use, the final service arrangement and family-facing material must define its purpose, authorised staff access, moderation and safeguarding escalation, response target, correction, retention and deletion. The presence of the route does not approve that use.

Users must:

• give cards only to the intended student under the school’s approved process;
• explain how to keep the card private;
• avoid posting or forwarding QR links;
• report lost, copied or misdirected cards; and
• reissue the student’s profile access when compromise is suspected.

Cards and public student views must not expose teacher tools, full surnames, contact details, photos, private notes, database identifiers or other students’ private records.

7. Practice, Tuner and Audio Boundaries

Manual practice records must remain labelled Manual practice log — unverified. The service does not verify that a student practised merely because time was entered or a timer ran.

Optional tuner, sight-reading, mission and Tuning Darts pitch-analysis controls 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, not audio. Practice logging remains manual and unverified, and verified automatic practice detection is not included. The separately gated Lesson Note workflow below is the sole permitted microphone recording/transcription exception and is not a substitute for teacher assessment.

The tone generator and metronome generate sound locally and do not require microphone access.

Custom feedback sounds must not contain student voices, identifying information or material the uploader is not authorised to use.

8. Lesson Notes

When an authorised teacher opens a teaching date, the service may automatically store one name-minimised Prepared Draft for each active scheduled lesson and rehearsal. A prepared record uses a privacy-neutral time/type label and internal occurrence key. It does not prove the session occurred and is not approved teaching content.

Lesson Notes may use microphone assistance only after an authorised teacher deliberately arms the selected teaching date once. That single arm covers the combined list of writable lessons and rehearsals for the date. Normal startup and page opening remain audio-free. After arming, active scheduled sessions may start/stop temporary capture at their timetable boundaries with a persistent indicator and Stop/Discard controls. Processing uses only the approved authenticated loopback engine on the app host. Audio and raw transcript text must be destroyed and never stored; only a privacy-filtered Candidate Draft may be saved. The workflow does not use cloud transcription, generative AI, automatic assessment, automatic sign-off or automatic delivery.

Teachers must replace prepared prompts with concise teaching content, remove names and identifying details, and complete sign-off before copying or controlled sharing. A server-side identifier check is only an aid and does not replace teacher review.

An in-app checkbox is evidence of a local review step, not legal authority or consent. Capture remains locked unless the required school, privacy, child-safety, data-minimisation, correction, local-engine and explicit environment gates all pass.

Untouched Prepared Drafts may be refreshed or archived when the timetable changes. Teacher-edited Drafts and signed records must not be silently overwritten or removed. Schools must define access, retention, correction, backup and approved sharing arrangements before real-data use.

9. Acceptable Use

Users must not:

• access or attempt to access another school, account or student without authority;
• defeat role checks, rate limits, QR security codes or audit controls;
• disclose credentials, QR tokens, profile links or exports to unauthorised people;
• collect prohibited or unnecessary personal information;
• upload malware or use the service to harm, intimidate, profile, advertise to or monitor children;
• use student-to-student messaging or public posting through the service;
• use microphone functions for covert recording or general surveillance;
• use the service for automated high-impact decisions about a child;
• scrape, reverse engineer or overload the service except to the extent the law does not permit that restriction;
• remove the visible prototype notice during the prototype stage; or
• infringe copyright, confidentiality, privacy or other rights.

Suspected child-safety concerns must be handled through the school’s approved child and student protection procedures, not through an ordinary app support request.

10. Copyright and Teacher-supplied Material

Users retain responsibility for material they enter or supply and must have the authority to use it.

Method-book import is intended to extract limited checkpoint metadata from a locally supplied document. It must not reproduce or redistribute copyrighted method-book notation, pages, lyrics, scans or images. Users must not treat the service as permission to copy music.

The service operator retains rights in the service, branding and original software subject to any licences stated in the final agreement. The final terms must specify licences for customer data, feedback and exported material narrowly enough to provide the service without claiming ownership of school records.

11. Exports, Printing and Sharing

Exports can create portable copies outside the service’s access controls. The user initiating an export is responsible for:

• selecting only necessary students and fields;
• checking accuracy and the intended recipient;
• using an approved storage and transfer location;
• avoiding insecure personal email or consumer file-sharing services unless approved;
• retrieving printed pages promptly; and
• securely disposing of superseded copies.

The service operator must document any export it performs for support or deletion handling and must not use exported school information for a new purpose.

12. Availability, Accuracy and Fallbacks

The current pilot carries no production availability commitment. Users must keep a manual attendance fallback, verified backups and a tested restore process.

The app can contain defects, and generated schedules, statistics, music exercises, summaries and reports may be incomplete or wrong. Teachers remain responsible for checking outputs before relying on or sharing them. No feature replaces professional teaching judgement, safeguarding judgement or a school’s official records.

Any future service level, maintenance window, support priority, recovery objective or data-restoration promise must be stated in a signed service schedule and supported by measured evidence before it appears in public terms.

13. Backups and Customer Responsibilities

Backups may contain the same personal information as the live database. The responsible Administrator must follow the approved backup schedule, restrict backup access, verify integrity, rehearse restoration, protect encryption material separately and apply the approved retention schedule.

The final agreement must say who operates backups, where they are stored, which party holds encryption keys, what happens at contract end, and which recovery outcomes are commitments rather than goals.

14. Subscriptions, Charges and Refunds — Future Only

The repository contains entitlement and billing-readiness scaffolding. It does not establish a live paid subscription, pricing promise or payment-provider integration.

Before charging anyone, the final order form and terms must clearly state:

• price, GST treatment and billing party;
• School or Studio plan scope and the included staff/student limits;
• trial duration and what occurs when it ends;
• plan limits and fair-use rules;
• renewal, price-change and cancellation process;
• school transfer and account-owner rules;
• failed-payment and grace-period treatment;
• App Store, Google Play and direct-sale differences; and
• refund and remedy rights.

Nothing in the final terms may exclude, restrict or modify a consumer guarantee or other right that cannot lawfully be excluded under the Australian Consumer Law. “No refunds” wording must not be used as a substitute for the remedies required by law.

15. Account Closure and Data Requests

The public /account-deletion page is information and navigation only. A signed-in secure account can submit a review request, and Administrators can manage its status in Global Settings. There is no approved former-user external intake. These controls do not delete an account, school workspace, student records, backups or provider copies. Marking a request “completed” is not evidence that technical deletion occurred.

Before public account creation, users must have a clear in-app and external pathway consistent with the final privacy policy and store requirements. Account access removal, staff-account deletion, school-data deletion, student-record disposal and backup expiry are separate decisions and may have different authorised owners and retention duties.

The operator must explain what was deleted, what was retained, why, for how long, and how the requester may complain. The sole Administrator must transfer or close the school workspace through an approved process before their account is deleted.

16. Complaints, Incidents and Child-safety Escalation

The final published terms must provide real contact details and distinguish:

• service support and correction requests;
• privacy access, correction and complaints;
• security incidents and lost credentials/QR cards;
• billing disputes; and
• urgent child-safety or emergency reports.

The operator must acknowledge and triage reports against documented service targets. A privacy complaint involving a Queensland state school should be directed to the school/Department pathway first, with the operator cooperating as required by the approved service arrangement. A private-sector complaint should follow the operator or school pathway identified in the final privacy policy.

The app’s support queue is not an emergency service. Immediate danger must be reported through emergency and school child-protection channels.

17. Ending Use

The final agreement must cover notice, export, access revocation, outstanding charges, transition assistance, return or deletion of data, backup expiry, audit evidence and any terms that continue after termination.

Ending an individual staff account must not silently destroy records another authorised school user needs. Ending a school service must not leave active public QR tokens, sessions, native sessions, scheduled backups or unmanaged copies.

18. Liability and Disclaimers for Legal Review

Legal review must draft any warranty disclaimer, indemnity, liability cap and exclusion for the actual parties, risk allocation, insurance and purchasing channel. No clause may exclude liability or remedies where exclusion is prohibited by law.

The final drafting should specifically consider:

• loss or corruption of school records;
• unauthorised disclosure or security incidents;
• misuse of QR links or exports;
• infringement in teacher-supplied material;
• failure to follow school instructions;
• business interruption; and
• child-safety obligations that cannot be transferred to software.

This section deliberately makes no release-ready limitation-of-liability claim.

19. Governing Law and Disputes

The proposed governing law is Queensland, Australia, subject to final legal review and any mandatory jurisdiction. The final terms should require good-faith escalation between authorised contacts before proceedings, without preventing urgent relief, regulatory complaints or non-excludable rights.

20. Changes to Terms

The operator must version the terms, retain the accepted version, describe material changes and give appropriate notice. Material changes to student access, data use, providers, overseas handling, retention, payments, microphone use or automated processing require privacy, school and child-safety review before release; a generic right to change terms is not enough.

21. Publication Gate and Evidence Register

No gate should be marked complete merely because this draft exists.

Authoritative Review Sources

These links support final review; they do not replace advice for the actual deployment:

• Queensland OIC — Queensland Privacy Principles
• Queensland OIC — contracting and privacy
• Queensland Government — privacy rights
• OAIC — Australian Privacy Principles
• OAIC — children and young people
• Queensland Government — Child Safe Standards and Universal Principle
• Queensland Department of Education — student protection
• Australian Government — Australian Consumer Law and business
• Apple — App Review Guidelines
• Google Play — User Data policy and account deletion