Detect Terminology Drift

Terminology drift is insidious. Teams develop their own language organically, and by the time they need to collaborate, they've accumulated invisible translation barriers. One team's "deployment" is another's "release" is another's "promotion." These differences seem trivial until they cause a production incident.

Common drift patterns:

• Teams adopt vendor terminology differently
• Original terms evolve as understanding deepens
• New team members bring terminology from previous jobs
• Documentation uses different terms than conversation
• Technical precision varies by team culture </context>

Executive Summary

[2-3 sentences on the overall state of terminology alignment. How severe is the drift?]

Risk Level: [Low / Medium / High / Critical] Teams Analyzed: [List] Terms Reviewed: [Count] Conflicts Found: [Count]

Critical Conflicts (Immediate Attention)

Conflict 1: "[Term]" Has Multiple Meanings

Risk: [What could go wrong if this isn't resolved] Recommendation: [Standardize to X / Create explicit mapping / Needs discussion] Suggested Standard Definition: [If recommending standardization]

Conflict 2: Same Concept, Different Names

Concept: [What the underlying thing is]

Risk: [What could go wrong] Recommendation: [Which term to standardize on and why]

Acronym Inconsistencies

Term Equivalence Map

This table shows how concepts translate across teams:

Low-Risk Variations (Monitor Only)

These differences exist but don't currently cause confusion:

Recommended Glossary Updates

New Standard Terms

## [Term]
**Definition:** [Clear, canonical definition]
**Also Known As:** [Team-specific variants, if kept]
**Not To Be Confused With:** [Similar terms that mean different things]
**Examples:** [Concrete usage examples]

Cross-Reference Entries

## [Team-Specific Term]
**See:** [Canonical Term]
**Used By:** [Which team]
**Note:** [Any context on why this variant exists]

Action Items

1. [Highest priority term to standardize]

   • Owner: [Suggested—likely a tech lead or architect]
   • Action: [Specific next step]

2. [Second priority]

   • Owner: [Suggested]
   • Action: [Specific next step]

3. [Create/Update shared glossary]

   • Include: [List of terms that need documentation]
   • Location: [Where the glossary should live]

Analysis Notes

Confidence: [How confident I am in these findings] Limitations: [What I couldn't determine from the memory banks] Suggested Follow-Up: [Additional analysis that might help] </output-format>

NEVER:

• Flag differences that only exist in old/archived content
• Recommend standardization for terms with legitimate domain-specific meanings
• Assume one team's terminology is "correct" without justification
• Ignore context—the same word can legitimately mean different things in different domains

DO NOT:

• Create a conflict where none exists (minor wording variations aren't conflicts)
• Recommend renaming terms with high switching costs without acknowledging the cost
• Miss implicit definitions (terms used consistently but never explicitly defined)
• Overlook acronym collisions (same letters, different meanings)

ALWAYS:

• Quote actual usage from the memory banks
• Explain WHY a conflict matters (what could go wrong)
• Consider the cost of standardization vs. the cost of ambiguity
• Provide concrete recommendations, not just observations
• Flag cases where human judgment is needed

PRIORITIZE BY:

1. Cross-team integration points (where teams must communicate)
2. Customer-facing terminology (where external consistency matters)
3. Technical precision terms (where ambiguity causes bugs)
4. Internal convenience terms (lowest priority) </instructions>

Conflict: "Service" Has Multiple Meanings

Risk: When Platform says "the service is down," API Team might think the endpoint is unavailable while Support thinks the subscription tier has issues. During incidents, this ambiguity costs precious minutes. Recommendation: Standardize technical usage to "microservice" for Platform's meaning, "endpoint" for API Team's meaning, keep "service" for Support's customer-facing context.

❌ Bad conflict identification:

Conflict: Different Capitalization

Risk: Looks different. Recommendation: Pick one.

[This is pedantic—capitalization rarely causes real confusion. Don't waste attention on it.]

✅ Good equivalence mapping:

❌ Bad equivalence mapping:

[No context, no teams identified, no explanation of why this matters] </examples>3c:["$","$L44",null,{"content":"$45","frontMatter":{"name":"detect-terminology-drift","description":"Identify terminology inconsistencies across team memory banks"}}]