TurtleDock
Writing

AI in education management: what it is good for, and what it is not

AI is genuinely useful in school administration for pattern-finding across data a person cannot read in full — spotting a fee ledger that has drifted, drafting text a human then edits, and turning a question into a query. It is not suitable for judgements about individual children, because those get treated as facts by whoever reads them.

We build school software and have declined to ship several AI features other vendors offer. That is a position, and the reasoning is below so you can disagree with it.

Written by Checked by MuthuLast reviewed

Every education software vendor now has an AI page, and most of them describe the same three things: predicting which students will fail, predicting which families will not pay, and writing report card remarks. We have built none of them, and it is worth explaining why rather than quietly not mentioning it.

This is not scepticism about the technology. There is real, unglamorous value in applying it to school administration. It is a distinction about what kind of question is being asked, and about who reads the answer.

Good at
Finding patterns in data too large to read
Good at
Drafting text a person then edits and owns
Bad at
Judgements about individual children
The test
Who reads the output, and what do they do with it
01

The distinction that decides it

The useful line is not between prediction and description, or between statistics and machine learning. It is between an output a person will check and an output a person will act on directly.

A model that flags forty fee accounts as anomalous produces work: someone opens them and finds three genuine errors. Being wrong thirty-seven times costs nothing but time. The output is a queue.

A model that says a child is likely to fail produces a belief. It is read by a class teacher, mentioned to a parent, and remembered. Nobody checks it, because there is nothing to check against until the result exists — by which point the belief has already influenced how the child was taught.

02

Where it earns its place

All three of these are in production somewhere, and none is controversial.

  • Reconciliation anomalies. A fee ledger with eleven thousand transactions a year cannot be read by a person. Surfacing the two hundred that do not look like the others is exactly the job, and every one is verified by a human before anything happens.
  • Drafting that a person owns. A first draft of a circular, a summary of a long thread, a translation into a parent’s language. The person sending it reads it, changes it and puts their name to it — which is what makes it theirs.
  • Turning a question into a query. "Which sections are behind on marks entry" is a question a principal should be able to ask in words rather than by learning a reporting tool. The answer is rows, which are checkable.

The pattern is consistent: the output is either verified before it acts, or it is a starting point that a person completes.

03

The three we declined, and why

Each is technically straightforward. That is rather the problem.

  1. Predicted board grades. A number generated from historical patterns is read by a parent as a forecast about their child. It is not; it is a statement about students who resembled this one on the recorded variables. Publishing it changes behaviour in ways nobody measures.
  2. Per-family fee default risk. Sort families by likelihood of not paying and you have built a tool for treating some families differently, on the basis of a score they cannot see and did not consent to. What the school actually needs is who has not paid, which is a fact, and it already has that.
  3. Auto-published report card remarks. A remark is a statement by a named teacher about a named child. Generating the sentence and printing it under a teacher’s signature misleads a parent about who formed the judgement. A comment bank a teacher chooses and edits from is a different thing and we do build that.
04

Questions to ask a vendor

These get past the demonstration quickly.

  • Who reads this output, and what do they do with it? If the answer is a parent or a class teacher, and the output is about a child, be careful.
  • What happens when it is wrong? Every model is wrong sometimes. A vendor who has not thought about the wrong case has not thought about the feature.
  • Can a person see why? Not full interpretability — just enough for the person acting on it to sanity-check it.
  • Is our data training a model used for other schools? Ask directly, and get the answer in the contract rather than in an email.
  • Can we switch it off? If a feature cannot be disabled, it is not a feature, it is a condition.
FAQ

Questions people ask

Phrased the way they arrive, answered so each one stands on its own.

Is TurtleDock against AI in schools?

No. We use it where the output is verified before it acts or is a draft a person completes. We decline it where the output is a judgement about an individual child that will be read as a fact, which is a narrower objection than being against the technology.

Do you train models on customer data?

No. School data is used to run that school’s instance and nothing else. It is not pooled, not used to train anything, and not shared.

Will you build these features if customers ask?

Customers have asked. We have said no and explained why, which is a better use of the conversation than shipping something we would not want used on our own children.

Related

Read next

Provenance

Who checked this, and against what

Accountability

Checked by the Product desk on 7 September 2026. Corrections go in the page, dated, rather than quietly.

No call required

Tell us your enrolment, we will tell you the number.

Pricing is on the page, in the open, with the counting rule written next to it. Nobody has to book a call to find out what it costs.

See pricing

Bring your own structure. We configure it live on the call.

Forty minutes with an implementation engineer — your classes, your fee heads, your grading scheme, entered as we go. No slides, no sample school.