How Do You Manage Terminology Across an OCCAR Programme
- May 28
- 9 min read
Managing terminology across an OCCAR programme is not a documentation task. It is a data governance challenge with direct consequences for audit compliance, contractual accuracy, and multinational coordination. Across programmes like Eurofighter, A400M, Boxer, and Tiger, a single misaligned term can propagate through specifications, handbooks, and interface control documents across six nations and dozens of contractors. How you manage terminology across an OCCAR programme determines whether your documentation holds up in an AQAP 2110 audit or generates costly clarification loops that delay milestones.
Table of Contents
Key Takeaways
Point | Details |
Build on stable term IDs | Assign each concept a language-independent ID (e.g., CON-00014) to anchor translations across all partner nations. |
Align with NATOTerm and NSO | Map programme terms to NATO-approved equivalents before publication to maintain legal and technical authority. |
Govern the full term lifecycle | Define extraction, validation, approval, and retirement steps with documented SLAs and role assignments. |
Integrate tools via TBX and APIs | Use open-standard exports and real-time API validation to keep CAT tools, CMS, and TMS synchronized. |
Maintain audit-ready records | Track every term decision with who changed it, when, and why to meet AQAP 2110 and ISO 17100 requirements. |
How to manage terminology across an OCCAR programme: the foundation
The first structural decision you make determines everything that follows. Terminology management for defence programmes is a data integrity challenge requiring stable IDs, lifecycle statuses, ownership roles, and audit trails. A flat glossary spreadsheet shared by email is not a termbase. It is a liability.
The industry standard for multinational programmes is a master-term-with-translations architecture. Each concept receives a stable, language-independent ID such as CON-00014. That ID is the anchor. German, French, Spanish, and English translations all attach to the concept, not to each other. This prevents the common failure where the French team updates a term definition without realizing the German equivalent was not updated correspondingly.
Aligning with NATOTerm and NSO standards
Before you publish a single term, map your programme-specific vocabulary against NATOTerm and NSO-authorized legal and technical equivalents. Where a NATO-standardized term exists, use it without modification unless your programme has a formally documented, configuration-managed reason to deviate. Deviations require a governance record. Undocumented deviations become audit findings. For more on how NATOTerm alignment drives audit-ready terminology, the implications run deeper than most programme managers expect.
Structure your termbase data using the TBX (TermBase eXchange) open standard. TBX supports interoperability among CAT tools, content management systems, and translation memory platforms. Each entry should carry metadata fields covering domain, definition, usage note, source reference, status (draft, approved, deprecated), and locale-specific attributes.
Roles and governance baseline
Assign four defined roles from programme initiation:
Terminologist. Owns the termbase architecture, extraction methodology, and term quality.
Language leads. One per partner nation language. Responsible for locale-specific validation and morphological consistency.
Subject-matter experts (SMEs). Engineers, legal officers, and systems specialists who confirm technical accuracy and contractual meaning.
Programme terminology authority. The single approval authority whose sign-off moves a term from “draft” to “approved.”
Governance alignment should reference ISO 17100 for translation quality, ISO 27001 for information security controls over the termbase infrastructure, and AQAP 2110 as your defence-specific quality management baseline.
Implementing a structured terminology workflow
A termbase without a managed workflow is a snapshot that decays. The workflow keeps it alive and traceable across the programme lifecycle.
Term extraction. Extract candidate terms from source documents using either manual review by your terminologist or semi-automated extraction tools in your CAT platform. Apply domain filters to avoid extracting general vocabulary.
Normalization by concept. Group candidate terms by the underlying concept, not by surface form. “Maintenance action,” “maintenance task,” and “service action” may refer to the same concept or three distinct ones. That determination must happen before any translation work begins.
SME validation. Route each candidate term to the relevant SME for technical confirmation. Define an SLA here. Unreviewed terms sitting in a validation queue are a programme risk.
Language lead review. Each language lead confirms the target-language equivalent, checks locale-specific attributes (grammatical gender, plural forms, formality register, right-to-left script requirements where applicable), and flags conflicts with NATOTerm-approved forms.
Programme terminology authority approval. Approved terms are published to the live termbase. The approval record, including the approver ID and timestamp, is written to the audit trail.
Publication and distribution. Push approved terms to all integrated systems: CAT tool termbases, CMS glossary modules, and TMS term enforcement settings.
Term retirement. Deprecated terms retain their ID and record but receive a “retired” status with a documented reason and a pointer to the replacement term.
Terminology drift occurs mainly due to siloed decision-making. Running this workflow inside a central knowledge platform such as Confluence, with role-based editing permissions and templated term pages, keeps the process transparent when personnel rotate. Personnel rotation on long programmes like A400M or Boxer is not an edge case. It is a certainty.
Pro Tip: Set a hard SLA of five business days for SME validation responses. If the SLA is breached, escalate to the programme terminology authority automatically. Unreviewed terms silently block downstream translation work and create schedule risk.
Tool selection and IT infrastructure
The tool you choose constrains what your workflow can enforce. A useful framework for evaluating options sits on a spectrum from minimum viable to fully integrated.
Tool Type | Capabilities | Limitations | Best Fit |
Shared spreadsheet | Low cost, fast setup, version-exportable | No lifecycle management, no API, no QA enforcement | Programme initiation, small teams |
Standalone termbase (e.g., TBX-compatible) | Lifecycle status, TBX export, basic role access | Limited real-time CAT integration | Mid-scale programmes with CAT tooling |
CAT/TMS terminology module | In-editor term lookup, forbidden term flagging, QA checks | Vendor lock-in risk, limited cross-system API | Active translation phases |
Integrated TMS + API validation | Real-time enforcement, drift monitoring, audit logs | Higher implementation overhead | Full programme scale, multi-nation |
Regardless of tool tier, choose platforms supporting TBX export, approval workflows, and API access to maintain interoperability. Lock-in to a proprietary format is a governance risk on a ten-year programme.
Automated term validation matters at scale. Implementing real-time terminology validation APIs integrated with documentation build pipelines allows you to catch forbidden terms, casing violations, and deprecated usage before a document reaches review. Pre-commit hooks in documentation repositories flag terminology issues at the authoring stage, not during QA.
Pilot your terminology infrastructure on a single domain and one locale pair before scaling to all partner nations. Errors in the termbase architecture are far cheaper to fix at pilot stage than after 40,000 terms have been entered.
Pro Tip: Run a multilingual defense bid through your terminology tool as a stress test before programme go-live. Bid documents surface morphological, formality, and domain coverage gaps that internal test sets typically miss.
Quality assurance and audit compliance
AQAP 2110 audits do not accept “the team knows what the term means.” They require documented evidence that terminology was controlled, reviewed, and applied consistently. QA gates must be defined for every stage of the term lifecycle and for every document release.
Mandatory QA checks before any document reaches programme review should cover:
Forbidden term detection. Flag deprecated, unapproved, or programme-incorrect terms in the document body.
Approved term coverage. Confirm that all in-scope concepts use their approved programme term rather than a variant.
Casing and form consistency. Abbreviations, acronyms, and hyphenated forms must appear consistently.
Locale completeness. Every approved source-language term must have an approved equivalent in all programme languages before the source document is released for translation.
A termbase with metadata including domain, usage notes, and audit trail supports these checks at scale in a way that flat glossaries cannot. Terminology consistency reduces errors and improves audit outcomes in defence documentation when governance is aligned to ISO 17100, ISO 27001, and AQAP.
Track these KPIs across the programme to maintain visibility:
Terminology QA failure rate per document release
Term approval backlog (open requests older than SLA threshold)
Lookup rate per term (low lookup rates may indicate adoption gaps)
Deprecated term usage incidents per quarter
Audit trail records for every term must capture the approver identity, the approval date, the version of the programme standard referenced, and the rationale for any deviation from NATOTerm or NSO equivalents. This record is the evidence package for your AQAP 2110 compliance audit.
Common failure modes and how to avoid them
Most OCCAR terminology programmes do not fail because the wrong tool was chosen. They fail because governance was treated as a setup task rather than an ongoing programme discipline.
Siloed systems and lack of clear ownership are the most common root causes of terminology drift. When the French documentation team approves a term variant without informing the programme terminology authority, and the German team uses a different variant for the same concept, you have a consistency failure that will surface in audit or, worse, in a translated technical manual used in the field.
The mitigations are organizational before they are technical:
Assign a named owner for every term in the live termbase. Ownership must transfer explicitly when personnel rotate.
Schedule mandatory quarterly reviews of all approved terms against current programme configuration. Systems change. Terms must follow.
Build a glossary-first culture starting from programme initiation. A shared, accessible glossary embedded in project briefs and onboarding materials measurably improves quality and audit readiness.
Enforce the central termbase as the single source of truth. Contractor-specific glossaries that are not synchronized to the programme termbase are a drift source.
Terminology governance is not a translation function. It is a configuration management discipline. Programmes that assign it to translators without providing a governance framework will spend more time correcting inconsistencies than it would have cost to govern the process from the start.
Training matters as much as tooling. Authors, engineers, and project managers who create source documents must understand which terms are programme-approved and where to find them. Passive availability is not adoption.
My perspective on what actually works
I have seen terminology programmes that looked excellent in a kick-off presentation and were abandoned within six months. The pattern is consistent. A terminologist builds a well-structured termbase. The workflow is documented. Then the programme enters its heaviest execution phase, SMEs stop responding to validation requests within SLA, and the termbase freezes while documents keep moving. Within a year, translators are working from informal contractor glossaries because the official termbase is twelve months out of date.
What I have found to be the real differentiator is not the tool. It is whether terminology governance has a named, empowered owner with programme-level authority to hold up document releases when terminology compliance is not met. Without that authority, the workflow is advisory. Advisory workflows decay under schedule pressure.
The other lesson I keep returning to is that concept-centric termbases with stable IDs save programmes enormous rework during configuration changes. When a system is redesigned and ten component names change, a concept-centric termbase lets you update the approved term at the concept level and propagate the change to all language versions with a traceable audit record. A flat glossary forces manual updates across every document and every language, with no guarantee of completeness.
My advice to any documentation lead joining an OCCAR programme: spend the first month building the governance framework and the role structure before entering a single term. The termbase you build in month two will be far more defensible in audit and far more useful to your team than anything built without that foundation.
— Viestarts
How AD VERBUM supports OCCAR-grade terminology management
For programme managers who need terminology governance to meet AQAP 2110, ISO 17100, and ISO 27001 requirements, the quality of the language service partner matters as much as the internal framework. AD VERBUM’s AI+HUMAN hybrid translation workflow begins by ingesting your existing Translation Memories and Term Bases, constraining output to your approved programme terminology before any human review step begins. Subject-matter expert linguists with defence-sector credentials then review for technical accuracy, regulatory compliance, and locale-specific nuance. QA is aligned to ISO 17100 and ISO 18587.
AD VERBUM operates on EU-hosted private infrastructure, with no reliance on public cloud tooling for core processing. For OCCAR programmes handling controlled technical documentation, that data sovereignty posture matters. If you are building or auditing a defence localization program that needs to hold up under AQAP scrutiny, contact AD VERBUM to discuss terminology governance support.
FAQ
What is a termbase ID and why does it matter for OCCAR?
A termbase ID is a stable, language-independent identifier assigned to each concept in a termbase. It ensures that all language variants remain linked to the same concept, which is critical for traceability during AQAP 2110 audits.
How does NATOTerm relate to OCCAR terminology management?
NATOTerm provides NATO-standardized terms and definitions that serve as authoritative references for multinational defence programmes. OCCAR programme teams should map programme-specific terms against NATOTerm equivalents and document any approved deviations.
What is the TBX standard and which tools support it?
TBX (TermBase eXchange) is an open XML standard for exchanging termbase data between CAT tools, CMS platforms, and TMS systems. Most professional CAT and TMS platforms support TBX import and export.
How do you prevent terminology drift across partner nations?
Terminology drift is prevented by maintaining a single central termbase with role-based editing permissions, enforcing SLAs for term validation, running automated QA checks before document release, and scheduling quarterly reviews of all approved terms.
What records are needed for an AQAP 2110 terminology audit?
An AQAP 2110 audit requires documented evidence of term approval decisions, including the approver identity, approval date, version of the relevant standard, and rationale for any deviation from NATOTerm or NSO-authorized equivalents.
Recommended