Audit Logging: Accountability Without Over-Collection
When you run a teaching studio, trust isn’t abstract.
You need to know:
• who changed something,
• what changed,
• when it happened,
• and which student or record it affected.
But you also need the opposite:
• not collecting more data than necessary,
• not retaining logs forever,
• and not creating new privacy risks in the name of “tracking.”
In My Music Studio, audit logging is designed to support accountability while staying tenant-safe, privacy-aware, and lightweight.
This article explains what we log, what we intentionally don’t, and why.
What audit logging is for (and what it isn’t)
Audit logs are not meant to be “surveillance.”
They exist for a few practical, studio-safe reasons:
1. Explain changes
• “Why did this student’s status change?”
• “Who edited the lesson details?”
2. Support troubleshooting
• When something looks wrong, logs help confirm what happened.
3. Enable responsible administration
• In multi-teacher environments, logs create clarity without requiring micromanagement.
Tenant-safe by design
Every audit event is tied to a school boundary.
That means:
• logs are captured with school_id,
• and can be filtered and managed per school.
This avoids cross-tenant leakage and keeps the logging model aligned with how studios operate in real life.
Capturing the right “who”
We record the actor in two ways:
• Auth identity (Supabase auth user)
• Internal identity (the teacher/admin record used by the teacher app)
This matters because it gives you both:
• a stable authentication reference,
• and a studio-scoped identity reference that aligns with permissions.
Importantly, the system resolves this automatically from the request JWT when logs are created via database triggers — without needing app-level logging sprinkled throughout the codebase.
Logging changes without storing entire records
A common logging mistake is capturing “everything” and hoping it’s useful later.
That creates risk:
• you end up retaining large amounts of personal data inside logs,
• logs become expensive to query,
• and it’s harder to reason about what actually changed.
My Music Studio takes a different approach:
• On UPDATE, we log the diff — what fields changed — and include the prior values.
• On INSERT, we can optionally allowlist which fields are recorded to keep payloads lean.
• On DELETE, we record the old row so deletions are explainable.
This is designed to provide accountability while keeping payloads compact and intentional.
Retention and pruning
Logs should not live forever by default.
To keep storage sane and reduce privacy risk, audit logs are pruned on a schedule based on a retention window (for example, 180 days).
This helps ensure audit logging remains:
• useful,
• performant,
• and proportionate.
Operational safety: a kill switch for bulk jobs
Sometimes you need to do large imports or bulk edits.
For those cases, the system supports an audit “kill switch” that can disable audit logging inside a transaction.
This prevents audit logs being flooded during controlled maintenance operations, while keeping normal day-to-day changes fully attributable.
Why this matters in education software
In music education contexts, software sits close to:
• children,
• families,
• schedules,
• notes,
• and records that studios rely on.
Audit logging is part of being a good steward of that environment.
The intent isn’t to log everything — it’s to ensure that when something changes, the system can answer:
• what happened
• who did it
• when
• within which studio
…without turning logs into a second database of sensitive personal data.
That balance — accountability without over-collection — is a core part of how My Music Studio is designed.