Degradation marks

The problem

A transcript with a two-minute hole in it reads exactly like a transcript of a meeting where nobody spoke for two minutes. A page of paragraphs with no speaker names reads like one person talking. A transcript that stops eleven seconds before the recording does reads like the meeting ended there.

In each case the document looks complete, and the reader's next move is the opposite of the right one: carry on reading instead of going to find the missing audio; label the speakers by hand instead of learning there was nothing to label; take a blank for a pause instead of a loss.

The tool knew. The microphone stopped feeding it; the recogniser gave up separating voices; the file ended early. That knowledge went into a log, or into an error the user dismissed, and the document went out without it.

The rule

When a tool delivers a transcript it knows to be worse than it should be, it writes a mark into the transcript, and the mark goes wherever the transcript goes: into every export, onto every shared copy, in front of every stranger who opens it.

A mark is not an error. The work was delivered. A mark says where the delivered work is short, so that the reader does not take the shortfall for a fact about the meeting.

A mark

{
  "code": "recording_interrupted",
  "at": "2026-11-07T09:14:03Z",
  "spans": [{ "startSec": 872, "seconds": 118 }]
}

• code — one of the codes below, or the tool's own (see Adopting it).
• at — when the mark was written, ISO 8601.
• spans — optional: where in the recording the mark applies, for the codes that know. startSec is seconds from the start of the stored audio. seconds is how much was lost there, present only when it was measured.

A transcript carries zero or more marks, in whatever container the tool already uses for the transcript's own data.

Two kinds of mark

Not every shortfall belongs in the document, and the split is not by severity. The test is:

Could a reader of the finished transcript notice this without being told?

• A break in the recording leaves a blank, and a blank reads as a pause. The reader cannot notice. That is a document mark. It travels with the transcript.
• "Your custom word list could not be read" is about the minute the job ran. It is worth saying on screen, and it is not a fact about the document. That is a processing note. It stays in the interface.

A banner that is wrong is glanced at once. A document that is wrong follows the transcript for as long as it exists, looking exactly like a true one. That asymmetry is why document marks get the stricter treatment below.

Document marks

Every document mark answers one question for the reader: which of three things is missing? Missing audio is gone for good, and the reader has to look elsewhere. Missing words are still in the recording, and the reader can listen. Missing speakers means the words are all there and nobody is named against them, and the reader can label them by hand if it matters.

Audio is missing

Words are missing; the audio has them

Speakers were not told apart

Three speaker codes rather than one, because they send the reader to different remedies: this recogniser will not label this language, so a different one is needed; a shorter recording might be labelled; a second run might.

Processing notes

Shortfalls in the run that the document does not hide: a custom word list that could not be read or was refused; a summary that fell back to a general format because the kind of recording could not be determined; a language label that does not account for every script in the text. Shown on screen, not written into files. A tool defines its own.

Span rules

1. Positions are seconds into the stored audio, not wall-clock time. Audio does not advance while none is arriving, so a two-minute interruption is a point in the file, not two minutes of it. Measured from the clock, every span after the first drifts forward by the gaps before it, until the offsets point past the end of a file that is shorter than the meeting was.
2. A span starts where the affected audio starts. For missing words, that is the first second the recogniser wrote nothing for. For missing audio, it is the moment the audio stopped arriving, not the moment the stall was noticed: a watchdog fires after a threshold, and a mark placed there sits inside the gap. The reader jumps to it, hears the second half of nothing, and concludes the mark is wrong.
3. **seconds only when measured.** For missing audio, measure from the last frame that arrived: timed from the notice, every span under-reports by the threshold, systematically and silently. When it was not measured, leave it out. A guessed duration invites the reader to conclude the loss was small.
4. The shortest loss worth reporting is one second. A span is a claim that something is missing, and a reader acts on it by going to look. Below a second there is nothing to find. This bounds seconds where it is present; startSec may be zero, and an absent seconds is valid. Validate as "at least one", not "positive": a source that ends a few milliseconds after its last frame rounds to zero, and if the span rides along with the upload, refusing the span refuses the recording.
5. At most twenty spans per mark. Past that the individual timestamps stop being useful; the honest summary is that the recording was broken throughout. Over the cap, merge the two neighbours with the least audio between them, and repeat. Never drop. Dropping makes "it broke forty times" read as "it broke twenty times": a smaller number, in the direction that flatters the tool.
6. **A merged span's seconds is the sum of the two, not the distance between their ends.** The distance counts audio that was captured as though it were lost. Where either side is unknown, the merged value is unknown too.
7. A position never exceeds the length of the stored audio. A duration may. Lost audio is, by definition, not in the file: a recorder that stopped for an hour inside a ten-minute file reports a span of one hour. Bound seconds by a fixed ceiling of your own (the longest recording you accept is a natural one), not by the file.

Where a mark goes

• Document formats (plain text, Word, PDF, and the f4 layout that MAXQDA and ATLAS.ti read): one sentence per document mark, at the top, before the first word, naming its places in the player's clock (14:32 (about 118s)). A JSON export carries the same sentences as a notes list beside the words.
• Subtitle tracks, editor timelines and timed tables (SRT, VTT, FCPXML, NVivo's rows and the like): one cue per span, at the second it applies, lasting the measured length up to five seconds, or two seconds when nothing was measured. A track is played against the media, so the place to say "this is missing" is the second it is missing. Only marks with a span inside the media: a speaker mark has no moment to sit at, and a cue asserting it over an arbitrary second would be inventing a position; a mark at the very end of the media (recording_end_may_be_missing) has no second left to play at. The document formats carry those.
• Shared copies: every document mark, before the words, in the interface's own wording.
• The interface: everything, document marks and processing notes alike.

Wording

1. Say what is true of the reader's document, never which component failed. "Scene detection failed" is the tool's problem. "The summary uses the general format" is the reader's.
2. Say which of the three things is missing: audio, words, or who said them. "Something is wrong here" cannot be acted on.
3. Say "may" when nothing measured it. A copy that was written out before its page closed is whole, and nothing downstream can tell it from one that was not.
4. An unknown code still says something. Codes gain members, and a build that has sat on a machine for months will receive one it has never heard of. Show the raw identifier. Never reassure: "this does not affect the content" is a claim about a code you cannot read.
5. In a file, a code you have no sentence for gets the bare code or nothing, never a sentence written for a different code. Losing a disclosure is bad. Inventing one is worse, and the reader of a file cannot tell a sentence you wrote from a sentence you guessed.

What this spec is not

It is not a confidence score, a quality grade, or an error rate. It carries no number that says how good a transcript is. It says only where the transcript is known to be short, and which way to read the blank. A tool that adopts it claims nothing beyond: we told you what we knew.

Adopting it

• Write marks into your transcript's data with the codes above. Add your own with a prefix (yourtool.noise_suppressed) and decide which kind each is by the one test: can a reader notice it unaided?
• Put one sentence per document mark at the top of every text export; in every timed export, one cue per span that lies inside the media (a speaker mark, and a mark at the media's end, have no second to sit at); and keep every document mark on every shared copy.
• Decide document-or-processing in one place, and have every renderer ask that place. Two copies of the list drift, and the drift does not report itself.
• Keep the span rules' numbers in one place, for the same reason.

The codes and rules above are the ones in use at txscribe, where this started. They are published so that other tools can write the same marks and readers can learn one vocabulary. New codes are expected. Renaming one is not.