Student data
What LOOP holds about your students.
Written to be read in one sitting by the person who has to approve it — and to be forwarded. The binding version is Exhibit B of the data privacy agreement, generated from our own source code; this is the readable version of the same facts.
What we collect
One first name and one class code per child, the worksheets they filled in, and what those worksheets say about which skills they have. Nothing else.
The binding inventory is long because it names every field our pipeline writes, down to a single box's confidence score. It falls into six categories, and the full element-by-element list is attached to the agreement — we'll send it before you ask.
"Student identifier" means a class code, not a school ID. A child is C1-003 in our system. That code is ours, it's meaningless outside the class, and it never travels with a name.
We never collect, and our database has no column that could hold: last names, birthdays, photographs of faces, or student logins. Children do not have accounts and never sign in. There is no parent-facing page, no advertising, and no third-party analytics on any page that touches student work — including this website.
We do not call any of this de-identified. A first name plus a class code is re-identifiable by anyone holding your roster, which is every adult in the building. We treat all of it as student data and we ask you to as well.
Where it's stored, and for how long
Two places, both in the United States, both encrypted at rest. Records live in a database; images live in file storage, filed one folder per class-day so a whole day is one delete.
| Thing | Kept for |
|---|---|
| Scanned page images, and the small crops cut from them | 24 hours — until the teacher's review window closes |
| The class roster, scores, skill history, and plans | One school year |
Both windows are provisional in our own specification. We'd rather you agree to final durations than to our drafts, so they get confirmed with you before anything is signed.
Who sees it
The classroom teacher, through a link sent to their school email — no password, no account to create. Our own operator has access for support and repair. That's the list.
What leaves the school
One crop at a time, to be read. A crop is a photograph of a single printed box with one handwritten number in it. It goes to a commercial AI API that does not train on customer inputs, and it comes back as digits.
Nothing goes with it. We checked the code that builds that request rather than asserting it: it carries the model name, a fixed instruction, and the image. No first name, no class code, no sheet identifier and no date accompanies any image we send.
No child's name is ever sent to any model. First names sit in one column of one table and are used only to print a name on a worksheet and to show the teacher who is who. They are not part of any file the reading stage can open.
How it's deleted
Two commands, and the proof is a count. One removes a whole class; one removes a single child. Each run records how many rows and files existed before and after, then re-counts and fails if anything is left. Running the same delete twice must report zero.
This exists because Utah Code 53E-9-309 requires your contract with us to give you a deletion right. The command is that right, rather than a promise about one.
The one thing we ask for
We'd like permission to keep the crops — the small pictures of handwritten digits — with the child stripped out, so our handwriting reader gets better. It's the only use of your students' work that goes beyond running the service for you, and we'd rather raise it than bury it.
The mechanism is built and it is one-way. A kept crop lands in a separate store, named only by a hash of the image itself: no class code, no child code, no sheet number, no date, no original filename. The finest time we record is the school year. Nothing can join that store back to a child — which is the point of it, and also the cost, because once a crop is there your deletion request cannot reach it.
It is off unless you turn it on. The consent flag defaults to off, per class. Without your written agreement, none of your students' work enters it.
What we still owe you
A few things are genuinely unsettled, and we'd rather list them than let you find them: confirmation of both retention windows as final; whether we request zero-day or accept 30-day retention at our reading provider; and your own Data Manager's name on the agreement, since school governance plans name the role rather than the person.