Pronunciation scoring API for reading and literacy apps
A pronunciation scoring API for a reading product is an HTTP service that takes a recording of a child reading aloud plus the word or passage they were given, and returns a score for each individual sound in that text rather than a verdict on the word as a whole. For a decoding or phonics product that is the difference between knowing a child got ship wrong and knowing that the /ʃ/ came out as an /s/ — which is the level at which phonics objectives are written and the next lesson is chosen.
Why phoneme-level scoring maps onto phonics
Reading instruction is built on grapheme–phoneme correspondences, and it is assessed one correspondence at a time. A scoring layer that reports whole words is reporting at a coarser resolution than the curriculum it is supposed to serve.
- Instruction is already phoneme-shaped. A phonics scope and sequence is a list of grapheme–phoneme correspondences. If your scoring layer only reports whole words, every one of those objectives has to be inferred from a signal that cannot carry it.
- The diagnostic value is in which sound failed. A child decoding ship who produces /s/ + /ɪ/ + /p/ has not learned the digraph. A child who produces /ʃ/ + /e/ + /p/ has a vowel problem. Both are “wrong word” at word level and they call for completely different next lessons.
- Positions and blends fall out of the same data. A learner who is solid on /s/ in isolation and loses it in str- clusters is visible in phone-level rows and invisible in word-level ones.
- Timings let you build the reading metrics. Each phoneme comes back with its start and end in the audio, which is the raw material for pacing, hesitation and words-correct-per-minute style measures against a known passage.
- Tiering keeps the loop kind. The
flag/review/cleantiers let you correct only when the engine is confident and route the borderline cases to a teacher queue instead of the child.
The same word, three different lessons
A child reads ship. At word level there is one outcome: incorrect. At phoneme level there are three completely different diagnoses — the digraph was not learned, the short vowel was not learned, or the final stop was dropped. Only the second representation tells a teacher, or an adaptive engine, what to do next.
Where it fits, and where it does not
ArticScore scores against a target you supply. That constraint is what makes reliable per-sound scoring possible, and it also draws a clean line around the use cases it can serve.
| Activity | Fit | Why |
|---|---|---|
| Word-list decoding practice | Strong fit | Target word is known; every phoneme is scored against it |
| Passage reading against a known text | Strong fit | Score word by word through the passage with per-sound detail |
| Phonics drills on a target grapheme | Strong fit | Filter the phone rows to the target sound and aggregate across items |
| Nonword / pseudoword decoding | Depends on your lexicon | Requires a pronunciation for the item; talk to us about how yours is generated |
| Free retell, open discussion, unscripted talk | Not a fit | There is no target text to score against |
| Open-ended transcription of what a child said | Not a fit | ArticScore does not transcribe — it scores a known target |
If your roadmap depends on open-ended transcription — knowing what a child said when you did not know what they were going to say — that is a different class of system and ArticScore is not it. We would rather say that here than in a pilot.
In a reading loop, the false-flag rate matters more than recall
In a clinical triage workflow, recall is what you optimise: a missed error is a missed finding. A motivational reading loop inverts that. The child is the consumer of the feedback, and the cost of being wrong lands on them directly.
6.5%
false-flag rate at the shipped operating point
Sounds the human judges scored correct that the engine flagged anyway, at score < 50, measured on 4,855 correct phones (317 false flags) from children aged 6–15.
8.0% → 6.5%
what child-speech fine-tuning bought
At the same fixed operating point, recall on real errors stayed identical at 0.730 while the false-flag rate fell. The gain came from 12.5 hours of audio from 531 child speakers.
- A false flag costs more than a miss in a motivational loop. A missed error means one repetition of practice did not land. A false flag means a child who read the word correctly was told they were wrong — which damages the thing a reading product depends on most, the child’s willingness to keep reading aloud.
- The number to negotiate on is the false-flag rate, not recall. At the shipped operating point our engine flags 6.5% of sounds that human judges scored correct. Ask any vendor you evaluate for this figure specifically, ours included — it is the number your users will feel, and it is easy to overlook when recall is the headline.
- Fine-tuning on child speech is what moved it. Held at the same fixed operating point, recall on real errors stayed identical at 0.730 while the false-flag rate fell from 8.0% to 6.5%. That gain came from 12.5 hours of child audio from 531 child speakers, not from adjusting the scoring maths.
- Design so that being wrong is survivable. Never break a streak, deduct a point, or block progression on a single flag. Re-prompting gently, or simply logging it for a teacher, costs nothing when the engine is wrong.
Dialect sensitivity — validate on your own users
The engine is evaluated and supported on American English, and it is scored against an American English lexicon. That is a real constraint for a literacy product, because several patterns that an American target treats as a mismatch are standard features of other English varieties.
The shape that works in a reading product
- Correct on
flagonly. Routereviewto a teacher queue silently, and never surface it to the child. - Suppress on known differences. Maintain a per-child list of sounds the child is known to produce differently and mute flags on those sounds in the reading loop.
- Separate the two ledgers. Keep “decoding evidence” and “pronunciation observation” as different fields in your data model from day one. Merging them is easy later; unmerging them is not.
- Aggregate to the correspondence, not the word. Report progress against grapheme–phoneme objectives, which is what per-phoneme rows are able to support and word-level scores are not.
- Do not gate progression on a score. Use it to choose the next practice item and to inform a teacher, and let a human decide when something is mastered.
Every number on this page comes from our own evaluation runs and is published with its sample size and its caveats on the benchmark page. None of it is third-party certified, and none of it is a standardized assessment of reading or of speech.
What the response looks like in a reading loop
The same scoring response drives a child-facing practice screen and a teacher's review queue. Below is one rendering of the sample response published on the ArticScore overview — the API supplies the per-sound data, and the experience around it is yours to design.
In a practice set
rabbit
61.4
1 of 1 word scored
61.4 / 100
One dot per phoneme, in the order the API returns them, showing that phoneme’s own score. Colour bands: 80 and above uses the brand teal, 50–79 amber, below 50 red. The bar is overall_score (61.4) out of 100, and this response covers a single word — no other words are implied.
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 reading, decoding or phonics 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