Reading machines in the classroom

A school that buys reading software is doing something different from a person who downloads a reading app. The person risks their own time. The school spends public money, children’s attention and a teacher’s authority, usually on the strength of a demonstration and a brochure. That asymmetry deserves a harder set of questions than the market usually gets asked — and the vendors who deserve the business are the ones who can survive them.

We should declare our interest at once. We make reading software, we offer it to institutions, and this article is therefore partly a description of the standard we are trying to hold ourselves to. Where we fall short of it we say so below. The standard itself, though, does not depend on us, and a school could use it against our product as readily as against anyone else’s.

Classroom reading technology tends to arrive with a claim about learning outcomes attached, and this is the first place to slow down. The evidence standard in education software is, as a rule, far below the standard the language implies. “Research-based” commonly means the product cites research, not that the product has been tested. A school does not need a research office to cope with this; it needs one reflex. When a vendor says “proven”, ask: where, by whom, against what control?

Teacher control is architecture

The first demand: the teacher decides. Which text, which pace, which features are on, whether the class sees a leaderboard, whether a session is timed. In too much classroom software these are platform decisions — made at head office, adjusted by remote update, wrapped in gamification the teacher never asked for. Control that can be revoked from elsewhere is not control. A classroom tool should be inert until a teacher configures it, and it should hold that configuration until a teacher changes it.

This is not a small preference. A reading exercise is embedded in instruction — in what came before it and what the teacher intends after it. Software that reorders its own behaviour mid-term, ships a new reward scheme, or runs engagement experiments on pupils has made itself a co-author of the lesson without being asked. Schools have learned this the hard way with engagement-optimised platforms of every kind, and are entitled to a flat rule: no behavioural experiments on children, ever, and no silent changes.

There is also a quieter reason to insist on teacher control: the software cannot see the classroom. It does not know that this group read the passage aloud yesterday, that this child reads fluently but will not attempt anything long, that today is the wrong day for a timed exercise. The person who knows those things must be able to override the tool instantly and completely, or the tool is in charge.

No data leaves the building

The second demand is stricter than most procurement checklists make it. Not “data is encrypted in transit”, not “we comply with the relevant framework”, but: what does the software transmit at all, and to whom? A child’s reading record — speed, errors, recall scores, what they read and where they struggled — is close to a cognitive medical record. The default posture should be that it does not leave the building, and any departure from that default should be a decision the school takes knowingly, not a clause it failed to notice.

This is where architecture shows. Our consumer app runs entirely in the browser and uploads nothing — zero bytes, verifiable by watching the network tab — because it was designed that way from the start rather than patched towards privacy afterwards. For institutions we build the same principle at building scale: a deployment a school hosts itself, on its own hardware, air-gapped if it wishes, so that the question “where does the data go” has a one-word answer. We regard self-hosting as a design requirement for school software, not an enterprise upsell, and we think schools should treat vendors who price privacy as a premium feature with the suspicion that pricing invites.

A child’s reading record is close to a medical record. Treat the vendor accordingly.

The custody question

The evidence bar

Now the demand that we ourselves cannot fully meet. If a product claims to improve reading outcomes, the claim requires a controlled study in a comparable population — not a testimonial, not a pilot without a control group, not engagement metrics standing in for learning. Very little classroom reading technology clears this bar. Ours does not clear it either: our comprehension-first design rests on well-replicated general findings — dual coding, the testing effect, the speed–comprehension trade-off — but no classroom trial of this app exists, and we will not imply otherwise.

The general literature, used carefully, is still worth having. That adults read prose at roughly 200–300 words per minute, that comprehension falls away beyond roughly 400–500 on unfamiliar material, that testing beats re-reading for retention — these are stable, replicated findings a school can lean on when a vendor’s promises exceed them. A product promising to triple every child’s reading speed is contradicted by a century of measurement, and no procurement process should need a laboratory to notice.

What a school can do meanwhile is prefer products that measure honestly. A tool that shows a recall score next to a speed score at least keeps the right variable in view; a tool that celebrates words per minute alone has already told you what it thinks reading is. And any vendor unwilling to say “this has not been trialled” about an untrialled product has answered a different important question.

• What, exactly, is transmitted off-site, and can we watch the network traffic ourselves rather than take the policy’s word for it?
• Can the school run it without your company existing — self-hosted, offline if needed, with pupil data exportable in an open format?
• Which claims are supported by controlled studies of this product, and which are extrapolations from the general literature? Both are legitimate; conflating them is not.
• Can a teacher disable every game-like element — points, streaks, leaderboards — in a single action, for one child or a whole class?
• What can change without our consent? For school software the honest answer should be: nothing.

The line software must not cross

The last demand is a boundary, and it matters more than the others. Learning to read — decoding print, in the technical sense — is taught, and the evidence on how favours structured literacy: systematic, explicit instruction in the mapping between sounds and letters, delivered by a teacher, adjusted child by child. That work belongs to trained people. Software can supply practice, pacing, text at a suitable level, a comfortable display, a patient voice that never tires of repeating a sentence. It cannot supply instruction, and a product that blurs that line is mis-sold, whatever its other virtues. The distinction runs through everything we publish — decoding is not comprehension — and it is nowhere more consequential than in a classroom.

The boundary cuts both ways, which is why we keep insisting on it. Teachers should not be asked to defer to software about how reading works, and software should not be asked to do teaching it cannot do. The recurring failure of edtech is a category error — a tool promoted into a curriculum, a dashboard promoted into a diagnosis. The corrective is not hostility to technology; it is precision about roles, of the kind good schools already exercise everywhere else.

None of the questions above is exotic. They are the questions any school already asks about a science lab or a minibus: who controls it, what does it record, what is it actually for, and what happens when it fails. Reading software has escaped them mainly by being new. It is not new any more, and the schools that ask hardest will get the tools they deserve — which is, on the whole, how markets learn to read as well.