Streaming speech recognition emits partial hypotheses that get revised. Vendors publish word error rate and latency — both describe endpoints. Neither describes the interval in between, where text is visible, plausible, and still changing. That interval has no published number. We call it settling time. SETTLE ships two things together: 1. The instrument — streams audio at real-time pace, records every Speechmatics message with arrival timestamps, and computes per-word settling time across a 10-clip corpus swept at max_delay ∈ {0.7, 1.0, 2.0, 4.0}. Every number traces to committed run files in the repo (make results). 2. The sidecar — a WebSocket proxy that holds a token until its text has been stable for τ seconds, then releases it. One upstream feed, two downstream streams (naive and settled) on byte-identical input. Demo: emergency dispatch. On our locked clip (runs/09_md1.0.jsonl), a partial misheard as "working fire me" makes the naive consumer fire ELEVATED - FIRE — a false alarm — before the engine corrects to CRITICAL - RESCUE. The settled stream (τ = 0.774s, settling p95 at max_delay = 1.0) never sees the false alarm. Headline finding across 1,227 observed words: 0.0% changed after their AddTranscript — but settling p99 scales 3.5× from max_delay 0.7 to 4.0. Finals don't retract; they just take longer to arrive than they look like they will. Built on Speechmatics Realtime API. Measures settling time on streaming partial transcripts and ships a hold-until-stable sidecar. Live prototype: https://adindamochamad.github.io/settle/ Repository: https://github.com/adindamochamad/settle
Category tags: