What is Post-Edit Rate? The dictation metric that measures send-readiness

You finish dictating a message and the tool reports 98% accuracy. Then you read what it produced, fix a comma, restore a word it swapped, delete a greeting you never asked for, and send. The accuracy number was true. It also told you nothing about the thing you just did.

That gap is the whole problem with how voice dictation gets measured. Word error rate counts words. It was built for transcription, where the job ends when the words are on the page. Dictation into Gmail or Slack is not transcription. The job ends when you press send without having touched anything.

So we measure the thing that matches the job. We call it Post-Edit Rate, we publish it, and this post explains what it is.

The definition

Post-Edit Rate (PER) is the percentage of voice dictations that need at least one edit before they are fit to send. It measures send-readiness rather than transcription accuracy. Lower is better and zero is the goal.

A dictation passes only if a reasonable person could send it without changing a single character. Not "mostly fine." Not "one small fix." Zero characters.

Preference does not count. If you would swap a word because you like a different one better, that is style, and the standard here is send-readiness.

There is no partial credit and no composite score, because partial credit is where honest metrics go to die. The moment a benchmark lets a result be 87% good, every failure gets to hide inside the average. A binary pass forces the number to mean something: either you had to touch it, or you didn't.

The idea is borrowed. Machine translation has measured post-editing effort for decades, on the reasoning that a translation's value depends on how much work a human does after the machine finishes. Translation Edit Rate and its human-targeted variant are standard there. Dictation has the same shape and never adopted the same measure. Post-Edit Rate applies an old idea to a category that kept reporting the wrong number.

Why accuracy is the wrong number to publish

Word error rate is the wrong number for this category, and the category keeps publishing it because it flatters everyone.

Consider a dictation where every word is transcribed correctly and the output still fails. You said "I think we should probably push this back a week." The tool returns "I recommend delaying this by one week." Word error rate has nothing to say about that. Every word it produced is a real word, correctly spelled. But you hedged on purpose, the hedge is gone, and the message you send now carries more certainty than you meant.

The reverse happens too. A tool drops a stray "um," fixes your capitalization, and lands a message you send untouched. By word error rate it made changes. By the only test that matters, it did its job.

Post-Edit Rate collapses that into one question: did you have to fix it?

How the number is produced

A run sends a set of realistic dictation scenarios through the live production pipeline, the same one users hit, not a staging copy. The suite holds 116 scenarios, and most are graded against more than one surface, since the same sentence should come out differently in an email than in a chat message. That gives 173 scenario-surface pairs. Each run makes four passes over all of them, because formatting failures are often intermittent and a single clean pass hides them, which is how the August 15, 2026 run reached 692 evaluations.

Every output is graded by fixed rules on text. No AI judge scores the number, no model votes, no human opinion decides a borderline case. That constraint is deliberate. A benchmark graded by a language model is a benchmark you can move by changing the grader, and a quality number you can move without changing quality is marketing.

Each failure maps to exactly one category, resolved by a fixed precedence so a single mistake never gets counted twice:

Invented content is countable but always treated as critical, reported on its own and routed to a human. A fabricated sentence should never be able to look like a misplaced comma in a summary statistic.

The category that makes this metric different

Look again at the Voice row. Dropping your hedge is a failure. Softening how strongly you put something is a failure. Swapping one of your words for a better one is a failure.

Most tools would score all three as successes, because most tools are trying to improve your writing. Rubil formats your words. It never rewrites or generates them. A benchmark that rewarded a nicer-sounding output would be measuring a product we deliberately did not build, so the counting rules treat your phrasing as the thing being protected rather than the thing being optimized.

That is the part of Post-Edit Rate a competitor could adopt and would not enjoy. It penalizes exactly the behavior that demos well.

Where the number sits today

On the August 15, 2026 run, Rubil's Post-Edit Rate was 0.58%. Four failures across 692 evaluations. Direct messages and AI chat prompts routinely record zero.

The number moves, and the board shows it moving. A formatting model change on August 14 measured 1.88%. A value-preservation guard shipped the same day took it to 0.43%. A suite revision the following day put it at 0.58%. Three runs, three different numbers, all published.

Publishing the bad run is the entire point. A quality number that only appears when it improves is a press release. The live board carries the current figure, the per-surface breakdown, and the run history, and it is the source of truth rather than this post, which will go stale the next time the number moves.

What this number does not tell you

A metric that only tells a flattering story is not worth publishing, so here is where this one is limited.

It is measured on a fixed scenario set, not on your writing. The scenarios are built to be realistic and messy, with filler words and false starts and trailing thoughts, but they are still a set someone chose. A number produced against a fixed suite tells you about the suite.

The mix of scenarios across surfaces is not weighted to match how people use Rubil in practice. Direct messages carry a larger share of the suite than they carry of real usage.

And a suite that stays fixed while the product is tuned against it slowly stops being a test. That risk is real and it grows the more attention this number gets.

None of that makes the number meaningless. It makes it a floor rather than a promise, and a floor you can inspect is worth more than a percentage nobody can check.

No user text is involved

The scenarios are written for the benchmark. They are not harvested from anyone's dictations, because there is nothing to harvest from. Audio is processed transiently and discarded. Transcripts are not stored on Rubil's servers. Your Glossary is encrypted. Rubil detects the app you are writing in by reading the URL in Chrome or the app identifier on Mac, never by looking at the screen. Every data processor is named on our privacy page.

Measuring quality without collecting user text is a constraint we accepted on purpose. It is also why the scenario set has to be built by hand.

FAQ

Why publish it at all

A voice tool asking for a place in your daily writing is asking for a lot of trust. Claims about accuracy are cheap and unfalsifiable. A number that is defined in public, counted by rules anyone can read, and posted on the bad days as well as the good ones is the only version of that claim worth making.

You can see the current figure on the quality board, read the reasoning behind formatting rather than rewriting in the ghostwriter philosophy, or try it in your browser with nothing to install. For how the formatting differs by where you are writing, see the guides to voice dictation for Gmail and voice dictation for Slack.