What eleven checks on a subtitle cue actually catch

Every cue is validated before it reaches you, and anything that fails goes back to the model with the complaint attached. Here is what the checks look for and why each one exists.

Most subtitle tools translate and hand you the result. This one validates every cue first, sends the failures back to be fixed, and then sweeps the whole file again. The checks are cheap and local; none of them cost an API call.

Structure

Every input cue id appears in the output — catches dropped cues outright.
Formatting tags are balanced, and protected spans survive intact.
Line count and characters per line stay inside subtitle limits.
Reading speed stays under the threshold for the cue's duration.

Language

A character-set check catches output left in the source language. It does not catch a near-miss language, which is the more interesting failure: several Russian words use only letters that also exist in Bulgarian, so they pass any script test cleanly. That needs a wordlist, and the wordlist only grows from real files.

Meaning-adjacent

Length ratio against the source, which catches both dropped and hallucinated content.
Dangling fragments — a cue that ends mid-clause with no terminal punctuation.
Terminology consistency, so a name is not spelled three ways across an episode.

What happens to a failure

It is re-asked, with the specific complaint attached rather than a generic retry. And a repair is only accepted if the cue validates no worse than before — without that rule, a confident bad suggestion can quietly degrade a cue that was already correct.

What this does not promise

None of these checks read for style. They catch structural failure, which is most of what goes wrong, and they catch it on every cue rather than on the ones someone happened to look at. A line can pass all eleven and still be a flat translation. We would rather say that than imply otherwise.