Inverse text normalization: define what your parser gets

A parser can accept a transcript that uses the wrong convention. Decide what inverse text normalization should preserve before treating its output as ready for code.

TL;DR: Before code consumes an AI transcript, specify whether numbers use spoken or written form, whether disfluencies stay, and whether speaker-attributed word timestamps are required. NVIDIA documents instruction-selected styles in Nemotron 3.5 Transcribe. A schema-valid record is not, by itself, evidence that the intended meaning was preserved. That last distinction is an engineering inference from the documented scopes, not an audio test result. [1] [2]

I would settle the representation before adding parser fixtures. The difference becomes concrete when a zero belongs to an identifier.

Inverse text normalization: choose the text before parsing

Inverse text normalization converts spoken-form transcription text into written form. NVIDIA's NeMo terminology documentation places it in automatic speech recognition (ASR) post-processing and gives the example “one hundred twenty three” becoming “123”. That versioned documentation establishes terminology, not the current capabilities of a newly announced model. [4]

The Nemotron 3.5 Transcribe announcement, dated 28 October 2026, describes a broader choice. NVIDIA documents numbers in spoken or written form, verbatim wording or cleaned-up disfluencies, and other transcription conventions. It says the style is chosen with a natural-language instruction for each request, without retraining. These are the publisher's descriptions; no model run was performed for this article. [1]

That makes “give me a transcript” an incomplete instruction for a consumer that depends on one particular spelling of a number. Inverse text normalization is one part of the representation decision. It does not name every cleanup operation, correction policy or speaker requirement.

Attribution and timing

Are speaker attributed timestamps available? The announcement says the model returns speaker-attributed word-level timestamps on request. That is documented availability, not an independently checked timing or speaker-accuracy guarantee. [1] If the consumer needs them, specify that requirement and how the application will interpret timing fields. Do not assume a readable block of prose supplies them.

The contract can be a few explicit assumptions next to an existing parser. Its job is to remove ambiguity before text reaches that parser, especially when a written number can carry more than one kind of value.

A number can be an identifier

Consider the hypothetical utterance “reference zero zero seven”. No audio was recorded and no model produced the alternatives below. They are proposed representations for examining a consumer's assumptions, not observed transcription outputs.

For this proposed reference field, I would require a three-character string and preserve the leading zeros. For a count of seven items, I would choose a numeric value instead. Those are application-design choices. A general instruction to clean up the transcript does not document which choice the application made.

The same separation applies to disfluencies. Retaining a speaker's self-correction and selecting the corrected value are different decisions. The announcement supports choosing verbatim or cleaned-up wording, not a tested rule for interpreting every correction. [1]

This is the practical point of a transcript normalization contract: make the convention and the field's meaning explicit. Then ask what the record validator can actually establish.

Schema versus meaning: a valid string is a narrow result

JSON Schema's introductory guide describes structure, constraints and data types for JSON data. Its validator takes a schema and an instance. The guide shows type checks, required properties and value constraints. [2]

A string-only check would allow both "007" and "7". The following proposed schema fragment adds a three-digit shape requirement for our fictional reference field. It has not been run here and is not a transcription-provider response schema:

{
  "type": "object",
  "required": ["reference"],
  "properties": {
    "reference": {
      "type": "string",
      "minLength": 3,
      "maxLength": 3,
      "pattern": "^[0-9]{3}$"
    }
  },
  "additionalProperties": false
}

These constraints distinguish a three-digit string from a one-digit string. They do not distinguish the intended "007" from a different three-digit string such as "008". The candidate JSON alone contains no observation of what was spoken.

That is a limit of the evidence supplied to this check, not a claim that schemas can never validate meaning. Encoded value constraints can rule out meaningful errors. If a trusted expected value is supplied to an appropriate check, the check can compare against it. Someone still needs to establish that expected value from the relevant source.

A representation constraint can reject a malformed identifier without proving that the remaining identifier matches the audio. This is the inference from comparing the documented transcription choices with instance-validation scope. [1] [2]

The related discussion of schema validity versus interpretation correctness follows that boundary into typed decisions. Here, the unresolved question stays upstream: which audio-derived text should the parser receive?

Testing the representation contract

The AI SDK Core testing documentation says its mock providers and test helpers let developers control outputs and test consuming code without calling a language-model provider. That is useful precisely because the input is controlled. It is not evidence of how a speech model transcribed a recording. [3]

For the hypothetical reference field, I would separate these proposed checks:

• Feed "007" into the consumer and check that the identifier stays intact.
• Feed "7", a numeric 7, or a missing reference into the consumer and check its declared rejection or handling policy.
• Supply a required speaker or timestamp field, then omit it, to exercise the consuming code's handling of each case.
• Separately run consented or synthetic audio through the actual transcription path and compare its output with a declared reference representation.

None of these tests was executed for this article. The first cases would exercise application behavior under fixed inputs. The last needs an actual audio/output pair, the requested convention and a justified expected result. A passing fixture test cannot supply that missing observation. This is an application of the documented fixture scope, not a claim that the SDK provides a transcription simulator. [3]

The distinction gives each failure somewhere useful to go. If a fixed "007" input loses its zeros, investigate the consumer. If the live transcription path returns another representation, inspect the request and the audio/output pair before blaming the parser. Those are proposed diagnostic branches, not findings from a production incident.

For the broader testing-layer choice, continue with separating parser fixtures from live model-quality evaluations. That is related reading, not proof of speech accuracy.

Response-shape and stream fixtures

The same AI SDK page documents simulated readable streams with delays. [3] If your integration receives chunks, controlled partial responses can exercise its assembly and incomplete-input handling. A truncated record belongs in that test set only if it represents a failure the integration needs to handle.

This says nothing about whether Nemotron 3.5 Transcribe offers live streaming. That capability was not verified. The continuation on response-shape and stream fixtures concerns consuming-code tests, not a speech simulator or an audio-fidelity benchmark.

When a separate contract would be too much

The strongest objection is that an existing schema and a few fixtures can already express these requirements. I agree. A fixed integration does not need a new service or another document just to say that reference preserves leading zeros. Put the representation assumption beside the code and tests that depend on it.

A human-only note may not need a parser contract at all. Verbatim vs normalized transcription is a choice about the reader's purpose; the announcement itself says there is no single correct transcript for every reader and use. [1] The extra specification earns its place when consuming code relies on that choice.

For speech to text normalization, the useful question is therefore narrower than “does this look clean?” When inverse text normalization changes a number's spelling, ask which form the consumer expects and which evidence checks it. In our proposed reference example, those are a preserved identifier, a constrained record, and a separate audio/output comparison. Do not let success on one stand in for the others.

Sources were inspected on 29 October 2026. The model was not run; audio fidelity, timing quality, deployment fit and privacy or retention behavior remain unverified. This is a representation-contract argument, not a recommendation of a model for a consequential use.

Share a spoken-number edge case with the engineer who maintains your parser. Decide together which characters must survive before calling the transcript valid.

References

1. NVIDIA, Nemotron 3.5 Transcribe research announcement . Published 28 October 2026; captured 29 October 2026. Publisher documentation of selectable conventions and on-request speaker-attributed word timestamps, not independently tested behavior. Publication hour and timezone were not established.
2. JSON Schema, Creating your first schema . Captured 29 October 2026; publication/update date not established. Structure, constraints, types and instance-validation scope. The audio-correspondence distinction and proposed reference schema are this article's engineering application.
3. AI SDK Core, Testing . Captured 29 October 2026; publication/update date not established. Controlled mock outputs without provider calls and simulated readable streams. Applying that scope to transcript-consuming code is a proposal, not an audio experiment.
4. NVIDIA NeMo 24.09, Text (Inverse) Normalization . Captured 29 October 2026; publication/update date not established. Versioned terminology source for post-recognition conversion into written form and the documented “one hundred twenty three” to “123” example. Not evidence of current model capabilities.