Back to blog
Engineering · 14 June 2026 · 6 min read

Data-Subject Rights Without the Ticket Queue

When a learner wants to see or correct their data, that should be a button, not an email to an inbox someone checks on Fridays. How Lattice Learn handles access and correction as self-service, by design.

Aditya Varma
Aditya Varma
Founder / Director

A learner emails support: “What do you actually hold about me, and can you fix my date of birth?” In most training systems, that sentence has just become a support ticket. It gets a number, joins a queue, and waits for a human to read it, decide who owns the answer, dig the records out of three places by hand, and write back — eventually. The request is a favour someone grants when they get to it. If the inbox is busy, it waits. If the person who knows where the data lives is on leave, it waits longer.

That model gets the law backwards. Under the Privacy Act and the Australian Privacy Principles, access to your own personal information and correction of it where it’s wrong are rights, not customer-service gestures. An organisation that holds personal information has to be able to give an individual access to it and to correct it on request, within reasonable bounds. Building that as a ticket queue means your compliance with a legal obligation depends on how full someone’s inbox is on a Friday afternoon. That’s a strange place to put a statutory duty.

A training platform feels this more sharply than most, because of what it holds. Competency records, assessment results, certificates, and the rules a person was auto-enrolled under are not neutral facts — they are close to someone’s livelihood, and in a safety context they sit adjacent to health information about who is cleared for high-risk work and who is restricted from it. That is exactly the category of data the law treats as sensitive. So Lattice Learn treats data-subject rights the way it treats everything else in the compliance schema the LMS lives inside: as a designed-in mechanism, not a manual process you hope someone remembers to run.

Access is a view, not a request

When learning lives in the same schema as compliance, “show me my data” stops being a scavenger hunt. The system already knows every record keyed to a person — their completions, their assessment outcomes, the certificates on the append-only certificate ledger, the mandatory rules they fall under, and the automated decisions made about them. There is no nightly export to reconcile and no second system to cross-check, because there is no second system. The data subject’s own record is assembled from the source of truth, on demand.

So access is self-service. A learner can open their profile and see what is held about them, rather than asking a human to go and find out. The point isn’t that a screen is friendlier than an email — it’s that the friendly screen and the legal obligation are now the same artefact. You can’t be slow to honour access when access is a page the person can already load.

Correction is a tracked request, not a buried one

Access is the easy half. Correction is where ticket queues quietly fail, because a correction is a change to a record, and changes to compliance records can’t be casual. You can’t let a learner silently rewrite their own assessment history, and you equally can’t ignore them when they say a field is genuinely wrong.

Lattice Learn splits the difference the way the Privacy Principles intend. A learner can lodge a correction directly from their own record — flag the field, state what it should be, submit. That request becomes a tracked object in the system, with a status and an owner, not a line in an inbox that gets read once and forgotten. It is queued as a correction, visible as one, and resolvable as one. The learner can see that it was received; the tenant can see that it’s outstanding. Nothing depends on a human happening to notice an email twice.

And because the request is structured data rather than free text in a thread, it carries the context the resolver needs: which record, which field, lodged by whom, when. The person actioning it isn’t reconstructing the request from a paragraph — they’re approving or declining a specific, bounded change. Where a correction can’t be made, the Principles still expect a record of the disagreement, and a structured request is what makes that possible rather than a thread that scrolls away.

The same logging that defends a record audits its correction

Here is where the architecture pays for itself twice. The same property that makes Lattice Learn’s records defensible — append-only, signed logging that you can’t quietly edit after the fact — is exactly what makes a correction auditable. We wrote about why those records hold up under a hostile reading in records you can defend. Correction is the other side of that coin.

When a field is corrected, the system doesn’t overwrite history and pretend the old value never existed. The change is logged: what the value was, what it became, who approved it, and when. The correction is itself an event on the trail, not a silent mutation of the past. That sounds like a tension — append-only records and the right to correct them — but it isn’t. Correction under the Privacy Principles was never “make the old truth vanish.” It’s “make the record accurate going forward, and be honest about the change.” An append-only log does precisely that: the current state is correct, and the history of why it’s correct is intact. A regulator asking “was this record altered, and on what basis?” gets a straight answer, because the alteration left a mark on purpose.

This is the quiet advantage of not bolting privacy on at the edges. A system that stored corrections by overwriting fields would have to choose between honouring a correction and keeping an audit trail. Because Lattice Learn’s records were append-only from the start, it does both at once — the correction is honoured and it’s evidence.

Privacy as a property, not a policy page

Plenty of platforms have a privacy policy. Fewer have privacy as a property of the data model. The difference is whether a data-subject right is something a human performs on request or something the system makes available by construction. We took the second path for the same reason we put learning in the base tier rather than behind a paywall: the things that matter most shouldn’t be the things that depend on someone remembering to do them.

It’s also why this sits comfortably alongside the rest of the records and privacy layer — retention schedules, signed disposal, the automated-decisions log — and why our trust and security posture describes data handling as architecture rather than aspiration. Australian-built, Australian-hosted, with the privacy obligations a sensitive-data platform carries built into the schema rather than promised in prose. When a learner asks what you hold and to fix what’s wrong, the right answer is a button — and the law, conveniently, agrees.

lms privacy engineering

Ready to see Lattice Look in action?

Five minutes to sign up. Free onboarding.