Short answer
A workplace glossary is a list of the names, abbreviations and synonyms a site uses for its equipment, materials and actions, each tied to a definition or a reference image. It helps a language-conditioned robot system resolve what an instruction refers to. It says nothing about how to move, grip or apply force, so it supports grounding and planning, not control.
Why site vocabulary is its own purchase
A supervisor who says "pull the gaylord to dock 4" is using three local terms in one sentence. A language model trained on general text may guess that a gaylord is a person's name. The same site may call one object a tote, a lug, a bin and a case, depending on department and shift.
Procedures, work orders and checklists already contain this vocabulary, but it is scattered and implicit. A glossary pulls it into one place and makes the mapping explicit: term, variants, definition, category, and what the term points at in the physical world. That mapping is what an instruction-grounding pipeline needs when it decomposes "restock the sanitizer" into objects it can look for and actions it can plan.
This page covers sourcing the vocabulary asset itself. For how running procedure text feeds grounding, see procedural text for instruction grounding.
What counts as a glossary asset
Operating businesses keep terminology in more places than a document titled "glossary":
- Defined-terms sections at the front of quality manuals and SOPs.
- Abbreviation lists attached to maintenance logs, shift handover notes and engineering drawings.
- Equipment registers with asset tags, common names and manufacturer model names.
- Controlled vocabularies in a computerized maintenance system, such as failure codes, location codes and part names.
- Onboarding sheets that translate shorthand for new hires.
- Style guides for technical writing that fix which word is allowed for which thing.
The published precedent is a language resource built from real logbooks. MaintNet provides logbook data from aviation, automotive and facilities domains together with abbreviation lists, termbanks and pre-processing tools (Akhbardeh et al., 2020). That mix is a useful template: raw text for context, plus curated lists that normalize it.
What the data can support and what it cannot
A glossary can support:
- Resolving a spoken or written instruction to named objects and locations.
- Normalizing jargon, misspellings and abbreviations before text goes to a planner or parser.
- Building synonym sets so one object is not treated as four categories.
- Aligning labels across suppliers so datasets from different sites share one ontology.
- Authoring evaluation instructions that use site language as a robot would actually hear it.
A glossary cannot support:
- Physical control. A definition of "torque to spec" gives no motion, force or perception data. Control training needs robot or teleoperation data, not text alone.
- Perception without images. A term with no reference photo or catalog entry does not teach a detector what the object looks like. Pair it with catalog text and images.
- Proof of real usage. A glossary records what the organization says its words mean. Workers may use them differently on the floor.
- Affordances. Published grounding work separates what a language model proposes from what a robot can actually do: the language model supplies task knowledge while pretrained skills supply feasibility (Ichter et al., 2022). A glossary sits on the language side of that line.
Illustrative glossary entry schema
The record below is Illustrative. Field names and values are synthetic; adapt them to your ontology.
| Field | Example (synthetic) | Why a buyer wants it |
|---|---|---|
term | "lug" | The surface form found in text |
variants | "lugs, tote, crate (site_017)" | Synonyms scoped to a site |
type | object / action / location / abbreviation | Lets you route entries to different modules |
definition | Free text, supplier-written | Disambiguation for annotators |
refers_to | Equipment register ID or catalog ID | Link to a physical object class |
reference_media | Image or drawing ID | Grounding for perception |
scope | site_017, dept_B, since 2019 | Prevents one site's slang from leaking into another |
status | approved / deprecated / informal | Separates official from shop-floor words |
Action terms need the same treatment. "Break down the pallet" may mean unstacking cartons, removing wrap, or dismantling the pallet itself. A good glossary records which procedure each action term appears in and what the end state is.
Acceptance criteria you can set
- Coverage. Choose a sample of procedures from the target task set and check what share of nouns and verbs resolve to a glossary entry. Set your own threshold.
- Link rate. Count entries that point to a register ID, catalog ID or image rather than free text.
- Variant accuracy. Have a site worker review a sample of synonyms for errors.
- Currency. Check revision dates; deprecated names should be marked, not deleted.
- Neutrality. Entries should be free of internal part numbers, customer names or confidential process parameters unless the license covers them.
Preparation work the buyer should expect
Existing glossaries rarely arrive training-ready. Typical preparation includes parsing PDFs and spreadsheets, splitting merged cells, expanding abbreviations that mean different things in different departments, removing trade names or customer identifiers, and mapping entries to a shared taxonomy. See parsing scanned manuals and redacting SOPs for the mechanics. If you need the same terms in several languages, multilingual SOP corpora covers the extra care.
Questions to ask suppliers
- Who maintains the glossary, and when was each section last reviewed?
- Is the vocabulary official, or does it also include shop-floor shorthand?
- Do entries link to equipment register IDs, catalog entries or images?
- Which sites, departments and shifts does each term apply to?
- Are deprecated and conflicting terms recorded, or were they overwritten?
- Does any entry include proprietary part numbers, supplier names or process parameters?
- Is any content taken from manufacturer manuals, standards or third-party guides?
- Who can license the list, and can it be delivered in a structured format rather than only as a PDF?
Permissions and provenance
Glossaries look harmless but often reproduce manufacturer terminology, standards text or training material written by third parties. Ask the supplier which parts were authored in-house and which were copied. Customer or supplier names embedded in definitions can be confidential even when the list itself is not. Redacting names does not by itself settle whether the list may be licensed, so treat redaction as a preparation step and keep the rights questions separate.
Where glossaries fit in a humanoid program
Treat the glossary as scaffolding for the language and planning layers. It is a low-cost companion to procedures and catalog data, and it is most valuable when it connects to something physical. It does not replace what SOPs can and cannot teach, and it does nothing for the manipulation data a humanoid needs. The wider procedures cluster and the humanoid training data guide show where it sits next to demonstrations and object data.
For the planner side of the pipeline, see grounding LLM planners with SOPs, which covers how a controlled vocabulary constrains what a planner may propose.
Discuss your requirements
If you need site vocabulary for specific equipment, materials or task families, describe the modality, format, language and permitted uses to SourceX. SourceX reviews the requirement, looks for US businesses that may hold suitable material, checks the data and the supplier's licensing permissions, and follows up about potential sources. A request does not guarantee a match. The catalog page on SOPs, playbooks and knowledge bases describes the nearest existing category.
Describe the workplace vocabulary your robotics project needs to SourceX
Sources
- MaintNet: A Collaborative Open-Source Library for Predictive Maintenance Language Resources — logbook data with abbreviation lists, termbanks and pre-processing tools.
- Do As I Can, Not As I Say: Grounding Language in Robotic Affordances — language model proposals constrained by robot skill feasibility.