{"slug":"architecture/CAPABILITY_RESOLVER_PATTERN","title":"Selective Backend Architecture: Capability Resolver Pattern","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/CAPABILITY_RESOLVER_PATTERN.mdx","bytes":14241,"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**Status:** ✅ ARCHITECTURAL ENHANCEMENT  \n**Date:** June 27, 2026  \n**Motivation:** \"Backend is capable of everything. Don't make everything follow everything.\"  \n\n---\n\n## THE PROBLEM\n\nTraditional platform architecture creates tight coupling:\n\n```\nFrontend\n    ↓\nEverything\n    ↓\nBackend\n```\n\nResult: Every UI depends on every service. Eventually everything breaks when you change anything.\n\n---\n\n## THE SOLUTION: Capability Resolver Pattern\n\n```\nFrontend\n    ↓\nFeature Manifest (What do I need?)\n    ↓\nCapability Resolver (Can you provide it?)\n    ↓\nProjection Registry (How do I show it?)\n    ↓\nSelected Platform Capabilities\n    ↓\nSpine + Governance (Centralized auth, data access, audit)\n```\n\n**Key Innovation:** Each frontend enters the platform at different depths based on its needs.\n\n---\n\n## FIVE DIFFERENT FRONTENDS, FIVE DIFFERENT NEEDS\n\n### 1. Brainstorming Workspace (Human Layer)\n\n**What it needs:**\n```\nMemory ─→ Save ideas\nEntity360 ─→ Understand context\nChat ─→ Talk to AI\nSearch ─→ Find related thoughts\nTasks ─→ Create action items\n```\n\n**What it doesn't need:**\n- MCP (not building integrations)\n- ADK (not developing agents)\n- Workflow runtime (not orchestrating)\n- Prediction engine (not forecasting)\n- Developer tools (not debugging)\n\n**Gateway calls:**\n```\nPOST   /api/v1/memory/save\nPOST   /api/v1/memory/query\nGET    /api/v1/entity/account/123\nPOST   /api/v1/chat/message\nPOST   /api/v1/tasks\n```\n\n**Layers loaded:** Memory, Context, Chat, Search  \n**Excluded layers:** 8 others  \n**Efficiency:** 35% of full platform\n\n---\n\n### 2. Customer Success Platform\n\n**What it needs:**\n```\nEntity360 ─→ Customer context\nSignals ─→ Risk detection\nInsights ─→ AI recommendations\nTimeline ─→ Event history\nRenewal ─→ Forecast outcomes\nHealth Score ─→ Account health\nApprovals ─→ Workflow approvals\n```\n\n**What it doesn't need:**\n- MCP (no external data integration needed)\n- ADK/Workflows (no automation building)\n- Developer console (not debugging)\n- Schema discovery (not exploring data)\n- Executive metrics (not dashboards)\n\n**Gateway calls:**\n```\nGET    /api/v1/entity/:type/:id\nPOST   /api/v1/insights/query\nPOST   /api/v1/spine/query (timeline)\nPOST   /api/v1/proposals (approvals)\nPOST   /api/v1/tasks\n```\n\n**Layers loaded:** Entity, Signals, Governance, Continuity Bridge  \n**Excluded layers:** 10 others  \n**Efficiency:** 45% of full platform\n\n---\n\n### 3. Developer Console\n\n**What it needs:**\n```\nMCP ─→ 200+ data sources\nADK ─→ Build agents\nWorkflows ─→ Orchestrate tasks\nRegistry ─→ Discover capabilities\nLogs ─→ Debug execution\nSchema Discovery ─→ Understand models\n```\n\n**What it doesn't need:**\n- Customer data (not a CSM)\n- Customer insights (not relevant)\n- Business forecasting (not analyzing)\n- Executive metrics (not reporting)\n- Brainstorm ideas (not ideating)\n\n**Gateway calls:**\n```\nGET    /api/v1/capabilities\nPOST   /api/v1/capabilities/:id/execute\nGET    /api/v1/connectors\nPOST   /api/v1/spine/query (logs)\n```\n\n**Layers loaded:** Runtime, Registry, Logs, Continuity Bridge  \n**Excluded layers:** 10 others  \n**Efficiency:** 40% of full platform\n\n---\n\n### 4. Executive Dashboard\n\n**What it needs:**\n```\nMetrics ─→ KPIs\nGoals ─→ Business objectives\nInsights ─→ AI analysis\nPredictions ─→ Forecasts\nRevenue ─→ Financial metrics\nPerformance ─→ Team metrics\nApprovals ─→ Strategic decisions\n```\n\n**What it doesn't need:**\n- MCP (not integrating)\n- Developer tools (not coding)\n- Technical logs (not debugging)\n- Brainstorm ideas (not ideating)\n- Customer details (not managing)\n\n**Gateway calls:**\n```\nPOST   /api/v1/insights/query\nGET    /api/v1/proposals/:id\nPOST   /api/v1/entity/search (aggregate metrics)\n```\n\n**Layers loaded:** Insights, Metrics, Governance  \n**Excluded layers:** 12 others  \n**Efficiency:** 25% of full platform (lightweight!)\n\n---\n\n### 5. AI Twin (Full Access)\n\n**What it needs:** Everything\n\n```\nMemory ─→ Complete memory\nEntity360 ─→ Full context\nChat ─→ Conversation\nMCP ─→ All sources\nADK ─→ Agent development\nWorkflows ─→ Orchestration\nGovernance ─→ Approvals\nSignals ─→ Pattern detection\n+ Everything else\n```\n\n**Gateway calls:** All 30 endpoints  \n**Layers loaded:** All 15 layers  \n**Efficiency:** 100% of full platform\n\n---\n\n## HOW IT WORKS\n\n### Step 1: Frontend Declares Its Manifest\n\n**Brainstorming workspace:**\n```yaml\nfrontendId: brainstorming\ncapabilities:\n  - memory\n  - entity360\n  - chat\n  - search\n  - tasks\nprojections:\n  - brainstorm-workbench\n  - memory-browser\n```\n\n**Customer Success:**\n```yaml\nfrontendId: customer-success\ncapabilities:\n  - entity360\n  - signals\n  - insights\n  - timeline\n  - renewal\n  - health-score\n  - approvals\n  - tasks\nprojections:\n  - account-health\n  - renewal-forecast\n```\n\n### Step 2: Capability Resolver Validates\n\n```typescript\n// Frontend makes first call\nPOST /api/v1/resolve-capabilities\n{\n  frontendType: 'customer-success',\n  userId: 'user-123'\n}\n\n// Resolver responds with:\n{\n  frontendType: 'customer-success',\n  capabilities: [\n    {\n      name: 'entity360',\n      available: true,\n      layers: ['entity', 'context'],\n      gateway_endpoints: [\n        'GET /api/v1/entity/:type/:id',\n        'POST /api/v1/entity/search'\n      ]\n    },\n    // ...more capabilities\n  ],\n  layers: {\n    required: ['entity', 'signals', 'governance'],\n    total: 3\n  },\n  rateLimit: {\n    perSecond: 100,\n    globalQuota: 360000 // per hour\n  }\n}\n```\n\n### Step 3: Projection Registry Renders UI\n\n```typescript\n// Frontend asks how to render\nPOST /api/v1/projections/render\n{\n  projectionId: 'account-health',\n  userId: 'user-123'\n}\n\n// Registry responds with:\n{\n  id: 'account-health',\n  name: 'Account Health Dashboard',\n  capabilities: ['entity360', 'signals', 'health-score'],\n  navigation: [\n    { label: 'Health', route: '/health' },\n    { label: 'Signals', route: '/signals' },\n    { label: 'Timeline', route: '/timeline' }\n  ],\n  widgets: [\n    {\n      id: 'health-card',\n      component: 'HealthCard',\n      capabilities: ['health-score']\n    },\n    // ...more widgets\n  ]\n}\n```\n\n### Step 4: Frontend Only Loads What It Needs\n\n```typescript\n// Customer Success app\n\nconst client = new GatewayClient({\n  url: 'https://integratewise-gateway.workers.dev',\n  manifest: 'customer-success' // Only these capabilities\n})\n\n// Can call these:\nawait client.entity360.get('account-123')\nawait client.signals.query({ scope: 'renewal_risk' })\nawait client.approvals.create({ ... })\n\n// Cannot call these (blocked):\nawait client.mcp.executeConnector() // Error: Not in manifest\nawait client.adk.testAgent() // Error: Not in manifest\nawait client.metrics.getKPI() // Error: Not in manifest\n```\n\n### Step 5: Platform Enforces Access\n\nEverything still goes through:\n- ✅ **Spine:** Central audit log (who did what)\n- ✅ **Governance:** Permission checks (are you allowed?)\n- ✅ **Auth:** Session validation (are you logged in?)\n\n**Different frontends, different paths, same foundation.**\n\n---\n\n## ARCHITECTURE DIAGRAM\n\n```\n┌────────────────────────────────────────────────────────────┐\n│                  FRONTENDS (5 types)                       │\n├─────────────────┬──────────────────┬──────────────────┬────┤\n│ Brainstorming   │ Customer Success │ Developer        │ ... │\n└────────┬────────┴────────┬─────────┴────────┬────────┴────┘\n         │                 │                  │\n    Manifest          Manifest           Manifest\n         │                 │                  │\n         ▼                 ▼                  ▼\n   ┌──────────────────────────────────────────────────┐\n   │    Capability Resolver Service                   │\n   │                                                  │\n   │  ✓ Validates capabilities                        │\n   │  ✓ Resolves dependencies                         │\n   │  ✓ Calculates rate limits                        │\n   │  ✓ Returns allowed endpoints                     │\n   └─────────────────┬────────────────────────────────┘\n                     │\n         ┌───────────┼───────────┐\n         │           │           │\n         ▼           ▼           ▼\n    Memory      Entity360    Signals\n    \n         Gateway (30 endpoints)\n    ═════════════════════════════════\n    \n    ┌─────────────────────────────────┐\n    │  Spine (Audit Log)              │\n    │  Governance (Permissions)       │\n    │  Auth (Session Check)           │\n    └─────────────────────────────────┘\n```\n\n---\n\n## EFFICIENCY METRICS\n\n| Frontend | Layers Used | % of Platform | Typical Load | Impact |\n|----------|------------|--------|-----|--------|\n| Brainstorming | 4 | 35% | Light | Individual use |\n| Customer Success | 4 | 45% | Medium | Account management |\n| Developer | 4 | 40% | Variable | Depends on testing |\n| Executive | 3 | 25% | Very light | Dashboard only |\n| AI Twin | 15 | 100% | High | Full experience |\n\n**Result:** Platform scales efficiently based on usage patterns.\n\n---\n\n## IMPLEMENTATION LAYERS\n\n### 1. Capability Resolver (New)\n```\nservices/capability-resolver/\n  ├─ Validates manifest\n  ├─ Resolves dependencies\n  ├─ Calculates rate limits\n  └─ Returns capability graph\n```\n\n### 2. Projection Registry (New)\n```\nservices/projection-registry/\n  ├─ Defines UI projections\n  ├─ Maps capabilities to widgets\n  ├─ Manages navigation structure\n  └─ Renders for frontend type\n```\n\n### 3. Feature Manifests (New)\n```\nservices/gateway/manifests/\n  ├─ brainstorming.ts\n  ├─ customer-success.ts\n  ├─ developer.ts\n  ├─ executive.ts\n  └─ twin.ts\n```\n\n### 4. Gateway (Updated)\n```\nservices/gateway/\n  ├─ Added: /resolve-capabilities\n  ├─ Added: /projections\n  ├─ Updated: Request validation\n  └─ Updated: Rate limiting per manifest\n```\n\n### 5. Client SDK (Updated)\n```\nlib/gateway-client.ts\n  ├─ Accepts manifest parameter\n  ├─ Blocks non-manifest endpoints\n  ├─ Respects rate limits\n  └─ Type-safe by manifest\n```\n\n---\n\n## EVOLUTION PATH\n\n**Today:** 5 predefined frontends\n**Week 1:** Add custom manifests\n**Week 2:** Add manifest composition (combine multiple)\n**Week 3:** Add runtime manifest adjustment\n**Month 2:** Add ML-based optimal manifest suggestion\n\n---\n\n## KEY PRINCIPLES\n\n1. **Backend is capable of everything**\n   - All 15 layers always available\n   - All services always running\n\n2. **Frontend declares what it needs**\n   - \"I only use memory, entity360, chat\"\n   - Not \"give me everything\"\n\n3. **Platform enforces at Gateway**\n   - Requests outside manifest are rejected\n   - Rate limits apply per manifest\n   - Permissions still centralized\n\n4. **Spine provides accountability**\n   - Every call logged\n   - Every action audited\n   - Every permission checked\n\n5. **Projections make it visual**\n   - How capabilities appear on screen\n   - Different frontends see different UIs\n   - Same backend, different presentations\n\n---\n\n## EXAMPLE: CUSTOM MANIFEST\n\n```typescript\n// Startup may only need analytics + chat\nconst startupManifest = {\n  frontendId: 'startup-app',\n  capabilities: [\n    'metrics',\n    'chat',\n    'entity360',\n    'tasks'\n  ]\n}\n\n// Request resolution\nconst resolved = await fetch(\n  'https://gateway.integratewise.dev/api/v1/resolve-capabilities',\n  {\n    method: 'POST',\n    body: JSON.stringify({\n      frontendType: 'custom',\n      customCapabilities: startupManifest.capabilities\n    })\n  }\n)\n\n// Response includes:\n// - Which endpoints are allowed\n// - Rate limits (shared across 4 capabilities)\n// - Required layers (metrics, chat, context)\n// - Projection recommendations\n```\n\n---\n\n## SUMMARY\n\n**Before:** One size fits all\n```\nFrontend\n    ↓\nAll 30 endpoints\n    ↓\nAll 15 layers\n    ↓\nBackend\n```\n\n**After:** Right-sized for each use case\n```\nFrontend (type)\n    ↓\nFeature Manifest (declares needs)\n    ↓\nCapability Resolver (validates)\n    ↓\nProjection Registry (renders)\n    ↓\nSelected Capabilities (efficient)\n    ↓\nBackend (provides what's asked)\n```\n\n**Impact:**\n- ✅ Each frontend only loads what it needs\n- ✅ Platform still enforces auth, permissions, audit\n- ✅ Backend is simple: one API, multiple entry points\n- ✅ Easy to add new frontends (just create manifest)\n- ✅ Easy to optimize (each manifest has own rate limits)\n\n---\n\n## NEXT: IMPLEMENT & DEPLOY\n\n1. **Deploy Capability Resolver**\n   - Validates manifests\n   - Returns capability graph\n\n2. **Deploy Projection Registry**\n   - Manages UI layouts\n   - Maps to capabilities\n\n3. **Update Gateway**\n   - Add /resolve-capabilities endpoint\n   - Add rate limiting per manifest\n   - Add request validation per manifest\n\n4. **Update Client SDK**\n   - Accept manifest parameter\n   - Enforce manifest in TypeScript\n   - Block non-manifest endpoints\n\n5. **Update Each Frontend**\n   - Provide manifest on client creation\n   - Only call allowed endpoints\n   - Respect rate limits\n\n---\n\n**This is the architectural leap that makes the platform truly multi-product, not multi-tenant.**\n\n"}