Speech Products: ASR & Transcription
Capacity Private Cloud's Automatic Speech Recognition (ASR) is the speech-to-text foundation of the platform. It accepts audio either as a single file or as a real-time stream of audio chunks and produces text through a Deep Neural Network (DNN) engine. Two recognition modes serve two different design problems: Grammar-Based ASR, where the engine matches speech against a constrained vocabulary defined by a grammar; and Transcription ASR, where the engine recognizes free-form speech against a statistical language model that covers the entire language.
This article covers the engine architecture, both recognition modes, post-processing (text normalization), and the streaming modes the platform supports. For an introduction to the speech product family, see Offering Overview. For definitions of speech terminology used throughout, see the Product Glossary.
The Engine
The ASR engine has a three-block architecture. Blocks 1 and 2 perform the acoustic task; block 3 performs the linguistic task. All input and output interactions are managed through the platform's API.
Block 1 — Audio pre-processing. Prepares the incoming audio for the neural network: framing, feature extraction, and normalization.
Block 2 — Deep neural network. Takes the audio features and produces candidate text in a single pass. The acoustic and feature work happens inside the network; conceptually it can be split into steps, but in practice it is one model.
Block 3 — Linguistic post-processing. Operates on the candidate text from block 2, using either a grammar or a statistical language model to turn a stream of letters into words that are coherent in context and in the order they were spoken. Block 3 does not see audio — its work is purely linguistic.
The engine's scoring algorithm is designed to deliver both accuracy and predictable resource consumption, which keeps horizontal scaling straightforward at production load.
Acoustic Model
The acoustic model is a single, deep-layered, self-improving network rather than a collection of per-dialect models. During training, it builds an extensible model that does not impose a limit on the number of dialects and accents per word, and does not require separate lexicons or auxiliary resources to produce accurate output.
The operational consequence is that organizations don't need to maintain — or pay to license — separate acoustic models for accents and close dialects of a language. The engine can also accurately spell words it has never encountered during training, which is significant for domains where new terminology appears frequently (medical transcription is a notable example).
Grammar-Based ASR
A grammar is a ruleset that defines the valid word and phrase choices the engine should recognize against. Grammar-Based ASR treats the language as a constrained subset, which is the right design for use cases where users are expected to speak only from a small set of possible utterances — menu choices, digits, yes/no responses, account numbers, and similar.
Beyond constraining the search space, grammars also resolve ambiguous pronunciations by predicting likely word combinations, and they carry semantic interpretation (so that "yes," "yeah," "of course," "sure," and "that's fine" can all map to the same intent value). For IVRs and automated customer service systems handling short utterances against predictable vocabularies — call routing, credit-card activation, repetitive transactions — Grammar-Based ASR delivers the highest accuracy the platform can produce.
Grammar Files
The engine supports the W3C SRGS (Speech Recognition Grammar Specification) standard. SRGS grammars are text files in either BNF or XML form, specifying patterns of words and the order in which they may appear. The platform ships with a number of out-of-the-box grammars (e.g. currency, digits, numbers, dates); most organizations author their own to fit their business logic.
Compiled Grammar Caching
When the calling application starts decoding audio, it sends a grammar alongside the audio request. For the engine to read it, the grammar must first be compiled into a binary format. The engine caches compiled grammars, so large grammars are loaded once and reused on subsequent requests without paying the compilation cost — provided the grammar source hasn't changed.
Aliases & Lexicons
Aliases are the platform's mechanism for telling the engine that when it recognizes word A, it should output word B. This is a powerful tool for matching predicted words to grammar entries and for producing the expected written form of domain-specific terms. Two common patterns:
- Word replacement — the recognized word "vulnerable" is replaced with "Shaky" before being compared against the grammar (useful when the deployment uses internal terminology that differs from the recognizer's output).
- Spelling interpretation — the recognized phrase "eye phone" is output as "iPhone" (useful for proper-noun and brand-name normalization).
For practical guidance on authoring and using SRGS grammars, see the grammar-authoring articles in the Knowledge Base Grammars.
Transcription ASR
Humans do not naturally constrain themselves to a grammar. To produce text from free-form speech, the platform offers Transcription ASR, where the engine recognizes audio against a statistical language model (SLM) that covers the entire target language rather than a closed-set grammar.
Transcription ASR is the right design for long-form speech — call center transcription, agent assist, quality assurance and sentiment workflows, chatbot interactions, video and conference transcription, and similar. It is also increasingly used for short-form utterances in IVRs and conversational AI where the enterprise wants the option to inspect what the caller actually said, not just match it against a fixed grammar.
Statistical Language Models (SLMs)
An SLM is a database of word relationships and their probabilities, trained on millions of lines of text in the target language. When a closed-set grammar isn't sufficient — typically for long-form transcription — block 3 of the engine applies SLM rules instead of grammar rules to predict words.
Like the acoustic models, the language models are built for global use: each model encapsulates word relationships across all accents and close dialects spoken worldwide, so a single Spanish model handles Mexican, European, and Latin-American Spanish without requiring deployment-specific variants. Where written-form spelling differs between dialects — for example, British and American English (colour / color) — the calling application can specify the dialect to control the spelling of the transcribed output.
For the current list of languages available for Transcription ASR, see the supported-languages reference in the Knowledge Base Languages Available.
SLM Augmentation: Phrase Lists
Phrase Lists let deployments augment a stock SLM with domain-specific terms and phrases — pharmaceutical and disease names in medical workflows, proprietary product names, geographic terms specific to the business, and similar. A Phrase List entry behaves much like a small grammar, with the addition that each phrase can be weighted to bias the engine toward it when the platform sees a near-collision with a similar in-vocabulary word. The weighting is further tunable through probability-boost settings to dial in the right trade-off between recall and false positives.
For practical guidance on building and tuning Phrase Lists, see the Knowledge Base Phrase lists.
Text Normalization
Speech recognition engines produce text in spoken form — words as they would be pronounced, without numbers, punctuation, dates, currency symbols, or capitalization (for example, "one hundred fifty-two thousand four hundred eighty-three dollars"). Spoken-form output is fine for short, grammar-based interactions where the recognized text feeds a system rather than a reader, but it is hard to read for long-form transcription and hard to feed into downstream analytics. Text Normalization (TN) — strictly speaking, inverse text normalization, though the industry uses "TN" as the umbrella term — converts the spoken-form output into the formatted, written-form text that humans and downstream applications expect (for example, $152,483).
The platform's TN capability consists of three independently togglable modules:
- Inverse Text Normalization
- Punctuation and Capitalization
- Sensitive Information Redaction
Each module is enabled or disabled via API flags on the recognition request. TN adds computational cost — additional CPU and memory headroom should be planned for deployments that turn it on at scale.
Inverse Text Normalization
The ITN module performs the following spoken-to-written-form conversions:
| Rule | Example |
| Cardinal numbers | "one hundred twenty-three million four hundred fifty six thousand seven hundred eighty nine" → 123,456,789 |
| Numbers + "million" / "billion" | "two point three million" → 2.3 million |
| Ordinal numbers | "first" → 1st |
| Two or more numbers < 100 in a row | "one ninety-two" → 192 |
| Times | "seven a m eastern standard time" → 07:00 a.m. EST |
| Dates | "may fifth twenty twelve" → may 5 2012 |
| Decimals | "three hundred and three dot five" → 303.5 |
| Alphanumeric sequences | "a b c d one two three" → ABCD123 |
| Measurements (%, km, °C, etc.) | "fifty pounds" → 50 lbs |
| Currencies | "fifty pounds" → £50 |
Punctuation and Capitalization
The punctuation and capitalization module restores both — known as true-casing — adding commas, periods, question marks, and language-specific marks, and selecting between first-letter capitalization, all-uppercase, or all-lowercase output according to configuration.
Sensitive Information Redaction
The redaction module marks words that contain personally identifiable information (PII) and labels the type of information identified. The module is currently available in English. Supported recognizers:
| Recognizer | Coverage |
| Passwords | Includes alphanumeric and special characters |
| Social insurance / security numbers | Australia, Canada, IBAN, USA |
| PIN recognizers | 4–6-digit sequences |
| Bank account numbers | Australia, Canada, IBAN, USA |
| Names | General |
| Driver's License | Australia, Canada, EU |
Downstream Benefits
Readability for human reviewers is the primary motivator for enabling TN, but the benefits extend to the systems that consume the transcribed text:
- Better intent classification and slot filling — downstream NLU models that were trained on written-form text perform measurably better when the transcript matches the form they were trained on (for example, "12:15" rather than "quarter past twelve").
- Cleaner segmentation — punctuation and capitalization let downstream pipelines split utterances into sentences, run discourse summarization, and generate FAQ extracts.
- More accurate analytics — sentiment analysis, search relevance, and ranking all improve when the input text matches the form the analytics models were trained on.
Languages supported for transcription text normalization vary by release — see the supported-languages reference in the Knowledge Base for the current list Languages Available.
Continuous Transcription Mode
In continuous mode the engine processes incoming audio one chunk at a time. The VAD detects when speech ends within each chunk, and the audio processing produces a word prediction — first pass, final pass, and post-processing — for every chunk continuously, without waiting for the end of the overall audio. This is the right mode for use cases where fast real-time output is the priority: IVRs, agent-assist implementations, and live subtitling.
Continuous mode vs. streaming with partial results. The two modes are related but serve different needs. Continuous mode produces a result only when a pause is detected, and the result is final once produced — well suited to subtitling, where each line of text is committed to the screen and shouldn't change. Streaming with partial results enabled produces interim results every few words and may revise them as more audio is processed — well suited to dictation and other real-time UX where the user expects the text to appear as they speak and stabilize as they finish a thought.
Enhanced Transcription Mode
Enhanced transcription combines transcription with grammars. Grammars are supplied either by creating a transcription interaction and attaching one or more grammar files, or through MRCP where an enhanced-transcription grammar is processed against ASR. Combining transcription with grammars enables NLP-style tasks — slot filling and entity recognition — on top of the open-vocabulary transcription output.
Related Articles
- Offering Overview — the speech product family in context.
- Speech Products: TTS — the text-to-speech counterpart to ASR.
- Speech Products: NLU & Diarization — natural language understanding and speaker diarization.
- CPA Technical Reference — Call Progress Analysis and Answering Machine Detection.
- Administration & Tuning Tools — Admin and Deployment Portals, Analysis Portal.
- Communication Protocol — gRPC and MRCP integration surfaces.
- Containerized Architecture — deployment model and operational characteristics.
- Product Glossary — definitions of the terms used in this article.