Music Lessons Network · Vetted instructors · Parent-visible comms · Consent-first · Early access · 2026

Parental veto is the default — the vetted music lesson network where every relationship requires explicit consent and every message is parent-visible

Music Lessons Network is built for school music directors and privacy-conscious families. Every student starts with no consent granted to any instructor. A parent must explicitly opt in before a lesson relationship opens. All instructor-family communication routes through the parent-visible app channel — there is no private student inbox, not by policy but by architecture. Instructor vetting is auditable by design: the policy is published in full, and no instructor is meant to appear in results until every required check is green — the vetting pipeline and directory are in active development. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How vetting works

Veto by defaultno relationship opens without a parent’s explicit opt-in — no-response is not consent

Auditable vettingthe vetting policy is published in full, not a badge — the pipeline and directory are in active development

Parent-visible commsevery instructor-family message is in the parent-visible channel — code enforces it

School director modebulk roster import + consent batching built — no single-family enrollment friction

Auditable instructor vetting — the policy is published, not badged

No instructor appears in results until every required check is green — and you can read exactly what that means before you enroll

Most lesson platforms run a background check and show a badge. Music Lessons Network publishes the vetting policy in full: which check types are required, what credentials are verified, what the reference review covers, and what an in-person orientation requires. A music director or parent can read the full policy before trusting it with a student.

The vetting pipeline is designed to record each check type, the date it cleared, and the credential source. An instructor’s profile is not listed until every required check is green. If a check lapses or is revoked, the profile is suppressed automatically — no one needs to remember to pull it down manually. If the active vetting policy is updated and a new check type is added, existing instructor profiles are re-evaluated and suppressed if they no longer clear. The policy is not a snapshot; it is a live requirement.

The instructor vetting pipeline and the vetted-profile directory are in active development — there is no live vetting engine or directory in the platform today. The booking interface that turns a vetted instructor’s availability into a confirmed lesson is likewise in active development and honest-off for live booking confirmation today.

Book a conversation Full platform

How it works

From roster import to lesson delivery in four stages

Music Lessons Network runs on a consent-first rhythm: roster import and consent collection before the first lesson, instructor vetting before the first directory result, lesson delivery through parent-visible channels, and a clean term close with portable records. Every stage is described as it is built today.

Step 1 · Program setup — roster import and consent collection

A school music director or studio owner imports the student roster before the first lesson. The platform generates per-student consent requests addressed to each family. Consent is collected at this stage, not assumed. A family that declines does not receive follow-up pressure; their status is recorded as declined and the student is excluded from lesson assignments until consent is granted. The consent ledger is populated before any instructor sees any student name. Families who opt in are added to the parent-visible communication list. The organisation owns its student and family data from the first import.

Step 2 · Instructor vetting — policy review and check clearance

Each candidate instructor goes through the vetting pipeline before their profile appears in any directory result. The vetting policy is reviewed by the organisation; required checks are configured per instructor type. The pipeline records each check type, the date it cleared, and the credential source. An instructor whose checks are all green is listed; an instructor with a pending or lapsed check is suppressed. The organisation does not need to remember to pull the profile down manually — the suppression is automatic. When a check lapses, the profile goes dark until it is renewed and re-cleared. The instructor vetting pipeline and directory described here are in active development and not live today.

Step 3 · Lesson delivery — scheduling, parent-visible communications, and session records

With consent granted and vetting cleared, lesson assignments are made against the student roster. All instructor-family communication routes through the parent-visible app channel. A parent can see every exchange between their child and the instructor from the moment the relationship opens. Session records (attendance, notes, progress) accumulate against the student-instructor pair in the organisation’s ledger. The per-lesson booking interface and confirmation flow are in active development; the booking surface is available to navigate but does not initiate a live charge or confirmed booking today.

Step 4 · Term close — records export, consent status review, payout projection

At the close of a term the organisation exports its complete records: session history, attendance, communication logs, consent status per student, and vetting status per instructor. Every record is in a portable format the organisation can read without the platform. Instructor payout projection — the per-session fee math and the platform-fee split — is visible in the ledger; the charge rail that moves money is honest-off. An organisation can see exactly what the disbursements would be before the rail is live. Consent status is reviewed; families who did not renew for the next term are not carried forward automatically.

The full platform

Five engines — honest about what is built and what is coming

Every feature is labelled honestly: Built means the underlying engine is production-ready. In development means the surface, wire-up, or carrier integration is in active build. We do not claim otherwise.

Auditable instructor vetting — the policy is published, no instructor appears until every check is green

The vetting model is auditable by design: the pipeline records each check type, the date it cleared, and the credential source, and an instructor’s profile does not appear in directory results until every required check in the active vetting policy is green. The vetting policy is published in full — not summarised as a badge or a star rating — so a music director or parent can read exactly what the vetting covers before enrolling. When a check lapses or is revoked, the profile is designed to be suppressed automatically, with no manual intervention. The instructor vetting pipeline and the vetted-profile directory are in active development; they are not built today and we do not list them as production-ready.

Vetting pipeline + directory in development · auditable-policy design

Parent-visible communication — no private instructor-student channel, enforced at the code layer

Every message between an instructor and a student’s family routes through the parent-visible app channel. There is no private student inbox, no direct message path that a parent cannot see, and no SMS or external channel that bypasses the record. The constraint is enforced by the channel architecture — not by a policy reminder. A parent sees every message their child’s instructor sends and every reply their child sends back. An organisation can pull a full communication log for a student-instructor pair at any time. The messaging channel infrastructure is built. Delivery to parent devices runs through the provider key layer, which is honest-off without a configured provider key.

Parent-visible channel built · delivery key-gated

School music director mode — bulk roster import, per-student consent batching, no single-family friction

A school music director imports a class roster in one operation — from a spreadsheet, a CSV, or a supported directory export. Consent collection is batched: the platform generates per-student consent requests that go to each family on the roster, rather than requiring every family to navigate enrollment individually. No lesson relationship opens for any student until that student’s family has returned a consent grant. The director sees a roster-level consent status dashboard: which families have responded, which are pending, and which have declined. Declined families are recorded as declined; no follow-up message is sent automatically. School music director bulk enrollment and the roster import flow are built and production-ready.

School director enrollment built · bulk consent batching built

Per-lesson booking and instructor payout — early-access, charge rail honest-off

The per-lesson booking interface — time-slot selection, instructor availability, session-pack configuration, and the scheduling calendar — is in active development. The platform-fee checkout and instructor payout rail are honest-off: they exist in the platform substrate but are not enabled for live transactions today. There is no live booking confirmation, no live billing, and no live payout. A family navigating the platform today reaches the booking surface in its current state and can see the intended flow, but no charge is initiated and no booking is confirmed through a live payment. When the charge rail is enabled (a founder-gated decision), organisations will be notified.

Booking interface in development · charge rail honest-off

For school music directors

One roster import, consent batched, no family navigates enrollment alone

The music director’s view

A music director enrolls the whole class in one roster import. Consent requests go to each family automatically — the director does not chase individual sign-ups. The consent dashboard shows which families have responded, which are pending, and which have declined. No student is enrolled without their family’s explicit opt-in. The director sees every active lesson relationship, every instructor’s vetting status, and every pending consent in one dashboard.

The parent’s view

A parent receives a consent request addressed to their child by name. They review the instructor’s vetting record and the published vetting policy before opting in. Once they opt in, every message from the instructor is visible in their app view. They can see the full communication log between their child and the instructor at any time. They can withdraw consent in one action, closing the instructor’s access to their child’s record immediately.

What is honest-off for schools today

The per-lesson booking confirmation and the platform-fee checkout are honest-off today. A school partner can see the full lesson scheduling flow in a demonstration, but no live booking is confirmed and no charge is initiated. School-partnership data-processing agreements are available for review. FERPA-aware data handling is the operating posture; student data does not cross external service boundaries. Calendar sync with a school’s existing scheduling system is on the roadmap.

No private instructor-student channel — enforced at the architecture layer

Every message is parent-visible. Not because of a policy — because there is no other channel.

A private instructor-student inbox — one the parent cannot see — is a structural vulnerability when working with minors. Music Lessons Network removes it at the architecture layer. The messaging channel is designed so that a parent and the instructor communicate through the same thread the student can see, and the student communicates through the same thread the parent can see. There is no separate student view, no direct path, and no external channel that bypasses the record. An organisation can pull a full communication log for any student-instructor pair at any time.

This is not a feature that can be toggled off. It is not a permissions setting an instructor can request to change. The channel architecture does not include a private student inbox. The communication infrastructure is built and production-ready. Delivery to parent and instructor devices runs through the provider key layer, which is key-gated for live send.

Student data & family consent

Your data. Your organisation’s data. Consent-gated, never sold, delete-on-request logged.

Student and family data belongs to the organisation — the school, studio, or program director — not to the platform. No student name, record, or identifier crosses external service boundaries. No behavioral or location tracking runs on minor students. No student data is sold to or shared with advertisers or outside companies. Consent is per-student and per-instructor-relationship: a family that opts in to one instructor does not automatically opt in to any other.

On a consent withdrawal, the instructor’s access to that student’s record closes immediately and the event is logged in the consent ledger. On a full deletion request, personally identifiable information is removed from active systems within the stated retention window; the deletion is logged and auditable. A one-click export is available in writing: if the organisation ever leaves the platform, every record leaves with it — session history, communication logs, consent status, vetting records — in a portable format readable without the platform.

What is built and what is coming — plainly

The consent and communication engines are built. The vetting pipeline and booking checkout are not live yet.

Built and production-ready today: the per-student, per-instructor-relationship consent ledger (parental veto as default, explicit opt-in required, withdrawal closes access immediately); the parent-visible messaging channel infrastructure (no private student inbox, organisation-level communication log); and the school music director bulk-enrollment and roster-import flow (per-student consent batching, roster-level status dashboard).

In active development: the instructor vetting pipeline and vetted-profile directory (designed so each check type is recorded by date and source, with suppression automatic on lapse). Not yet enabled for live use: the per-lesson booking interface and confirmation flow, the platform-fee checkout, the instructor payout rail, and live delivery for the parent-visible messaging channel (key-gated). These are honest-off — present in the platform, not enabled for live transactions. There is no live checkout here. No billing. No subscription. We say so directly because music directors and families deserve to know what is production-ready and what is still being wired.

Connected to the school platform

Lessons network, music school software, and the school publishing platform — built on the same consent spine.

Music Lessons Network is the vetted-instructor layer for individual and group lesson relationships. musicschool.software is the operating platform for music school owner-operators: scheduling, enrollment, recital operations, and family communication in one place. Both ride the same consent ledger and family-data rails. Assembly is the moment layer: recitals, concerts, and performances captured and archived with consent-gated media delivery. Seen is the recognition layer: every student musician and performer on a real, adviser-approved page. The school publishing platform at homeroom.software is the substrate all of these build on.

musicschool.software assembly.school seen.school homeroom.software

Early access · School music directors, studio owners, and privacy-conscious families

Book a conversation to see the current state honestly

Music Lessons Network is in active development. We do conversations that show the current state honestly: how the consent ledger flow works (opt-in per instructor relationship, immediate access revocation on withdrawal), how the vetting pipeline is designed to record and enforce check clearances (in active development), how the school director roster import and consent-batching dashboard works, and how the parent-visible messaging channel is structured. None of those involve live payments. If it looks right for your school or studio, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

Is the lesson booking checkout live? Can families book and pay right now?

Not yet. The booking interface — time-slot selection, instructor availability, session-pack configuration — is in active development. The platform-fee checkout and instructor payout rail are honest-off: they exist in the platform but are not enabled for live transactions today. There is no live booking confirmation, no billing, and no subscription. When the charge rail is enabled, organisations will be notified. The call to action here is “book a conversation,” not “book a lesson.”

What does “parental veto is the default state” mean in practice?

Every student starts with no consent granted to any instructor. A parent must explicitly opt in before a lesson relationship can open — before the instructor can see the student’s profile, and before any communication can be sent. The system does not flip a student to “consented” because the parent did not respond; no-response is treated as no-consent. Veto is the default. Opt-in is the active choice. A parent can withdraw consent at any time; on withdrawal the instructor’s access to the student record closes immediately and is logged in the consent ledger.

Why is all instructor-family communication parent-visible? Isn’t that inconvenient?

A private instructor-student channel — one the parent cannot see — is a structural risk when working with minors. Music Lessons Network removes that risk at the architecture layer, not by asking everyone to follow a policy. The parent-visible channel means every message a student’s instructor sends, and every reply the student sends back, is visible to the parent in the same app view. An organisation can pull a full communication log for any student-instructor pair at any time. There is no workaround, because there is no alternative channel.

How does the instructor vetting process work?

The vetting pipeline is designed to record each check type, the date it cleared, and the credential source, with required checks configured per instructor type. An instructor’s profile is not meant to appear in directory results until every required check in the active vetting policy is green, and if a check lapses or is revoked the profile is designed to be suppressed automatically — so no instructor “slips through” a missed manual suppression. The vetting policy is published in full so a music director or parent can read exactly what it covers. The vetting pipeline and vetted-profile directory are in active development today — not yet built or live.

How does bulk enrollment work for a school music director?

A school music director imports the class roster in one operation — from a spreadsheet, a CSV, or a supported directory export. The platform generates per-student consent requests addressed to each family on the roster. A director does not need every family to navigate an enrollment form individually. The director’s dashboard shows a roster-level consent status: which families have responded, which are pending, and which have declined. Declined families are recorded; no follow-up message is sent automatically. No lesson relationship opens for any student until that student’s family has returned a consent grant.

What is the platform fee model?

The model is described plainly, but no live checkout runs today. The platform charges a per-student active fee that scales with the number of active lesson relationships. Instructors receive their session fee minus the platform margin; the split is visible in the ledger before the charge rail is live. There is no subscription billed on a credit card today, no free-trial that auto-converts, and no pricing page that transacts. When the charge rail is enabled, the fee structure will be published in full and organisations will be notified before anything bills.

How does Music Lessons Network handle FERPA and COPPA obligations?

Student data is owned by the organisation — the school, studio, or program director — not by the platform. No student name, record, or identifier crosses external service boundaries; only aggregate counts and opaque program references are used for internal telemetry. No behavioral or location tracking runs on minor students. No student data is sold to or shared with advertisers or outside companies. The platform operates on a consent-first model: a student’s data is not processed for any purpose beyond the lesson relationship without an explicit consent grant. FERPA-aware data-sharing agreements are available for school partnerships; organisations handling child data under COPPA should review the data-processing agreement before enrolling students under 13.

What happens to a student’s data if a family withdraws consent or leaves the platform?

When a family withdraws consent, the instructor’s access to that student’s record closes immediately and is logged in the consent ledger. The student’s session history and communication log remain in the organisation’s ledger — owned by the organisation, not exported to the instructor. On full deletion request, the student’s personally identifiable information is removed from active systems within the stated retention window; the deletion is logged. A one-click export is available in writing: if the organisation ever leaves the platform, every record leaves with it in a portable format. Deletion is logged and auditable.

What is in a vetting record? What does the published policy actually cover?

The vetting policy is published in full on the platform before any director or family is asked to trust it. A vetting record for an instructor includes: the check types required (background check, credential verification, reference review, in-person orientation), the date each check cleared, and the source used. No instructor appears in directory results until every required check in the active policy is green. If a new check requirement is added to the active policy, existing instructor profiles are re-evaluated against the updated requirements and suppressed if they no longer clear. The policy is not a badge; it is a readable document. The vetting pipeline and directory that enforce it are in active development, not yet live.

What can a school or family actually use right now?

In a demonstration today we walk through the platform honestly: the consent ledger flow (how a parent opts in per instructor relationship, how withdrawal closes access immediately), the vetting pipeline (how a check is recorded, how a lapsed check suppresses a profile), the school music director roster import and consent-batching dashboard, and the parent-visible messaging channel. None of those involve live payments. The booking interface is available to navigate; no charge is initiated. A conversation is the honest next step — we show what is built, what the booking and payout timeline looks like, and what early access means for a school or studio.