Why dictation software rewrites what you said
Most AI dictation tools do not transcribe you — they paraphrase you. Here is the technical reason why, and what a tool has to give up to stop doing it.
You said "I’ll get the numbers over to you Thursday." The box says "I will send you the figures on Thursday." Nothing is wrong with it. It is arguably better written than what came out of your mouth. It is also not what you said, and once you notice the substitution you start seeing it everywhere: a hedge tidied away, a blunt sentence made diplomatic, a name swapped for a more common name that sounds a bit like it.
The natural reading is that the software made a mistake. It didn’t. In most tools that advertise AI dictation, the rewriting is the feature working as designed, and it follows from a decision made well before the part you can see.
There are two models in the chain, not one, and the second is not editing your words. It is writing new ones that resemble them.
Two models in a row
The first model is acoustic. It turns a waveform into text, and it is faithful by construction — it has nothing to say about style, and when it is wrong it is wrong the way a mishearing is wrong, producing something that sounds like what you said.
Its output is honest and ugly. Real speech is full of interjections, false starts, repeated function words and clauses abandoned halfway, and nobody sends that. So everyone adds a second stage. For years that stage was a set of narrow models — one for punctuation, one for capitalisation — which are classification problems with fixed label sets and physically cannot emit a word you did not say. Then general language models became cheap enough to put in the loop, and the second stage became a prompt: here is a raw transcript, clean it up, remove the filler, fix the grammar, keep the meaning. That prompt is where fidelity goes.
What "clean this up" actually asks for
A language model predicts likely continuations. Given your transcript in its context window it produces a fresh sequence of tokens, each chosen because it is probable given what came before. There is no cursor in this process, no delete key, no edit operation. The model is not modifying your string; it is generating a new one conditioned on yours.
Probable according to what? According to a training corpus that is overwhelmingly written, edited prose. Speech is not edited prose, so wherever your sentence is shaped like speech, the most probable continuation is the one shaped like writing. "Get the numbers over to you" is a spoken construction and "send you the figures" is the written neighbour sitting next to it in the distribution. The model did not decide to improve you; it sampled from a distribution whose centre of mass is somewhere other than where you were standing.
This is also why the rewriting concentrates on exactly the content you least want touched. Fluency objectives smooth low-probability text, and low-probability text is where your meaning lives: proper nouns, product names, unusual numbers, technical identifiers, the hedge you chose on purpose. Common phrasing survives because it was already the likely option. It is the same mechanism behind names coming out wrong so consistently — a rare name has a common neighbour, and a system optimising for likelihood will find it.
Why an instruction does not bound it
The obvious objection is that you can just tell the model to stop. Write "preserve the user’s exact wording, only remove disfluencies" into the prompt and the problem is solved. In practice this moves the distribution without bounding it. Instruction-following is one prior among several and it competes with the fluency prior baked into every parameter; when the two conflict — a deliberately awkward clause, an unfamiliar term with a smoother neighbour — fluency wins often enough to matter.
What makes that dangerous rather than merely annoying is that the failure carries no signal. The output arrives as ordinary fluent text with no diff, no marked spans, no flag saying "this clause was regenerated." There is no such channel, because from inside the model nothing was altered; a sequence was produced. Detecting a substitution means comparing the result against your memory of what you said, at speaking speed, which nobody does.
There is a real engineering answer, and it is the honest version of using a language model safely: constrain the decoder so the only tokens it may emit are ones that keep the output a subsequence of the input. Then it can physically only delete. This works, and it is also a strange thing to have built — you are paying a large model’s memory and latency to make deletion decisions, and you have given up the reason you wanted the model, since it can no longer join clauses, punctuate or rephrase. Fidelity and fluency are one capability seen from two sides. The constraint is not even sufficient on its own: deleting the word "not" produces a perfectly valid subsequence, and negation reversal is the ugliest failure mode in this area. You still need explicit rules about what may be dropped, and once you have those, the model above them is earning very little.
What a deletion-only pass can honestly do
The alternative is unglamorous: a cleanup stage that can only remove, working from an enumerated list under stated conditions. Its entire behaviour can be read in an afternoon, and it admits a test that no generative stage can pass — assert that the output is a subsequence of the input, on every utterance. If a word appears that you did not say, the test fails.
The categories that survive that constraint are narrower than people expect:
- Unambiguous interjections. "Um" and "uh" are never anything else. "Like", "so" and "right" are filler about half the time and load-bearing the rest, so a precision-biased rule leaves them alone rather than gambling.
- Adjacent repeats of function words — "the the", "I I" — which are stutters. Repeated content words are not safe: "four four" may be a number you said twice on purpose.
- Two repeats but never three, because three is a person meaning it. Emphasis has to be protected rather than cleaned.
- Trailing filler phrases, but only where punctuation shows they are parenthetical. "It’s fine, you know." is filler; "That’s all you know." is the entire sentence.
- Commas left orphaned when the phrase after them was removed, which is punctuation repair rather than rewriting.
The feature that gets deliberately left out
The clearest illustration of the trade is self-correction. Everyone wants "send it Friday — no, Thursday" to arrive as "send it Thursday." It is the most requested cleanup behaviour there is, and it is genuinely useful.
In text alone it is also unsafe. Collapsing that utterance means locating the boundary of the retracted span, and the word marking it is indistinguishable in text from an answer: "Can you make Friday? No, I’m out." is not a correction, and deleting the wrong span there inverts the sentence and ships it under your name. What separates the two cases is prosody — pause length, pitch reset, the way a retraction is spoken differently from a reply — and by the time a text-tier cleanup runs, the audio is gone.
So a tool with a fidelity guarantee ships without it and says so. Voicecape leaves self-correction unimplemented for exactly this reason, which means some transcripts arrive with the correction still in them and you fix it by hand. That is the whole bargain: lower recall, in exchange for a system that never invents.
The asymmetry that settles the argument
There are two ways this stage can be wrong and they do not cost the same. A missed cleanup leaves an "um" in your text. You can see it, removing it takes a second, and it never escapes your control, because the failure is sitting in plain view before you press send.
An unauthorised change puts a word in your mouth. You cannot see it, because it reads correctly — better than correctly, since fluency was the objective. It leaves your control immediately, attributed to you, in a message you believe you wrote.
Given a cost function that lopsided, the only defensible bias is to preserve when uncertain — and it is worth checking which bias you have: dictate a sentence with an unusual word choice and an unusual construction, and see whether both survive verbatim. For where the line falls in practice, the full list of what a deletion-only pass removes is a short read, and the case for a verbatim mode covers wanting no cleanup at all.
A useful vendor signal: read what a tool says it deliberately does not do. A product that names a missing capability and gives a technical reason for its absence is telling you where its bias sits.