标签：#amivoice

📝 Originally published in Japanese on Zenn. This is the English version. Canonical: https://zenn.dev/uya0526_design/articles/satellite3_metrics-rationale 📚 This is satellite article #3 in my "Read-Aloud Speed Meter dev log" series. For the whole picture, see the main article . Where This Sits The read-aloud speed meter converts speaking speed into an evaluation label like "slightly fast," and stagnation rate into one like "few." Those labels ultimately become the foundation for Claude Haiku's feedback. So — on what basis did I draw the thresholds (the dividing lines)? This article digs into that "basis." The short answer from my research: I couldn't find a paper that defines an academic threshold for "N characters/min = fast/slow." This is a record of how I drew the lines honestly once I'd learned there was no firm basis. More than the metric numbers themselves, I believe being transparent about why I chose those numbers is what makes an evaluation app trustworthy. 💡 I'm an ex-Java engineer learning TypeScript in public. This one is mostly about design decisions. Why Obsess Over the "Basis"? An evaluation app passes judgment on the user: "your reading is slightly fast." Once you're passing judgment, if you can't explain "why we can say that," it's just guesswork. This app in particular passes the labels straight to Claude Haiku to generate coaching. If the foundational label has an unclear basis, the feedback built on top of it is a castle on sand. So I decided to nail down the basis for the thresholds first. Two things to research: The judgment basis for speaking speed (characters/min) The judgment basis for stagnation rate (the proportion of silence) As it turned out, these two had completely different kinds of basis. Speed Thresholds: No Academic Threshold → Draw From General Rules of Thumb What I found For speaking speed, I first looked for academic backing. Here's what I found: Speaking speed has traditionally been measured against mora count, but prior researc