What happens to a learner’s records.
Every learner is a real person with rights over their own record. Here is what we accept, how one customer is kept apart from another, and how a record leaves.
What we accept.
-
An ID that means nothing to us
A string your system picks, unique inside one project. The same string in two projects is two different people, and nothing links them. No names, addresses or emails.
-
What was delivered, and what followed
A lesson record names its type, skill, time and the version of your tutor, never the content itself. A check carries a score on its scale, whether help was used, and whether the question was new.
-
Nothing about how they behave
No keystroke timing, eye tracking, screen capture or reading speed. We go by what a learner answered without help.
-
No AI model in the loop
Records, receipts and experiments are worked out without a language model, and no learner data is sent to one.
-
Real records only after an agreement
A live project turns away every learner record until its use is on file: the signed agreement, the purpose, who does what, how long data is kept, where it lives and who processes it. Until then you can build an integration there, but it holds no learner data.
How one customer is kept out of another.
Every row knows which project it belongs to. Row-level security is switched on and enforced for those tables, the application’s database role can’t bypass it, and links between records include the project, so nothing can point across. The project always comes from the key that signed the request, never from anything inside it.
API keys are shown once and stored only in scrambled form (a keyed hash), never as the key itself. Expiry and revocation take effect on the very next request. Every write carries an idempotency key, so a retry after a timeout gets the original answer back instead of recording twice.
People reach a project only through membership in its organization, checked on every request, so a role change or a removal applies at once. A role grants exactly what it names, and an organization always keeps an owner. People join by invitation: a code that works once, for one role, and then expires.
An issued receipt can’t be updated, because the database doesn’t allow it. New evidence produces a new version next to it, so what was known at each moment stays on record.
Getting it out, and taking it away.
- export
- One learner’s records in a single file with a manifest. Each download is checked separately and expires after 24 hours.
- erasure
- Access stops at once. Then the learner’s records, and everything worked out from them, are removed through one reviewed path.
- re-import
- A keyed record of the erased ID refuses any later import that would bring the person back.
- restore
- Each erasure is also written to a ledger on a database branch of its own, outside any restore of the main one. A copy restored from before an erasure refuses every request until that erasure has been applied again. This has been rehearsed in the hosted sandbox, on its own invented data.
- retention
- By default, a scheduled job removes learner records after 30 days in a sandbox project and 90 in a live one.
What leaves the service.
-
Signed webhooks to your server
A webhook carries record IDs and statuses, never a learner’s ID or their evidence. It only goes to an https address outside private networks, it is signed, and it never follows a redirect.
-
And nothing else
No third-party analytics, no advertising, and no model trained on one customer’s records for another.
Reporting a security problem.
This page describes the service as built and tested. It hasn’t had an independent security review yet.
Write to security@outfigure.in, and please keep real personal data out of the report.