How a lesson becomes a receipt.
Your app tells OutFigure what the tutor did and how the learner answered afterwards. OutFigure matches the two and hands back a receipt: what happened next, and what the evidence can’t back up.
What happens, step by step.
-
You send what happened
What the tutor delivered, for which skill, when, and from which version of your tutor. Send the same record twice and it is stored once. Send different content under the same ID and it is turned away.
-
A plan starts the clock
The plan says what evidence to wait for. The standard one wants a check 1 to 30 minutes after the lesson, then retention and transfer checks 4 to 10 days later, done without help.
-
Checks come in
Each check says how it was scored, whether the learner had help, and whether the question was new to them. If nobody recorded whether there was help, OutFigure never assumes there was none.
-
You get a receipt
It lists every piece of evidence it looked at and why each one counted or didn’t. When more evidence arrives or a window closes, you get a new version, and the old one stays as it was.
What is on a receipt.
A receipt describes one lesson, and says nothing about the learner as a person. It names the versions of the rules that produced it, so the same records always give the same receipt.
- status
- still waiting, evaluated, or not enough evidence
- how far it reaches
- from nothing usable (MD0) to a later check on something new (MD4)
- how sure of the cause
- from can’t say (CS0) to a fair test, repeated (CS4)
- observed outcome
- where the learner started, where they ended up, and the change
- lasting
- right after and later on, kept apart
- evidence
- everything considered, and why it counted or didn’t
- warnings
- what the receipt can’t back up
When you need to know what caused it.
A receipt tells you what followed. To learn what a change to your tutor caused, you need a fair test where learners get versions at random, and OutFigure runs those too.
-
Plan first, then seal it
You say up front which versions you’re comparing, how learners are split and what counts as a result. Once the test starts, the plan is sealed and can’t be changed.
-
Fair, repeatable groups
Each learner’s version is picked at random from their ID, the same way every time, so nobody can be quietly moved to the group that looks better.
-
Compared on what followed
Versions are compared on how learners did later, counting those who really got the version they were given. Each comparison shows its margin of error, who saw what, whose results are missing, and whether the split came out as planned.
-
No peeking
Nothing is estimated until every version has enough learners with results and every check’s time has run out.
What the evidence says to do next.
Two parts turn results into advice for your team. Neither one acts on a learner.
-
Should this version ship?
For each new version in a fair test, a fixed rule says release it, hold it back, have a person decide, or don’t release it. It reads the main result the plan named and the checks on the test itself. Your release process acts on it. OutFigure releases nothing.
-
What next for this learner?
For one learner and one skill: check them first if they haven’t answered on their own since they were taught, use a version a fair test backs, or run a test because nothing is proven yet. Off until you turn it on, and never shown to a learner.
-
Rules you can read
Both are short rules with a version number, spelled out in the API reference. Neither has yet been tested against real outcomes, and each answer says so.
Try it on your old logs first.
Before you build anything, run our audit tool on an export of what your tutor did and the checks that came after. It runs on your own computer, sends nothing anywhere, and shows you the receipts you would have got and what your data can really support.
| Question | Kind of answer | Can your data answer it? |
|---|---|---|
| Are the records clean enough to use? | what happened | supported |
| Did checks come back after lessons? | what happened | supported |
| Were there checks a week or more later? | what happened | supported |
| Were there checks on questions the learner hadn’t seen? | what happened | supported |
| Can teaching styles be compared? | a pattern | supported |
| Can it say which style caused the difference? | a fair, random test | not supported |
A real run on invented data: 240 learners logged without a fair test. Comparing teaching styles there can show a pattern at most, so the question of cause is marked “not supported”.
How it plugs in.
-
An API for your server
A web API with keys that work for one project only, retries that never count anything twice, and ready-made clients for TypeScript and Python.
-
Notices to your server
A message when a receipt is written or updated, signed so your server can check it really came from OutFigure.
-
Your history, imported
Bring a CSV of past lessons or checks. You map it column by column, and every row is checked before it lands in a sandbox project.
-
A console
See how much follow-up came back, open any receipt down to its evidence, and run your fair tests.
What it leaves alone.
It measures what happened next. Learners see nothing different.
-
Your tutor
OutFigure doesn’t change what your tutor does. Release advice and next-step suggestions go to your team and your system, never to a learner, and suggestions stay off until you turn them on.
-
Grades and credentials
It doesn’t grade, rank or certify anyone. A receipt is not a credential.
-
How people behave
It records no keystrokes, eye movements or reading speed.
-
Other customers
One customer’s data never trains anything for another.
Start with one kind of lesson.
Tell us what your tutor delivers and which checks already come after it.