When the transcript flickers, the resident watches the machine change its mind.
Partial transcripts that keep rewriting themselves make a device feel uncertain and untrustworthy. How we kill the flicker — debouncing, a stability threshold of N unchanged updates, and committing only the prefix that has stopped moving.
Partials make a voice device feel fast. They also, handled naively, make it feel nervous. A resident says I want to call my son, and the raw partial stream renders I want → I want to call → I want to fall → I want to call → I want to call my son — a sentence that visibly twitches and second-guesses itself before settling. Every one of those intermediate strings was the recognizer's honest best guess at the time. Shown or acted on directly, they read as a machine that doesn't know what it heard. This post is about the flicker specifically, and how we stop it without giving up the speed that partials buy us.
Flicker is the tail of the partial revising itself
The instability is almost always at the end of the partial — the most recent word or two, where the recognizer has the least audio context and the most uncertainty. The earlier tokens of an utterance stabilize quickly; the trailing tokens churn until enough following audio arrives to pin them down. In our logs the last token of an in-flight partial gets revised on something like one update in four during active speech, while tokens more than two words back almost never change. The flicker is real, but it is concentrated, and that concentration is what makes it fixable.
Commit the prefix that has stopped moving
The mechanism is a stability threshold applied per token. We track, for each token position, how many consecutive partial updates have left that token unchanged. A token that has survived N updates without being rewritten — we use N = 3 at our update cadence, which lands around a couple hundred milliseconds — is promoted to committed. The committed prefix is frozen: it will never be redrawn or retracted in what the resident sees or what we act on. Only the unstable tail past the committed prefix is allowed to keep changing, and we simply do not surface or act on the tail until it earns its way into the prefix.
- A new partial arrives; diff it against the previous one token by token.
- Increment a stability counter for each leading token that matches; reset the counter for the first token that differs and everything after it.
- Advance the committed prefix to include every token whose counter has reached N.
- Render and reason over the committed prefix only; hold the volatile tail back until it stabilizes or the utterance ends.
Two guards keep this honest. First, a short debounce so a burst of updates within a few tens of milliseconds doesn't get treated as N independent confirmations — stability has to mean stable over time, not stable across three messages that arrived in the same breath. Second, end-of-utterance overrides everything: when the turn closes, whatever tail remains is reconciled against the final transcript in one move, so we never strand a half-committed sentence.
Stability is a tunable, and the right setting depends on stakes
N is the latency-versus-trust dial. A larger N waits for more confirmation and flickers less, at the cost of feeling slower to commit. A smaller N commits sooner and occasionally has to live with a token that wished it had waited. We do not use one value everywhere. For low-stakes conversational back-and-forth we commit aggressively, because a rare imperfect word costs little. For anything that becomes a nurse-reviewed event — a symptom, a name, a request for help — we raise N and lean on the end-of-utterance reconciliation, because a committed clinical event has to be one we will stand behind.
The resident in 214B never sees the recognizer argue with itself. The words she said appear, settle, and stay. Underneath, the tail is still churning the way it always did — we have just stopped showing her the part of the machine that was still thinking, and only ever stand behind the part that has stopped.