Give AI wording proposals the glossary’s context and exceptions
A proposed AI terminology reviewer suggests contextual wording changes for a Project-to-Workspace UI rename. The maintained glossary defines the current UI label, effective release, and literal API exception project_id. With that entry, AI can propose “Open your Workspace” while preserving API tokens; writers and API owners check the patch before publishing.
See the business case- Business goal
- Reduce costs
- Business metric
- Content cost
The task and the failure point
For the same current-release source passages, AI must update a UI instruction while preserving the literal project_id API field. A concept entry gives the model scope and exception evidence that a preferred-label list lacks.
Terminology drift creates review cycles and translation ambiguity. Extraction can propose terms and find variants, but a governed entry must say what the concept means, where the preferred label applies, what legacy terms still mean, and who decides exceptions.
Open your
{ "project_id": "…" }The content repairGive the term entry an explicit scope: Workspace for the current UI; project_id unchanged in API references; historical Project labels retained for earlier releases. Route ambiguous mentions to the term owner.
AI proposal from a label pair alone
“Replace Project with Workspace,” including a proposed workspace_id token in the API reference. The label pair has not supplied the API contract exception.
AI proposal using the approved concept entry
UI patch: “Open your Project” → “Open your Workspace.” API snippet: {"project_id":"…"} unchanged. The proposal cites the UI scope and literal-token exception; writers and API owners inspect the diff and validate the example.
A comparison worth testing
Hold passages, release, AI model, prompt, and reviewers fixed. Compare proposals from the Project → Workspace label pair with those from the governed concept entry. Inspect UI patches, unchanged project_id tokens, historical mentions, and ambiguous cases; validate API examples before measuring review and localization effort.
The glossary entry below is an input to the AI patch proposal. Its UI scope permits the wording change, its API exception protects project_id, and its historical scope tells the model which Project mentions to leave for version-specific guidance.
What the content must carry
Term entry: Workspace
Concept: container for a team’s current UI work.
Preferred UI term: Workspace. Deprecated UI label: Project (before the rename).
Do not replace: API field project_id until the API contract changes.
Owner: product terminology council. Applies to: current UI release. Localization note: translate the concept consistently, retain literal API tokens.
From content work to content cost
The AI patch must survive contextual review and literal-token validation before writers publish it. Approved term adherence and Terminology rework rate test the corrected output; Content cost includes glossary maintenance, rejected proposals, and localization work.
How to measure it
Keep model, prompt, passage set, and effective release fixed while comparing glossary inputs. Save AI diffs and reviewer decisions, including protected API tokens and ambiguous contexts. Validate published examples and compare equivalent topic/language effort; a high scan score can still hide a wrong concept mapping.
Start with a bounded task
Pilot AI wording proposals on one UI rename spanning task docs and API examples. Approve the concept entry first; review diffs and validate literal tokens before updating localization instructions.
See the implementation steps Assess your AI readinessWhich product term keeps sending work back through review?
Intuitive Stack can help give AI wording proposals a scoped glossary entry and literal API exceptions, with reviewable patches and checked published examples.