Pronunciation scoring API for speech therapy apps
A pronunciation scoring API for a speech therapy app is an HTTP service that takes a recording of a child plus the word they were asked to say, and returns a score for each individual sound in that word along with what was produced instead when a sound was wrong. For a paediatric therapy product that is the difference between telling a child “try again” and telling them the R at the start of rabbit came out as a W — and the difference between a parent reporting that practice happened and a clinician being able to count it.
What changes when feedback is per-phoneme
Speech therapy does not target words. It targets sounds, in specific positions within words, tracked to a percentage across sessions. A word-level score is the wrong shape for that work — it can tell you a production was imperfect but not which part of it was, and it cannot be aggregated into a goal.
- Targets are sounds in positions, not words. A goal is written as “/r/ in initial position, 80% accuracy across three sessions”. A per-word score cannot be aggregated into that. A per-phoneme score can be filtered to initial /r/ and counted directly.
- Feedback becomes specific enough to act on. “Try that word again” teaches nothing. “The R at the start of rabbit came out as a W” names the sound, the position, and the substitution — which is what a cue is built from.
- Progress becomes a curve on one sound. With phone-level rows you can plot a single target sound over weeks, in a specific word position, which is the shape a clinician actually reasons about between sessions.
- Generalisation becomes visible. A child whose /s/ is stable in isolation but collapses in clusters shows up in phone-level data as a positional pattern. A word-level score averages that away.
This is why the unit of the response matters more than the headline accuracy number. An engine that is excellent at scoring whole utterances and silent about individual sounds is solving a different problem — a good one, but not this one.
The practice-volume problem, and why automation helps
The bottleneck in articulation therapy is not clinical skill. It is repetitions. A child needs far more scored attempts at a target sound than any weekly session schedule can supply, and the attempts that happen at home have traditionally been unmeasured — nobody knows how many there were or how many were right.
- The arithmetic of a weekly session is unforgiving. One or two short sessions a week gives a child a limited number of scored repetitions of a target sound. What actually drives change is the practice between sessions — and historically that practice has been invisible, unscored, and unreported.
- Automated feedback makes home practice countable. Every attempt is a row: the target, the phone, the score, the timestamp. A clinician opening a dashboard on Monday can see 140 attempts at initial /r/ with a rising mean, instead of a parent saying “we did some.”
- Latency is the whole design constraint. A child will not wait. Score returns in roughly a second; build your loop so the feedback lands while the child still remembers the attempt, and do the aggregation asynchronously.
- Do not correct on every flag. At real base rates most flags are wrong. A product that interrupts a child two-thirds of the time it should not is worse than one that stays quiet — which is the entire reason the three-tier model exists.
The three-tier output, and the worklist you build from it
Every scored phoneme comes back with a tier as well as a score. The tiers exist because two different consumers need two different thresholds: a child should only be interrupted when the engine is confident, while a clinician wants everything borderline surfaced.
| Tier | What it means | What to do with it |
|---|---|---|
| flag | The engine's score is low enough to be its strongest available signal that something went wrong — which is still wrong more often than not on our evaluation set | Surface to the child as corrective feedback; add to the clinician worklist |
| review | Borderline — the score sits in the band where the engine and a human often disagree | Do not correct the child. Queue it silently for the clinician |
| clean | The engine found nothing wrong with the production | Reinforce the child. Do not treat as cleared — see the limit below |
Turning tiers into a clinician worklist
- Rank, do not filter. Sort every production from the week by engine score ascending. The clinician works down the list until they run out of time; nothing is hidden from them.
- Budget the listening. In our clinical evaluation, reviewing only the worst-ranked productions recovered a disproportionate share of the clinician’s own error list — well above what reviewing the same number at random would have found. A fraction of the listening for a large share of the findings is what a triage layer is for.
- Group by target sound, not by session. A clinician reviewing twelve attempts at initial /r/ back to back forms a judgement far faster than one hopping between sounds.
- Show the engine’s reason. Put the candidate substitute and error type next to each item. It is what turns a listening queue into a shortlist the clinician can skim.
- Never label a bucket “cleared”. The clean tier is not a clearance and the UI must not imply it is. See the limit below.
What the engine does on clinical audio
The benchmark we publish measures phoneme scoring on child voices, and its speakers are English learners rather than children in therapy. So the engine is also evaluated against a speech and language therapist's judgements on recordings of children with diagnosed speech sound disorders. That work is ongoing research on a corpus licensed for non-commercial use, so we do not publish its figures here. Two of its findings decide how a therapy product should be built, and both are stated in full below.
The second finding is the limit below, and it is the one that decides your architecture.
The limit that decides your product architecture
The shape that works
Put together, the measurements point at one product architecture and away from several others. Automated feedback in the child's practice loop, tuned to interrupt rarely and gently. A complete, ranked record of every attempt for the clinician, with the engine's reasoning attached. A clinician who reviews the top of that list and whose judgement is the only thing that ever marks a sound as achieved. No screening, no clearing, no diagnosis.
That product is useful today and can be described accurately to a clinician. The one that assesses a child unsupervised cannot, and our own measurements are the reason we say so.
What the response looks like in a review queue
One scoring response, rendered the way a clinician would want to read it. Every field shown below is taken from the sample response published on the ArticScore overview — the API returns the data, and the review interface around it is yours to build.
In a clinician’s review
rabbit
| Sound | Score | Sounded like | Error type | Tier |
|---|---|---|---|---|
| R /ɹ/ | 41.2 | W /w/ | substitution | flag |
| AE /æ/ | 88.1 | — | — | clean |
| B /b/ | 94.0 | — | — | clean |
| IH /ɪ/ | 79.6 | — | — | clean |
| T /t/ | 90.3 | — | — | clean |
Every column is a field the API returned: phone, phone_ipa, score, sound_most_like, error_type and tier. An em dash means the response carried no value for that field on that phoneme — those keys are only present on a flagged sound.
One way this response could look in your product— the API returns the data, you own the experience. Every phone, score, substitute and tier above is read straight from the sample response for rabbit; the layouts, the star rule, the colour bands and the coaching sentence are things a product decides, not fields the API sends back.
Building a paediatric speech therapy product?
ArticScore is in limited early access, rolled out case by case. Tell us your use case and expected volume and we will come back to you.
Request access