Glossaries and Custom Vocabulary: Teaching Your Transcriber Your Course Jargon

If your lectures are full of words like “anastomosis,” “Kubernetes,” or “cap rate,” you already know the pain: you hit transcribe, and the machine confidently turns your professor’s expertise into gibberish. The fix isn’t a better microphone. It’s teaching the transcriber the vocabulary your course actually uses.

Key takeaways

• Speech-to-text models guess from a general dictionary, so rare names, acronyms, and field-specific terms are the first thing they butcher.
• A custom vocabulary (also called a glossary, phrase list, or boost list) tells the transcriber which unusual words to expect and weight more heavily.
• Build your list from the syllabus, slides, and the first few minutes of any recording, where the jargon density is highest.
• Spelling and phonetic hints matter: give the model the exact spelling you want and, where supported, how the term sounds.
• Garbage transcripts produce garbage downstream, so cleaning vocabulary at the source saves you far more time than fixing it later.

Why transcribers mangle your jargon in the first place

Under the hood, a speech-to-text system is a probability machine. It listens to sound, then picks the run of words most likely to match, based on the enormous pile of everyday text it was trained on. “Photosynthesis” turns up all over that pile. “Phosphofructokinase” basically never does.

So when your biochem professor rattles off an enzyme name, the model falls back on its habit: it grabs something common that sounds close. You end up with “fossil fruit a kinase” or some equally cursed approximation. The audio was clear. The model just had no reason to expect that word.

This gets worse with three categories in particular:

• Proper nouns — researcher names, company names, product names, place names. “Bjarne Stroustrup” has no chance against a default dictionary.
• Acronyms and initialisms — “GAAP,” “REST API,” “CRISPR.” The model often spells these phonetically or breaks them into unrelated words.
• Domain terms that collide with common words — “cap rate” becomes “cap rape,” “VLAN” becomes “we land.” These are the sneaky ones. The transcript looks grammatical, so you don’t catch the error until it’s too late.

A custom vocabulary attacks all three by changing the odds. You’re handing the model a short list and saying, in effect: when you’re unsure, lean toward these.

What a custom vocabulary actually is

Different tools use different names. Whisper-based tools call it a prompt, or an initial prompt. Google’s speech API calls it speech adaptation, with phrase sets and boost values. AWS Transcribe just calls it a custom vocabulary. Otter, Rev, and similar consumer tools usually file it under “custom vocabulary” or “glossary” in the settings.

Underneath the branding, they do roughly the same thing. You supply a list of terms, and sometimes a strength value that controls how aggressively the model should favor them. A low boost nudges. A high boost can force the term even when the audio is ambiguous, which is great right up until it starts hearing your jargon everywhere, including where nobody said it.

Some systems also take pronunciation hints. If a term is spelled nothing like it sounds — think “Nguyen” or “Worcestershire” — you can hand over a phonetic spelling so the model maps the sound to the right written form.

A quick mental model

Think of it like autocorrect on your phone after you’ve typed an unusual name a few times. At first your phone fights you. Once it learns the word, it stops “correcting” it into something dumber. A custom vocabulary is you doing that teaching up front, deliberately, instead of letting the model keep guessing wrong.

How to build your glossary from a course

Here’s the part that saves real time. You don’t need to brainstorm every word — your course materials already contain the list. Pull from them in this order.

1. Mine the syllabus and slide decks

Your syllabus topics and slide titles are a dense source of the exact terms that’ll show up in lecture. Skim them and pull anything that’s a proper noun, an acronym, or a term you wouldn’t expect a random person to know. A single intro slide for a networking course might hand you “OSPF,” “subnet mask,” “CIDR,” and “VLAN” in one shot.

2. Listen to the first five minutes

Most lecturers front-load definitions and key names. Transcribe a short sample first, scan it for obvious errors, and add the corrected spellings to your list. This is your fastest feedback loop.

3. Add the names

Instructor name, textbook authors, recurring researchers, software, datasets. Names are where transcribers fail most embarrassingly, and they’re easy to forget because you already know how to spell them.

Mini-scenario: a cloud-security lecture

Say you’re transcribing a cloud-security lecture. Your first raw pass comes back with “we land segmentation,” “I am roles,” and a “U2F key” rendered as “you to F key.” You spend three minutes building a glossary: VLAN, IAM roles, U2F, SAML, OAuth, zero trust, NIST 800-53. Re-run with that list loaded, and the next recording in the series comes back clean enough to actually study from. You built the list once. It pays off across the whole term.

Tips that separate a good glossary from a useless one

Spell it the way you want it written. The model outputs your spelling, so if you want “PostgreSQL” and not “Postgres” or “postgre sequel,” put exactly that.

Don’t dump your entire textbook in. A bloated list dilutes the signal and can make the model over-trigger, hearing “CRISPR” in every cough. Keep it to terms that genuinely confuse the transcriber. Fifty sharp entries beat five hundred lazy ones.

Use boost values with restraint where you have them. Start moderate. If a term still gets missed, raise it. If the model starts hallucinating the term, lower it. It’s a dial, not a switch.

Group multi-word phrases as phrases. “Deep packet inspection” as one entry behaves differently than three separate words. Phrase-level entries help the model lock onto the whole expression.

Reuse and version your list. Save a glossary per course or per project. Next semester’s recordings will share most of the vocabulary, so you’re rarely starting from zero.

Where transcription ends and the rest of your workflow begins

Cleaning vocabulary at the source matters because every later step inherits the transcript’s mistakes. If you summarize a lecture full of “we land” and “fossil fruit a kinase,” your notes are quietly wrong, and so is anything you write from them. Fixing the input is cheaper than fixing every output.

It’s also worth separating two different jobs. Getting an accurate transcript is a fidelity problem — you want the words to match what was said. Turning that transcript into your own study notes or a discussion post is a writing problem, and that’s where you bring your own voice. If you ever draft from AI-assisted notes and want the final writing to read like you and not like a model, that’s a separate pass. Curious why machine-written text often reads “off”? The statistics behind AI detectors are worth a look, and the PaperBleach blog has more on writing that sounds human. If you want to know what a humanizing pass costs before you commit, the pricing page lays it out.

Frequently asked questions

Does a custom vocabulary work with every transcription tool?

No, but most serious ones support some version of it. Cloud APIs from Google, AWS, and others have robust phrase-list features. Whisper-based tools accept a prompt that nudges vocabulary. Consumer apps vary — check the settings for “custom vocabulary,” “glossary,” or “boost.” If a tool offers none of these, your only lever is post-editing find-and-replace.

How many terms should I add?

Enough to cover the real trouble words, and no more. For a single course, a few dozen well-chosen entries usually does it. The goal is to fix what’s actually breaking, not to pre-load every word you might say. Oversized lists can make accuracy worse, not better.

Will a glossary fix bad audio?

Not really. Custom vocabulary helps the model choose between plausible word candidates when the audio is decent. If the recording is muddy, echoey, or the speaker is far from the mic, no word list rescues it. Fix the recording conditions first. The vocabulary handles the jargon on top of clear sound.

What about acronyms the model spells out as words?

That’s the classic case for a phrase entry plus the exact spelling. Add “U2F” or “REST API” as you want it written. If it still mangles a sound-alike acronym, a pronunciation hint (where supported) maps the spoken sound to the right letters.

Do I have to rebuild the list every recording?

No. Save it per course or project and reuse it. Lectures in a series share almost all their vocabulary, so you build once and load it for every session that term. Add new terms as they come up.

Closing

A transcriber isn’t stupid. It’s just guessing from a general dictionary, and your course is anything but general. Spend ten minutes teaching it your jargon, and you turn a frustrating, error-riddled transcript into something you can actually learn from. Build the list from your syllabus, keep it tight, reuse it all term.

Once your transcript is clean and you’re turning it into your own writing, run a quick check with PaperBleach to make sure the final draft sounds like you.