Ubiquitous Language Implementation

This proposal addresses the terminology fragmentation that causes AI code generation failures. When different teams use different terms for the same concept, AI agents produce inconsistent code that requires manual correction. Establishing a ubiquitous language creates shared vocabulary that both humans and AI agents can rely on.

Key Insight: AI agents learn from code patterns. If the same concept has five different names across the codebase, AI will perpetuate that inconsistency. Ubiquitous language is not just documentation - it's a foundational requirement for reliable AI code generation.

Problem Statement

Current State: Terminology Chaos

Evidence from Cross-Team Feedback

Concept	Team A	Team B	Team C	AI Confusion
Camera device	`device`	`camera`	`channel`	AI mixes terms
User organization	`organization`	`tenant`	`account`	API inconsistency
Video segment	`clip`	`segment`	`recording`	Model mismatch
Device grouping	`site`	`location`	`group`	Navigation confusion
Alert notification	`alert`	`alarm`	`event`	Handler duplication

Real Examples

Backend Team:

"The API uses 'tenant' but the frontend uses 'organization'. AI generates API calls with wrong parameter names."

Mobile Team:

"iOS code calls it 'channel', Android calls it 'device', web calls it 'camera'. AI-generated code doesn't match the platform conventions."

Frontend Team:

"AI created a new RecordingList component when we already had ClipGallery because it didn't know they're the same concept."

The Cost of Inconsistency

Proposed Solution: Domain-Driven Ubiquitous Language

Target State

Ubiquitous Language Architecture

glossary/
├── CLAUDE.md                    # AI instructions for term usage
├── index.md                     # Master glossary overview
│
├── domains/
│   ├── device-management.md     # Device domain terms
│   ├── video-streaming.md       # Video domain terms
│   ├── user-identity.md         # User/Auth domain terms
│   ├── alerting.md              # Alert/Event domain terms
│   └── analytics.md             # Analytics domain terms
│
├── mappings/
│   ├── legacy-terms.md          # Deprecated term -> canonical term
│   ├── platform-terms.md        # Platform-specific variations
│   └── external-terms.md        # Third-party API term mappings
│
└── schemas/
    ├── term-schema.json         # Term definition schema
    └── validation.js            # Glossary validation script

Term Definition Standard

Term Documentation Template

markdown

# Device

## Definition

A physical or virtual camera, sensor, or recording equipment that captures video or audio data and transmits it to the platform.

## Canonical Name

- **Code**: `Device`
- **API**: `device`
- **UI**: "Device"

## Domain

Device Management

## Aliases (Deprecated)

| Alias | Context | Migration |
|-------|---------|-----------|
| `camera` | Legacy iOS code | Replace with `device` |
| `channel` | Legacy Android | Replace with `device` |
| `equipment` | Old API v1 | API deprecated |

## Related Terms

- **DeviceGroup**: Collection of devices at a location
- **DeviceStatus**: Online/offline/error state
- **DeviceCapability**: Features supported by device

## Platform Implementations

| Platform | Class/Type | File |
|----------|-----------|------|
| Web | `Device` interface | `types/device.ts` |
| iOS | `Device` struct | `Models/Device.swift` |
| Android | `Device` data class | `models/Device.kt` |
| Backend | `Device` entity | `domain/device.go` |

## API Usage

```json
{
  "device": {
    "id": "dev-123",
    "name": "Front Door Camera",
    "status": "online"
  }
}

UI Display

List item: "Front Door Camera"
Status badge: "Online"
Error message: "Device offline"

AI Guidelines

@ai-hint Always use Device for camera/sensor entities. Never use camera, channel, or equipment. @ai-hint Use DeviceStatus for state, not status or state alone. @ai-hint When generating device-related code, check this glossary for correct naming.



## Domain Glossary Structure

### Domain: Device Management

```markdown
# Device Management Domain

## Core Entities

| Term | Definition | Code Name |
|------|-----------|-----------|
| **Device** | Physical/virtual recording equipment | `Device` |
| **DeviceGroup** | Logical grouping of devices | `DeviceGroup` |
| **DeviceStatus** | Current operational state | `DeviceStatus` |
| **DeviceCapability** | Supported features | `DeviceCapability` |
| **DeviceConfiguration** | Settings and parameters | `DeviceConfiguration` |

## Status Values

| Value | Meaning | UI Display |
|-------|---------|------------|
| `online` | Device connected and operational | "Online" (green) |
| `offline` | Device not responding | "Offline" (gray) |
| `error` | Device reporting error condition | "Error" (red) |
| `maintenance` | Device in maintenance mode | "Maintenance" (yellow) |

## Operations

| Operation | API Verb | Description |
|-----------|----------|-------------|
| Register | `POST /devices` | Add new device to platform |
| Configure | `PATCH /devices/{id}` | Update device settings |
| Restart | `POST /devices/{id}/restart` | Reboot device |
| Decommission | `DELETE /devices/{id}` | Remove device from platform |

## Anti-Patterns

| Don't Use | Use Instead | Reason |
|-----------|-------------|--------|
| `camera` | `device` | Camera is a device type, not the entity |
| `channel` | `device` | Legacy term from old system |
| `equipment` | `device` | Too generic |
| `unit` | `device` | Ambiguous |

Domain: Video Streaming

markdown

# Video Streaming Domain

## Core Entities

| Term | Definition | Code Name |
|------|-----------|-----------|
| **Stream** | Live video transmission | `Stream` |
| **Recording** | Stored video segment | `Recording` |
| **Playback** | Video viewing session | `Playback` |
| **Thumbnail** | Preview image from video | `Thumbnail` |

## Deprecated Terms

| Deprecated | Canonical | Migration Path |
|------------|-----------|----------------|
| `clip` | `Recording` | Rename in new code |
| `segment` | `Recording` | Update variable names |
| `video` | `Recording` or `Stream` | Choose based on context |
| `feed` | `Stream` | Replace in UI text |

Legacy Term Migration

Migration Strategy

Legacy Term Mapping Table

markdown

# Legacy Term Mappings

This document maps deprecated terms to their canonical replacements.

## Severity Levels

- **Critical**: Causes runtime errors if not fixed
- **High**: Causes AI confusion frequently
- **Medium**: Occasional AI mistakes
- **Low**: Cosmetic inconsistency

## Mappings

| Legacy Term | Canonical Term | Severity | Migration Status |
|-------------|---------------|----------|------------------|
| `camera` | `Device` | High | In Progress |
| `channel` | `Device` | High | In Progress |
| `tenant` | `Organization` | Critical | Complete |
| `clip` | `Recording` | Medium | Planned |
| `segment` | `Recording` | Medium | Planned |
| `alarm` | `Alert` | High | In Progress |
| `site` | `DeviceGroup` | Medium | Planned |
| `location` | `DeviceGroup` | Medium | Planned |

## Code Examples

### Before (Legacy)

```typescript
// Multiple terms for same concept
interface Camera {
  cameraId: string;
  channelName: string;
}

function getChannelStatus(channelId: string): CameraStatus {
  // ...
}

After (Ubiquitous Language)

typescript

// Single canonical term
interface Device {
  deviceId: string;
  deviceName: string;
}

function getDeviceStatus(deviceId: string): DeviceStatus {
  // ...
}



## CLAUDE.md Integration

Add to project CLAUDE.md:

```markdown
## Ubiquitous Language

### Terminology Standards
- **Always check** `glossary/` before using domain terms
- **Use canonical names** from term definitions
- **Never use deprecated terms** listed in `glossary/mappings/legacy-terms.md`

### Before Writing Code
1. Identify domain terms in the requirement
2. Look up canonical names in `glossary/domains/`
3. Check for deprecated aliases to avoid
4. Use consistent naming across all layers (API, UI, code)

### Term Usage Rules

| Layer | Convention | Example |
|-------|-----------|---------|
| Variable/Property | camelCase | `deviceStatus` |
| Class/Type | PascalCase | `DeviceStatus` |
| API Parameter | snake_case | `device_status` |
| UI Label | Title Case | "Device Status" |
| Database Column | snake_case | `device_status` |

### Prohibited Practices
- Using different terms for same concept across files
- Creating new terms without adding to glossary
- Using legacy terms (see `legacy-terms.md`)
- Mixing naming conventions within same layer

### When Uncertain
If you encounter a term not in the glossary:
1. Search codebase for existing usage
2. Check if it's a new concept needing definition
3. Ask for clarification before proceeding
4. Do not invent new terms

Implementation Roadmap

Phase 1: Discovery

Goal: Identify terminology inconsistencies across codebase.

Deliverables:

[ ] Term inventory spreadsheet
[ ] Inconsistency report by domain
[ ] Proposed canonical term list

Phase 2: Documentation

Goal: Create glossary with term definitions.

Deliverables:

[ ] Glossary directory structure
[ ] Core domain term definitions (Device, User, Video)
[ ] Legacy term mapping table
[ ] CLAUDE.md terminology guidelines

Phase 3: Tooling

Goal: Build validation and enforcement tools.

Deliverables:

[ ] Term validation script
[ ] Pre-commit hook for term checking
[ ] IDE snippets for canonical terms
[ ] AI context file generation

Phase 4: Migration

Goal: Update codebase to use canonical terms.

Deliverables:

[ ] Migration scripts for each domain
[ ] Updated API documentation
[ ] Refactored type definitions
[ ] Updated UI strings

Phase 5: Enforcement

Goal: Prevent regression to inconsistent terminology.

Deliverables:

[ ] CI/CD term validation
[ ] PR template with terminology checklist
[ ] New developer onboarding guide
[ ] Quarterly glossary review process

Validation Tooling

Term Validation Script

javascript

// validate-terms.js
const glossary = require('./glossary/schemas/terms.json');
const deprecated = require('./glossary/mappings/legacy-terms.json');

function validateFile(filePath, content) {
  const issues = [];

  // Check for deprecated terms
  for (const term of deprecated) {
    const regex = new RegExp(`\\b${term.legacy}\\b`, 'gi');
    const matches = content.match(regex);
    if (matches) {
      issues.push({
        file: filePath,
        term: term.legacy,
        canonical: term.canonical,
        severity: term.severity,
        count: matches.length
      });
    }
  }

  return issues;
}

// Run as pre-commit hook or CI step

Pre-commit Hook Configuration

yaml

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: validate-terms
        name: Validate Terminology
        entry: node scripts/validate-terms.js
        language: node
        types: [javascript, typescript, markdown]
        pass_filenames: true

Cross-Platform Term Mapping

Platform Naming Conventions

Concept	Web (TS)	iOS (Swift)	Android (Kotlin)	Backend (Go)
Device entity	`Device`	`Device`	`Device`	`Device`
Device list	`DeviceList`	`DeviceListView`	`DeviceListScreen`	N/A
Get device	`getDevice()`	`fetchDevice()`	`getDevice()`	`GetDevice()`
Device ID param	`deviceId`	`deviceId`	`deviceId`	`deviceID`

API to Code Mapping

markdown

# API to Code Term Mapping

When translating between API and code:

| API (snake_case) | Code (camelCase) | Type (PascalCase) |
|------------------|------------------|-------------------|
| `device_id` | `deviceId` | `DeviceId` |
| `device_status` | `deviceStatus` | `DeviceStatus` |
| `recording_start_time` | `recordingStartTime` | `RecordingStartTime` |
| `organization_name` | `organizationName` | `OrganizationName` |

## AI Usage

When generating code that interfaces with APIs:
1. Use snake_case for API parameters
2. Use camelCase for internal code
3. Type definitions use PascalCase
4. Never mix conventions within same layer

Stakeholder Terminology Coordination

Terminology fragmentation happens at multiple boundaries - not just between engineering teams, but across the entire value chain from customer to AI agent.

The Translation Chain Problem

Each boundary creates translation opportunities where meaning gets lost or distorted.

Stakeholder Term Usage Patterns

Stakeholder	Primary Concern	Typical Term Usage
Customer	Business outcome	Domain-specific jargon, varies by industry
Sales/Business	Deal closure	Customer-facing terms, marketing language
PM	Feature definition	Mix of customer and technical terms
Engineering	Implementation	Technical precision, code naming
AI Agent	Pattern matching	Whatever exists in codebase

Multi-Stakeholder Term Definition

Extend term definitions to include all stakeholder perspectives:

markdown

# Device (canonical)

## Definition
Physical or virtual equipment that captures and transmits media data.

## Stakeholder Terminology

| Context | Term | Notes |
|---------|------|-------|
| **Customer (TW)** | 攝影機、監控設備 | Use in contracts, support |
| **Customer (EN)** | Camera, Surveillance Device | Marketing materials |
| **Sales/Business** | 設備、裝置 | Proposals, quotes |
| **PM/PRD** | Device | Requirements documents |
| **Engineering** | `Device` | Code, API, database |
| **UI Display (TW)** | 設備 | Localized strings |
| **UI Display (EN)** | Device | Localized strings |

## Translation Rules

- PRD mentions "攝影機" -> Engineering uses `Device`
- Customer says "監控設備" -> PM documents as "Device"
- API returns `device` -> UI displays "設備"

Coordination Mechanisms

1. Pre-PRD Term Alignment

Before writing requirements, align terminology:

markdown

## Pre-PRD Term Checklist

Before writing requirements:
1. [ ] List all domain concepts mentioned by customer/business
2. [ ] Check glossary for existing canonical terms
3. [ ] If new concept, propose term with all stakeholder mappings
4. [ ] Get PM + Engineering sign-off on terminology

2. PRD Template with Term Section

Every PRD includes explicit term mapping:

markdown

## Terminology

| This PRD Uses | Canonical Term | Customer Says | Code Uses |
|---------------|----------------|---------------|-----------|
| 即時影像 | LiveStream | 監控畫面 | `LiveStream` |
| 設備群組 | DeviceGroup | 站點 | `DeviceGroup` |

3. Mob Elaboration Term Resolution

During AI-DLC Mob Elaboration sessions, resolve terminology conflicts in real-time:

markdown

## Term Resolution Protocol

When terminology conflict arises:
1. PM states customer/business term
2. Engineering proposes canonical term
3. AI validates against existing glossary
4. Group decides on mapping
5. Glossary updated in same session

Governance Roles

Role	Responsibility
PM Lead	Customer/business term collection
Tech Lead	Engineering term standardization
UX Lead	UI display term consistency
Glossary Owner	Conflict resolution, maintenance

Workflow Integration

Key Insight

The goal is to maintain explicit mappings so:

Customer can use familiar terms
Business can speak customer language
PM can bridge both worlds in documentation
Engineering has unambiguous code naming
AI can translate between layers correctly

Cross-Product Terminology Coordination

When an organization has multiple products, terminology fragmentation becomes even more challenging as products evolve independently and develop their own "dialects."

The Cross-Product Problem

Impact of Cross-Product Inconsistency

Scenario	Impact
Customer uses both Product A and B	Confused by different terms for same thing
Backend API serves multiple products	Inconsistent parameter naming
Shared component library	Components named differently per product
AI agent works across products	Generates incompatible code
New product development	Reinvents terminology instead of reusing
M&A integration	Two codebases with conflicting terms

Federated Glossary Architecture

glossary/
├── CLAUDE.md
├── index.md
│
├── core/                        # Cross-product canonical terms
│   ├── entities.md              # Device, User, Organization
│   ├── operations.md            # CRUD verbs, state transitions
│   └── status.md                # online, offline, error
│
├── products/
│   ├── vsaas/
│   │   ├── _product.md          # Product-specific overview
│   │   ├── terms.md             # VSaaS-specific terms
│   │   └── mappings.md          # Maps to core terms
│   │
│   ├── vortex/
│   │   ├── _product.md
│   │   ├── terms.md
│   │   └── mappings.md
│   │
│   └── edge-ai/
│       ├── _product.md
│       ├── terms.md
│       └── mappings.md
│
└── cross-product/
    ├── entity-mapping.md        # Same concept across products
    ├── api-contracts.md         # Shared API terminology
    └── integration-terms.md     # Terms for product integration

Cross-Product Entity Mapping

markdown

# Cross-Product Entity Mapping

## Device Concept

The concept of "recording equipment" exists in all products but uses different names.

| Core Term | VSaaS | Vortex | Edge AI | Definition |
|-----------|-------|--------|---------|------------|
| `Device` | Device | Channel | Camera | Physical/virtual recording equipment |
| `DeviceGroup` | Site | Location | Zone | Logical grouping of devices |
| `Recording` | Recording | Clip | Event | Stored video segment |
| `Stream` | LiveView | Feed | Stream | Real-time video transmission |

## Canonical Term Selection Criteria

1. **Most generic** - Applies to all products
2. **Most established** - Used in oldest/largest product
3. **Most precise** - Clearest technical meaning
4. **Least ambiguous** - No conflicting meanings

Integration Patterns

Pattern 1: Shared Backend API

markdown

## API Terminology Standard

When building APIs that serve multiple products:

### Request/Response
- Always use **core canonical terms** in API contracts
- Products transform at their boundary

json

// API Response (canonical)
{
  "device": {
    "deviceId": "dev-123",
    "status": "online"
  }
}

typescript

// VSaaS Frontend (no transform needed)
device.deviceId

// Vortex Frontend (transforms at API client)
channel.channelId  // mapped from device.deviceId

// Edge AI Frontend (transforms at API client)
camera.cameraId    // mapped from device.deviceId

Pattern 2: Product Mapping Layer

Each product maintains a thin mapping layer:

typescript

// vortex/api/mappers/device.ts
export function toChannel(device: CoreDevice): VortexChannel {
  return {
    channelId: device.deviceId,
    channelName: device.deviceName,
    channelStatus: device.status,
  };
}

Pattern 3: Shared Component Library

typescript

// @company/ui-core (canonical)
export { DeviceCard } from './DeviceCard';
export { DeviceList } from './DeviceList';

// @company/ui-vsaas (re-exports as-is)
export { DeviceCard, DeviceList } from '@company/ui-core';

// @company/ui-vortex (re-exports with aliases)
export { DeviceCard as ChannelCard } from '@company/ui-core';
export { DeviceList as ChannelList } from '@company/ui-core';

// @company/ui-edge-ai (re-exports with aliases)
export { DeviceCard as CameraCard } from '@company/ui-core';
export { DeviceList as CameraList } from '@company/ui-core';

Cross-Product Governance

Term Promotion Process

When a product-specific term should become a core term:

markdown

## Criteria for Promotion

1. Used by 2+ products
2. Represents shared business concept
3. No existing core term covers it
4. Stable definition (6+ months unchanged)

## Process

1. Product team proposes term promotion
2. Core Glossary Team reviews
3. Other product teams assess impact
4. Define canonical form
5. Create migration plan for adopting products
6. Update all CLAUDE.md files

CLAUDE.md for Multi-Product Context

markdown

## Cross-Product Terminology

### When Working on [Product Name]

This product uses these term mappings:

| This Product | Core Term | Other Products |
|--------------|-----------|----------------|
| Channel | Device | VSaaS: Device, Edge AI: Camera |
| Location | DeviceGroup | VSaaS: Site, Edge AI: Zone |
| Clip | Recording | VSaaS: Recording, Edge AI: Event |

### Cross-Product Code Guidelines

1. **Shared libraries**: Always use core canonical terms
2. **Product code**: May use product-specific terms
3. **API boundaries**: Transform at product's API client layer
4. **Database**: Use core terms for shared tables, product terms for product-specific

### When Uncertain

1. Check `glossary/cross-product/entity-mapping.md`
2. If concept exists in another product, use core term
3. If truly new concept, propose to Core Glossary Team

Success Metrics

Metric	Before	Target	How to Measure
Term consistency	~60%	>95%	Audit for term variations
AI naming accuracy	~70%	>90%	Track AI-generated code reviews
Deprecated term usage	High	Near zero	grep for deprecated terms
Cross-platform alignment	Low	High	Compare naming across platforms
Onboarding clarity	Days	Hours	New dev productivity survey

Anti-Patterns to Avoid

1. Glossary as Afterthought

Problem: Creating glossary but not enforcing usage.

Solution: Integrate validation into CI/CD, make it a PR checklist item.

2. Over-Engineering Terms

Problem: Creating overly specific terms that nobody uses naturally.

Solution: Terms should match how developers actually talk about concepts.

3. Ignoring Platform Conventions

Problem: Forcing identical naming across platforms that have different conventions.

Solution: Define concept equivalence while respecting platform idioms.

4. Static Glossary

Problem: Glossary becomes outdated as codebase evolves.

Solution: Quarterly review process, glossary updates part of feature work.

5. Translation Without Context

Problem: Directly translating terms without considering domain meaning.

Solution: Focus on concept alignment, not literal translation.

Quick Reference Card

For AI-Generated Code

markdown

## Terminology Quick Check

Before generating code:
1. [ ] Domain terms match glossary?
2. [ ] No deprecated terms used?
3. [ ] Naming convention matches layer?
4. [ ] Cross-platform terms aligned?

Common Corrections:
- `camera` -> `Device`
- `tenant` -> `Organization`
- `clip` -> `Recording`
- `alarm` -> `Alert`
- `site` -> `DeviceGroup`

C1: Context Engineering Competency - Terminology as context foundation

Related: Continuous Context Cleanup | Design System | Back: Proposals Overview

References

Domain-Driven Design - Eric Evans' foundational work on ubiquitous language
RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels
Claude Code Documentation - Official documentation for CLAUDE.md AI guidance files

Ubiquitous Language Implementation ​

Problem Statement ​

Current State: Terminology Chaos ​

Evidence from Cross-Team Feedback ​

Real Examples ​

The Cost of Inconsistency ​

Proposed Solution: Domain-Driven Ubiquitous Language ​

Target State ​

Ubiquitous Language Architecture ​

Term Definition Standard ​

Term Documentation Template ​

UI Display ​

AI Guidelines ​

Domain: Video Streaming ​

Legacy Term Migration ​

Migration Strategy ​

Legacy Term Mapping Table ​

After (Ubiquitous Language) ​

Implementation Roadmap ​

Phase 1: Discovery ​

Phase 2: Documentation ​

Phase 3: Tooling ​

Phase 4: Migration ​

Phase 5: Enforcement ​

Validation Tooling ​

Term Validation Script ​

Pre-commit Hook Configuration ​

Cross-Platform Term Mapping ​

Platform Naming Conventions ​

API to Code Mapping ​

Stakeholder Terminology Coordination ​

The Translation Chain Problem ​

Stakeholder Term Usage Patterns ​

Multi-Stakeholder Term Definition ​

Coordination Mechanisms ​

1. Pre-PRD Term Alignment ​

2. PRD Template with Term Section ​

3. Mob Elaboration Term Resolution ​

Governance Roles ​

Workflow Integration ​

Key Insight ​

Cross-Product Terminology Coordination ​

The Cross-Product Problem ​

Impact of Cross-Product Inconsistency ​

Federated Glossary Architecture ​

Cross-Product Entity Mapping ​

Integration Patterns ​

Pattern 1: Shared Backend API ​

Pattern 2: Product Mapping Layer ​

Pattern 3: Shared Component Library ​

Cross-Product Governance ​

Term Promotion Process ​

CLAUDE.md for Multi-Product Context ​

Success Metrics ​

Anti-Patterns to Avoid ​

1. Glossary as Afterthought ​

2. Over-Engineering Terms ​

3. Ignoring Platform Conventions ​

4. Static Glossary ​

5. Translation Without Context ​

Quick Reference Card ​

For AI-Generated Code ​

Related Principles ​

References ​

Ubiquitous Language Implementation

Problem Statement

Current State: Terminology Chaos

Evidence from Cross-Team Feedback

Real Examples

The Cost of Inconsistency

Proposed Solution: Domain-Driven Ubiquitous Language

Target State

Ubiquitous Language Architecture

Term Definition Standard

Term Documentation Template

UI Display

AI Guidelines

Domain: Video Streaming

Legacy Term Migration

Migration Strategy

Legacy Term Mapping Table

After (Ubiquitous Language)

Implementation Roadmap

Phase 1: Discovery

Phase 2: Documentation

Phase 3: Tooling

Phase 4: Migration

Phase 5: Enforcement

Validation Tooling

Term Validation Script

Pre-commit Hook Configuration

Cross-Platform Term Mapping

Platform Naming Conventions

API to Code Mapping

Stakeholder Terminology Coordination

The Translation Chain Problem

Stakeholder Term Usage Patterns

Multi-Stakeholder Term Definition

Coordination Mechanisms

1. Pre-PRD Term Alignment

2. PRD Template with Term Section

3. Mob Elaboration Term Resolution

Governance Roles

Workflow Integration

Key Insight

Cross-Product Terminology Coordination

The Cross-Product Problem

Impact of Cross-Product Inconsistency

Federated Glossary Architecture

Cross-Product Entity Mapping

Integration Patterns

Pattern 1: Shared Backend API

Pattern 2: Product Mapping Layer

Pattern 3: Shared Component Library

Cross-Product Governance

Term Promotion Process

CLAUDE.md for Multi-Product Context

Success Metrics

Anti-Patterns to Avoid

1. Glossary as Afterthought

2. Over-Engineering Terms

3. Ignoring Platform Conventions

4. Static Glossary

5. Translation Without Context

Quick Reference Card

For AI-Generated Code

Related Principles

References