An engineer says “expansion joint” during a bridge inspection interview, but a recognizer unfamiliar with the topic may hear an everyday phrase. Deepgram’s keyterm prompting can bias Nova-3 transcription toward important terminology. It cannot verify that a speaker actually used a term, so it belongs in a review process rather than in a final evidence record by itself. The example below uses a fictional inspection and imaginary audio; it does not report measured accuracy or a completed transcription run.
Define the evidence and a small glossary first
Start with the interview’s purpose: producing a readable technical transcript for a bridge maintenance briefing. The source of truth is the original recording, not a glossary chosen before playback. Make a candidate list from field notes, approved technical vocabulary, and actual project names. Mark disputed phrases explicitly instead of converting uncertainty into a keyword that the model is expected to repeat.
For this fictional example, useful candidates include expansion joint, bearing seat, and deck delamination. A name can have multiple pronunciations and the same sound may describe a different object. Keep the glossary short and attach a reviewer-defined definition to each term. Do not include personal data just because it might improve recognition; sensitive names add privacy obligations.
Choose a model that accepts the feature
Deepgram documents keyterm prompting for Nova-3, including monolingual and multilingual transcription, and for compatible Flux streaming use. Other models may use the older Keywords mechanism instead. The methods are not interchangeable. In particular, Nova-3 keyterms are plain text without the numerical boosting weights used by the legacy keywords interface.
Before making an API request, check the current model, language, prerecorded versus streaming endpoint, audio format, and account settings. A request configured for an older model may ignore the intended mechanism or use different parameters. Our scenario uses a prerecorded audio file with the Nova-3 path; it does not assume live streaming or a specialist domain model.
Encode each technical phrase as one keyterm
For a prerecorded Nova-3 request, Deepgram uses repeated keyterm query parameters. A phrase such as expansion joint should be URL encoded as one phrase, for example keyterm=expansion%20joint. A separate term gets its own keyterm parameter. Supplying a comma-separated collection or a legacy weight suffix is not the same request and can quietly undermine the intended prompt.
A schematic request would target the prerecorded listen endpoint with model=nova-3 and the approved keyterms, using authenticated transport and only audio that may lawfully be sent to the provider. Keep tokens out of shared examples and source control. Store the submitted glossary alongside the interview revision so an editor can later explain why a particular spelling appeared.
Protect keyterms in usage records and respect limits
Deepgram warns that keyterms may appear in usage records. If a legitimate term is sensitive, the documentation identifies redact_usage=true as a way to redact stored usage-keyterm text. Check the service’s current privacy terms and storage policy before transmitting the underlying recording. Redacting a usage field should not be confused with permission to upload private interview audio.
The current documentation also describes a 500-token limit across supplied keyterms and discusses up to 100 important terms. Treat those as configuration constraints, not a target for maximum prompt size. Flooding a request with speculative terms makes auditing harder. Select only phrases that are likely to occur and for which a qualified reviewer can distinguish a correct mention from a fabricated one.
Compare a baseline with a prompted transcript fairly
To evaluate an actual deployment, save one source audio clip and run comparable baseline and prompted requests with the same model, language, and decoding settings except for the keyterm list. Line up the transcripts with timestamps and replay the suspect passages. Count correct mentions, inserted mentions, missed mentions, and false substitutions; do not count only the words that improved.
The illustrations in this guide are conceptual: a baseline may render “expansion joint” as a more common phrase, while a prompted version may spell it correctly. That is a possible review scenario, not a result observed by LabFin. When the audio is ambiguous, the final transcript should preserve uncertainty or a timecoded editor note instead of selecting the glossary term as fact.
Treat technical nouns and numbers differently
A pronunciation hint is not a repair specification. If the speaker seems to say a dimension, location, inspection rating, or date, verify those details separately against the waveform, notes, and authorized records. One misheard digit can change a work order. Do not let a correctly spelled bridge component create false confidence in neighboring quantities or engineering conclusions.
Document who can adjudicate the vocabulary. A qualified inspection reviewer may resolve the name of a component; an editorial assistant should not infer a structural defect from a transcript alone. Keep any report conclusions outside the automatic transcription stage and make corrections reversible so later reviewers can distinguish the raw model output from a human amendment.
Build an explicit transcript release checklist
Maintain the consent basis for recording, audio identifier, encoding, model version, endpoint type, language settings, accepted keyterms, prompt revision, and separate reviewer comments. Check speaker changes, clipped syllables, overlapping voices, abbreviations, proper nouns, timestamps, negative phrases, and all figures with operational consequences. The ability to search technical words is useful only if the quoted text remains faithful.
Before sharing, minimize participant identifiers and decide whether raw audio, automated output, and corrected transcript have different retention periods. If a glossary contains sensitive site codes, restrict both the glossary and logs. An external transcript should not imply that Deepgram validated the bridge, signed the inspection, or certified the correctness of engineering terms.
Make the decision from audio, not model confidence
A production acceptance rule can be simple: a changed term is accepted only when a reviewer can hear supporting speech or corroborate it with an authorized primary record and clearly label that correction. Send unresolved audio spans to a specialist, even if the resulting transcript is less fluent. A visible uncertainty marker is preferable to an invented certainty in a compliance or maintenance document.
No customer-specific evaluation or measured keyword recall rate was performed for this article. The vendor describes potential recall gains, but those figures are not a prediction for noisy bridge recordings. Check current Deepgram API behavior, rate limits, data terms, and regional availability before building a real workflow around keyterms.
How We Research
For this November 2026 guide, we reviewed named vendor-maintained documentation: Deepgram: Keyterm Prompting, Deepgram: Pre-recorded transcription API. We extracted the documented feature controls, compatibility boundaries, and relevant limitations, then designed a narrowly scoped fictional workflow and evidence-based failure checks for the specific scenario above. This was a source review, not hands-on testing: no account or API credentials were used, no live data was sent, no outcomes or quality measurements were observed, and no vendor-generated screenshots were taken. The diagrams are conceptual. Before deploying, recheck current availability, privacy terms, region and plan access, prices, and the latest official documentation. An authorized human, not an extraction or language model, remains responsible for any legal, safety, access-control, or release decision.
Frequently Asked Questions
No. It biases recognition of likely terms; a reviewer must confirm any important occurrence against actual speech.
No. Deepgram documents plain keyterm strings for Nova-3 rather than the weighted syntax from the older Keywords feature.
URL encode it as one keyterm value, and repeat the keyterm parameter for any additional phrase.
No. Deepgram notes keyterms may enter usage records; review redact_usage=true and the full data handling policy.
Keep an explicit uncertainty note and seek an authorized review instead of accepting a suggested term as proven.