{"slug":"business/NAMING_FRAMEWORK","title":"IntegrateWise Naming Framework","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/NAMING_FRAMEWORK.mdx","bytes":7776,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n\n> **Tier C — Historical.** This document is a point-in-time snapshot preserved for reference. For current architecture, see [CANONICAL_PLATFORM_ARCHITECTURE.md](../architecture/CANONICAL_PLATFORM_ARCHITECTURE.md).\n\n## Three Naming Layers\n\nTo avoid coupling architecture to marketing, we distinguish between what changes rarely and what evolves frequently.\n\n### Layer 1: Architecture (Stable)\nThese names appear in code, APIs, documentation, and database schemas. They change rarely.\n\n| Concept | Purpose | Stability |\n|---------|---------|-----------|\n| **Spine** | Canonical operational data store | 🔒 Very stable |\n| **Gateway** | Request routing & context broker | 🔒 Very stable |\n| **Memory** | Continuity & knowledge persistence | 🔒 Very stable |\n| **Entity360** | Unified entity view | 🔒 Very stable |\n| **Governance** | Policy enforcement | 🔒 Very stable |\n| **Loader** | Data acquisition from connectors | 🔒 Very stable |\n| **Normalizer** | Data transformation to canonical schema | 🔒 Very stable |\n| **Bridge** | AI context mediation | 🔒 Very stable |\n| **Skills** | Reusable actions & capabilities | 🔒 Very stable |\n| **Connected Apps** | External integrations (in APIs/docs) | 🟡 Somewhat stable |\n\n### Layer 2: Capabilities (Mostly Stable)\nThese names appear in UI, marketing, documentation. They change occasionally (v1 → v2), but not within a release.\n\n| Level | Capability | Today | Alternative Names | Stability |\n|-------|-----------|-------|-------------------|-----------|\n| L1 | **Workbench** | Workspace / Dashboard / Hub | 🟡 Could change in v2 |\n| L2 | **Intelligence** | Insights / Signals / Recommendations | 🟡 Could change in v2 |\n| L3 | **Twin** | Assistant / AI / Copilot / Co-worker | 🟡 Likely to change |\n| L4 | **Memory** | Knowledge / Brain / Store | 🟡 Could change in v2 |\n| L5 | **Approvals** | Reviews / Governance / Policy | 🟡 Could change in v2 |\n| L6 | **Connected Apps** | Integrations / Connectors / Plugins | 🟡 Likely to change |\n| L7 | **Identity** | Auth / Access / Users | 🟡 Usually stable |\n\n### Layer 3: Product & Brand (Most Flexible)\nThese are product names and can change independently of the platform. Update freely as you learn from customers.\n\n| Product | Today | v1.1 | v2 | Enterprise | Notes |\n|---------|-------|------|----|-----------|----|\n| **AI Workspace** | AI Workspace | AI Workspace | IntegrateWise AI | IntegrateWise Copilot | Flagship application |\n| **Twin** | Twin | Assistant | Copilot | Co-Pilot | The AI entity |\n| **Sales Tool** | Sales Workbench | Sales Dashboard | Sales Copilot | Sales CoPilot | Role-based app |\n| **CS Tool** | CS Workbench | CS Dashboard | Success Assistant | Success Co-Pilot | Role-based app |\n| **Docs** | Wise Docs | Knowledge | Docs | Knowledge Hub | Documentation app |\n| **Ops** | Wise Ops | Operations | Ops Copilot | Ops CoPilot | Operations app |\n| **Branding** | Wise Branding | Brand Hub | Brand Central | Brand Studio | Branding app |\n| **ERMS** | Wise ERMS | People | HR | People Hub | HRIS app |\n\n---\n\n## Evolution Examples\n\n### Example 1: Renaming L3 (Twin) Without Code Changes\n\n**Today (v1.0):**\n```typescript\n// Architecture (code)\nconst response = await twinAgent.reason(input)\n\n// UI (marketing)\n\"Chat with your Twin\"\n```\n\n**Later (v1.2):**\n```typescript\n// Architecture (same code)\nconst response = await twinAgent.reason(input)\n\n// UI (new marketing)\n\"Chat with your Assistant\"\n```\n\nNo code changes. The architecture is decoupled from the marketing name.\n\n---\n\n### Example 2: Renaming L1 (Workbench)\n\n**Today (v1.0):**\n```typescript\n// Architecture (route params, state, etc.)\nconst workbench = useWorkbench()\n\n// UI (marketing)\n<h1>Your Workbench</h1>\n```\n\n**Later (v2):**\n```typescript\n// Architecture (same code)\nconst workbench = useWorkbench()\n\n// UI (new marketing)\n<h1>Your Workspace</h1>\n```\n\nUsers see \"Workspace,\" but internally it's still the same Workbench service.\n\n---\n\n### Example 3: Enterprise Branding\n\n**Standard Edition (v1.0):**\n```\n🤖 Twin\n```\n\n**Enterprise Edition:**\n```\n🤖 Co-Pilot\n```\n\nSame code path, different label based on subscription tier.\n\n---\n\n## Decision Tree\n\nWhen naming something new, ask:\n\n1. **Is it part of the platform infrastructure?** (Spine, Gateway, Memory, etc.)\n   - Use **stable architectural names**\n   - Appears in code, APIs, documentation\n   - Rarely changes\n\n2. **Is it a user-facing capability?** (Workbench, Intelligence, Twin, Memory, etc.)\n   - Use **capability names**\n   - Can evolve within major versions\n   - Changes on marketing feedback\n\n3. **Is it a product or branded experience?** (AI Workspace, Wise Docs, Sales Workbench, etc.)\n   - Use **product names**\n   - Most flexible, can change anytime\n   - Independent per product/tier\n\n---\n\n## API Versioning\n\nKeep architecture stable by versioning only the presentation layer.\n\n**Backend (Stable):**\n```\nGET /api/platform/spine/entities/{id}\nPOST /api/platform/memory/store\nGET /api/platform/intelligence/signals\n```\n\n**Frontend (Flexible):**\n```\n// v1.0\n\"Intelligence\" card\n\"Twin\" chat\n\"Workbench\" dashboard\n\n// v1.1 (same APIs)\n\"Insights\" card\n\"Assistant\" chat\n\"Dashboard\" view\n```\n\n---\n\n## Types of Name Changes\n\n### Never Do\n- Rename Spine, Gateway, Memory, Loader, Normalizer, Entity360 in the middle of a release (code instability)\n- Rename core platform concepts in APIs without versioning\n\n### Safe in Minor Release\n- Rename UI labels (Intelligence → Insights)\n- Rename product names (AI Workspace → AssistantWise)\n- Rename capability marketing names (Twin → Copilot)\n\n### Safe Between Major Versions\n- Reorganize layer definitions\n- Rename capabilities that appeared in v1 if there's a strong reason\n\n### Freeze Pattern\nFor each major version, create a NAMING_FREEZE document:\n```\n# IntegrateWise v2 Naming Freeze\n\nStable through v2.x:\n- Spine, Gateway, Memory, Loader, Normalizer\n- L1, L2, L3, L4 (layer definitions)\n- Entity360, Skills, Governance\n\nFlexible in v2:\n- \"Workbench\" → can become \"Dashboard\" or \"Hub\"\n- \"Twin\" → can become \"Assistant\" or \"Copilot\"\n- \"Wise Docs\" → can become \"Knowledge\" or \"Wiki\"\n```\n\n---\n\n## Implementation Guidance\n\n### In Code\n\n**Stable names (architecture):**\n```typescript\n// ✅ Use stable names in services, constants, APIs\nexport class SpineService {}\n```\n\n**Flexible names (UI):**\n```typescript\n// ✅ Use i18n or config for UI names\n  twin: \"Assistant\",  // Change this for rebranding\n  workbench: \"Dashboard\",\n  intelligence: \"Insights\",\n}\n<h1>{CAPABILITY_NAMES.twin}</h1>\n```\n\n### In Documentation\n\n**Architecture docs:** Use stable names\n- \"The Spine stores...\"\n- \"The Gateway routes...\"\n- \"Memory persists...\"\n\n**Product docs:** Use capability names\n- \"Your Workbench shows...\"\n- \"Intelligence alerts you to...\"\n- \"Twin helps you reason...\"\n\n**Marketing docs:** Use product/brand names\n- \"AI Workspace brings you...\"\n- \"Wise Docs organizes your...\"\n- \"Sales Workbench accelerates...\"\n\n---\n\n## Questions to Answer Before Launch\n\n1. Is \"Workbench\" the right name for L1? (Consider: Dashboard, Hub, Workspace, Center)\n2. Is \"Twin\" the right name for L3? (Consider: Assistant, AI, Copilot, Agent)\n3. Is \"Intelligence\" the right name for L2? (Consider: Insights, Signals, Recommendations, Awareness)\n4. Are \"Wise Docs,\" \"Wise Ops,\" \"Wise Branding,\" \"Wise ERMS\" the right product names?\n5. Should \"Connected Apps\" be called \"Integrations\" or \"Connectors\"?\n\n**Note:** These decisions can change in v1.1 without code changes, so don't block Release 1.0 on perfect naming.\n"}