Before you sign anything, bring these ten questions to the meeting. If a vendor cannot answer any one of them in writing, that is your answer.
Most classroom tools that carry an AI label arrive with a demo, a case study, and a smile. They rarely arrive with a data map, an audit clause, or a way out. This checklist is a working document, not a legal opinion. Use it, edit it, keep it in your procurement folder.
The ten questions
1. Where does student data live, and who can read it? Ask for a written data flow: the fields collected, the servers they hit, the sub-processors that see them, the retention window, and the deletion path (Class C, configuration and integration). "In the cloud" is not an answer.
2. What is the opt-out? If a family says no, what happens to the student in the classroom that day, and to the record already collected? A vendor that cannot describe opt-out at the level of a single student is not ready for a school.
3. Who is the author of what the tool produces? If the tool writes, grades, or summarizes, whose name goes on the output? The AI-authorship fence we use in EducateWright says every artifact carries a visible note of how it was made. Ask if the vendor supports that fence, or fights it.
4. What claims does the vendor make, and what class of evidence backs each one? Bring the evidence-classes vocabulary into the room: A empirical-in-session, B code or inspection, C configuration or integration, E expert citation, F falsifier present, U unverified. A "raises test scores by twenty percent" claim without a study attached is Class U. Mark it that way in your notes.
5. What are the audit rights? Can your team, or an independent reviewer, inspect the model behavior on your own data, on a schedule you set? Read access to logs, prompts, and outputs, without write permissions, is a reasonable ask. "Trust us" is not.
6. What is the exit clause? If you cancel, when is student data deleted, in what format is it returned to you, and what does the vendor keep? Get the timeline in days, in writing.
7. Is student work used to train the vendor's models? This is a separate question from data storage. Get a written no, or a written yes with a clear opt-out, and get it before pilot, not after.
8. What happens when the tool is wrong? Every generative tool produces confident errors. Ask the vendor to show you their error surface: how a teacher sees that the tool is uncertain, how a student can push back, how a mistake gets corrected in the record.
9. Who is accountable in the room when a student is harmed? Not a support ticket, a person. Ask for the escalation path, the response time, and what the vendor has done the last three times it was used.
10. What is the tool NOT for? A vendor who can name the limits of their own product is a vendor worth talking to. If everything is a use case, nothing is.
How to use the list
Print it. Bring it to the meeting. Write the vendor's answer next to each question in your own words, and tag each answer with an evidence class. A folder of these sheets, one per vendor, is worth more than any brochure.
We teach this posture across our partnership work with schools, and we hold ourselves to it too. Our own claims about UNI, the active-inference build we teach here, are framed as a working hypothesis with growing, evidence-classed evidence, science in the open. We ask you to test our build the same way you test theirs.
Active inference as a framework is drawn from the open scientific literature, including Parr, Pezzulo, and Friston (2022) (Class E). We teach the framework, we do not teach a proprietary black box.
Where to go next
- Read what SolutionWright does and does not do for schools before you invite anyone in.
- Walk through how to audit a classroom tool with your team once a vendor is in the pilot phase.
- See our public commitments on the transparency page.
- If you want to work through this list with us in a room, the workshop is where we do that live.