Smart transcription is not an audit transcript

On August 26, Google launched Gemini 3.5 Transcribe as a speech-to-text model for voice apps and post-call analytics. Its launch page says smart transcription removes filler words, handles self-corrections and formats the result. The pricing page I rechecked on September 11 lists non-streaming transcription at an estimated $0.0051 per audio minute: roughly 23 cents for a 45-minute call.

That combination is excellent for adoption and dangerous for naming. Cheap, polished text will spread everywhere, and the file called transcript will quietly become the thing people quote during a dispute.

A smart transcript is not an audit record. It is a derived reading aid that deliberately changes the spoken stream. Where recording is permitted, preserve the source audio under the applicable policy, version every text derivative, and make any material excerpt resolve back to an exact audio span.

The model is doing what the feature promises

There is nothing defective about cleanup. A reader usually wants “Let’s meet Wednesday” instead of the full spoken path through Tuesday, a correction and two hesitations. A support manager wants searchable issues, not a page of “um” and “uh”. Smart transcription is useful precisely because it interprets.

Google’s current API documentation makes the product boundary clearer than the launch page did. It describes verbatim as the default mode and smart as an optional mode that removes disfluencies, resolves inline corrections and restructures speech for reading. It also says smart mode cannot be combined with word timestamps or speaker diarization. These defaults describe the September 11 documentation; the August 28 launch page did not establish them.

The implementation risk begins when an application flattens both modes into the same field. If transcript_text can hold verbatim output today, smart output tomorrow and a human-edited version next month, its name carries more certainty than its contents. Speaker labels and timestamps do not fix that. They locate model output; they do not prove the words match the recording.

Accuracy and authenticity answer different questions

Google reported a 2.6% average word error rate for non-streaming use, measured by Artificial Analysis. That is a benchmark result, not a guarantee for a particular accent, noisy room, product code or consequential sentence. More importantly, recognition accuracy and record authenticity are different tests.

Imagine a speaker says, “Ship Friday—no, Monday.” Smart output may correctly resolve that to Monday. A recap needs the final instruction. A reviewer investigating how the instruction changed needs the correction too. Both outputs can be useful; only the recording contains the complete event.

NIST’s digital-evidence work gives the distinction useful rigor. Its forensic framework lists separate questions such as whether two files match at binary or content level, whether a recording is authentic and unaltered, and whether a communication is the original authoritative source. Its preservation guidance recommends documenting the original source, hashing digital files, storing the hash separately, and protecting evidence with authentication, access control and logging.

That guidance is for evidence handlers, not a blanket legal rule for every sales or support call. The transferable engineering principle is narrower: do not overwrite the source with an interpretation and then ask the interpretation to prove itself.

Build two lanes, not one transcript

The record lane and the convenience lane should meet at a reference, never collapse into one object.

I would make the boundary mechanical:

1. Capture the source once. Where consent, purpose and retention policy allow recording, store the original audio as write-once or version-protected data. Give it a stable recording ID and calculate a cryptographic hash at ingest.
2. Attach a process manifest. Record the model identifier and version, transcription mode, configuration hash, creation time, transcript hash and any diarization or timestamp settings. A model alias alone is not a version receipt.
3. Fork named derivatives. Keep verbatim text, smart text, summaries and extracted actions as separate artifacts pointing to the same recording ID. Never let regeneration overwrite an earlier result.
4. Patch corrections. A reviewer correction becomes a new layer with author, time and reason. Preserve what the model originally returned; otherwise review destroys the evidence of what needed review.
5. Escalate material use. Compliance findings, disputed commitments and quality decisions should link to the relevant audio span. Search may start from text; verification ends at the recording.

This is the voice equivalent of the archive’s earlier rule that AI research needs evidence lineage. There, a material claim needs a source. Here, a material sentence needs an audio reference. It also extends the argument that version control needs eval history: text history is incomplete without the model, settings and review state that produced it.

The label is part of the control

Do not name a smart transcript audit_transcript_final. Name what it is: smart_transcript, verbatim_transcript, human_corrected_transcript or call_summary. Then expose the distinction to downstream systems. A retrieval agent should know which artifact it is quoting; a human reviewer should see whether the quote is model output or a reviewed correction.

My approval test would be five questions. Can we regenerate the text without losing the original? Can a quoted sentence play its source span? Can we state which model, version and mode created it? Can we see every correction without erasing the prior output? Can access and deletion follow the recording policy rather than whatever a meeting bot happens to retain?

If any answer is no, the artifact may still be useful for search and recap. It is not ready to carry an audit claim.

I did not run Gemini 3.5 Transcribe against a controlled audio set, so this is not a product evaluation or a word-error-rate replication. I inspected Google’s launch, pricing and current API documentation, then checked the record-design recommendation against NIST’s preservation guidance. The operating pattern is my editorial judgment; retention, consent and evidentiary requirements still belong to the relevant jurisdiction and policy owner.

Polished text is a better interface than raw audio. It is simply a worse place to hide the only copy of what happened.

Let smart transcripts make calls readable—but keep the permitted audio, provenance and time-span links that make the record checkable.