Studios teach children. We built like it.
Most software adds security as a checklist at the end. Cadence SM's biggest safety decisions are structural — they're in the database schema and the product design, where a bug in application code can't undo them.
Your studio’s data is walled off — by the database
Every studio is a tenant, and tenant isolation is enforced by PostgreSQL Row-Level Security on every single table. Even if our application code has a bug, the database itself refuses to hand one studio’s rows to another.
The technical layer
Every table carries an org_id column with an RLS policy; queries run inside a per-request transaction that sets the tenant context before anything executes. Nineteen narrow database roles separate concerns, and a CI job fails the build if any table is ever added without RLS protection. Cross-org foreign keys are structurally impossible (same-org composite FKs).
Students sign in like students
Children don’t have email addresses — so student sessions use a PIN, scoped to their own practice world, with database-backed lockout against guessing. A student session physically cannot reach billing, other students’ data, or staff tools.
The technical layer
Student PIN sessions are a structurally distinct session type from staff/parent logins — endpoints must explicitly opt in to accept them. COPPA-motivated RESTRICTIVE database policies further constrain what any student-scoped query can touch, on top of RLS.
No private teacher–minor DMs. Not discouraged — impossible.
Messaging is organized into per-student channels that parents can see. The system has no mechanism for a private one-on-one conversation between a teacher and a minor — the safe pattern is the only pattern.
Lesson audio never reaches a third party
Lesson transcription is processed only on our own servers, by a dedicated worker process. No third-party transcription or AI service ever receives it, no "we may use recordings to improve our models" — if that worker isn’t available, the feature refuses to run rather than falling back to an outside service.
The technical layer
Transcription runs on a self-hosted whisper.cpp engine on our infrastructure, fail-closed, with retention windows. Audio is deleted as soon as the job finishes, whether it succeeds or fails. The no-third-party-egress property is enforced by an automated test, not a policy document.
An audit log nobody can quietly edit
Financial and administrative actions write to an append-only audit log. "Who changed this invoice?" always has an answer, and the answer can’t be rewritten.
Two-factor for the people who hold the keys
Staff accounts can enroll TOTP two-factor authentication (any standard authenticator app). Changing or resetting a password revokes every other session for that account immediately — not whenever an old token happens to expire — and the same instant revocation fires if a studio is ever suspended.
The audit log records facts, not children’s words
Audit entries are data-minimized by design: who did what, when, to which record — ids, counts and statuses, never the text of a student’s practice reflection, a teacher’s written critique, or a family’s chat. Login telemetry is pruned on a retention schedule with a hard 30-day safety floor enforced by the database itself.
This website practices what the product preaches
No third-party trackers, no ad pixels, no analytics cookies. Fonts are self-hosted, so not even a font CDN sees your visit. The only data this site can send anywhere is the contact form — when you press the button.
Questions a cautious owner should ask
Bring your district's tech-vetting checklist, your studio's COPPA worries, or your own skepticism — we enjoy this conversation.
Talk to us