{"slug":"strategy/business-strategy/PLANE_LAYER_CROSS_REFERENCE","title":"Platform Plane ↔ Layer Stack Cross-Reference","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/business-strategy/PLANE_LAYER_CROSS_REFERENCE.mdx","bytes":15368,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Status: SUPERSEDED CROSS-REFERENCE.** The 19-plane/6-layer taxonomy is\n> historical engineering genealogy, not the frozen product or runtime model.\n> Use [`ARCHITECTURE_LOCK.md`](./ARCHITECTURE_LOCK.md) for the 12 kernel terms,\n> one Workbench surface and frozen runtime sequence.\n>\n> **Original status:** Canonical cross-reference\n> **Date:** July 12, 2026  \n> **Authority:** Nirmal (Founder)  \n> **Canonical Reference:** [CANONICAL_PLATFORM_ARCHITECTURE.md](./CANONICAL_PLATFORM_ARCHITECTURE.md)  \n> **Purpose:** Maps every Platform Plane to its layer(s) in the 6-Layer Stack, primary service bindings, and specification sections. This is the structural bridge between the product architecture (19 planes) and the technical architecture (6 layers).\n\n---\n\n## The Two Models\n\n### 6-Layer Stack (Technical Architecture — Documents 1 & 2)\n\n| Layer | Name            | Responsibility                                                                  |\n| ----- | --------------- | ------------------------------------------------------------------------------- |\n| L1    | Identity        | JWT, tenant isolation, RBAC, session management                                 |\n| L2    | Ingress         | Gateway routing, MCP protocol, SSE connections, webhook intake                  |\n| L3    | Capability      | Capability registry, routing, governance pre-check, context assembly, execution |\n| L4    | Continuity      | Spine (D1), memory, knowledge, context hydration                                |\n| L5    | Governance      | Proposal lifecycle, HITL queue, approval, audit                                 |\n| L6    | Provider Fabric | External API adapters, sync, writeback                                          |\n\n### 19 Platform Planes (Product Architecture — Document 3)\n\n| Plane                        | Canonical Responsibility                                                  |\n| ---------------------------- | ------------------------------------------------------------------------- |\n| Configuration Manager        | Defines how the tenant operates                                           |\n| Integration Manager          | Connects and discovers the tenant ecosystem                               |\n| Activation Bridge            | Compiles configuration + connections + user context into active workspace |\n| Pipeline                     | Converts provider activity into canonical operational state               |\n| Adaptive Spine               | Owns canonical operational truth                                          |\n| Spine Cache                  | Accelerates hydration and derived views                                   |\n| Knowledge                    | Owns semantic retrieval representations                                   |\n| Blobs                        | Owns files, raw artifacts, and evidence                                   |\n| User Workbench               | Department hub composing cross-tool fields, data, memory, capabilities    |\n| Twin                         | Reasons, retrieves, plans, delegates, proposes                            |\n| Twin Memory                  | Owns durable AI / user continuity                                         |\n| Session Logs                 | Own interaction and runtime session history                               |\n| Twin Audit Logs              | Own AI accountability and lineage                                         |\n| Capability Fabric            | Resolves how an intent can be performed                                   |\n| Governance Engine            | Resolves whether and under whose authority it may be performed            |\n| Hermes                       | Orchestrates execution                                                    |\n| Sync Engine                  | Controls system convergence                                               |\n| Continuity Pipeline          | Converts outcomes back into persistent operational memory                 |\n| Cross-Cutting Infrastructure | Identity, config, queues, observability, deployment, billing              |\n\n---\n\n## Cross-Reference Table\n\n| Platform Plane                   | Layer(s)                    | Primary Services                           | Spec Section                               | Notes                                                                                                                                   |\n| -------------------------------- | --------------------------- | ------------------------------------------ | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |\n| **Configuration Manager**        | L1 (partial), Cross-cutting | Tenant DO, KV config stores                | Not yet specified                          | Spans identity config, composition rules, sync policy, governance policy. No technical spec exists.                                     |\n| **Integration Manager**          | L2, L6                      | mcp-connector, act service adapters, Nango | Doc 1 §6 (MCP), Doc 1 §8 (Provider Fabric) | Four paths: MCP (L2), AI Connector (L2+L3), API Connector (L6), API Wrapper (L3). Only MCP has detailed spec.                           |\n| **Activation Bridge**            | L3 (partial), L4            | Context assembly, workspace hydration      | Not yet specified                          | Compiles config + connections + user context → active workspace. Maps to Doc 1's `AssembledContext` but broader.                        |\n| **Pipeline**                     | L4, L6                      | pipeline service (D1 writer), normalizer   | Doc 1 §4 (Normalizer), Doc 3 Data Pipeline | Three modes: Creamy Load (full), Delta Load (incremental), Streaming/Event Load. Only normalizer has partial spec.                      |\n| **Adaptive Spine**               | L4                          | D1 domain partitions, spine service        | Doc 1 §3 (Spine D1), Doc 3 Spine Model     | Canonical entity model, relationships, decisions, evidence, work state. Entity360 mismatch: flat (Doc 1) vs. rich (Doc 3).              |\n| **Spine Cache**                  | L4                          | D1 cache, KV hot cache                     | Doc 1 §3.5 (Spine Cache)                   | Entity 360 hydration views, context bundles, derived state.                                                                             |\n| **Knowledge**                    | L4                          | Vectorize, AI Search                       | Doc 1 §4 (Memory/Knowledge)                | Semantic embeddings, retrieval, graph context.                                                                                          |\n| **Blobs**                        | L4                          | R2 storage                                 | Not detailed in Doc 1                      | Documents, attachments, evidence, raw payloads.                                                                                         |\n| **User Workbench**               | Consumer of all layers      | apps/live (React/Next.js)                  | Doc 3 User Workbench, Doc 3 OODA Grammar   | Role-aware composition surface. No backend — consumes projections from all layers.                                                      |\n| **Twin**                         | L3 (partial), L4            | iw-agent-runtime DO, think service         | Doc 1 §7 (Twin DO), Doc 3 Twin             | 7 capabilities narratively described, 3 technically specified. Gap: planning, tool selection, agent delegation, capability preparation. |\n| **Twin Memory**                  | L4                          | D1/KV memory stores                        | Doc 1 §7.2 (Memory Graph)                  | Durable AI continuity, user preferences, learned context.                                                                               |\n| **Session Logs**                 | L4                          | D1 session state                           | Doc 1 §7.3 (Session State)                 | Conversations, tool calls, context lifecycle.                                                                                           |\n| **Twin Audit Logs**              | L5                          | D1 audit partition                         | Doc 1 §5 (Audit)                           | Model/agent identity, intent, policy decision, approval lineage.                                                                        |\n| **Capability Fabric**            | L3                          | CapabilityRouter DO, capability registry   | Doc 1 §6 (Capability Registry)             | Resolves how work gets done. 5 runtime types: agent, pipeline, workflow, mcp, direct. Needs 4 connection paths added.                   |\n| **Governance Engine**            | L5                          | govern service, HITL queue                 | Doc 1 §5 (Governance)                      | Confidence-based (Doc 1) vs. authority-based (Doc 3) — needs reconciliation.                                                            |\n| **Hermes**                       | L3                          | CapabilityRouter DO                        | Doc 1 §6 (CapabilityRouter)                | Execution orchestrator. Doc 1: routing only. Doc 3: broader (coordinate agents, retry, reconcile).                                      |\n| **Sync Engine**                  | L6                          | pipeline queue, writeback adapters         | Not yet specified                          | 6 convergence modes. Only PIPELINE_QUEUE exists. No spec for deferred, batch, scheduled, reconciliation.                                |\n| **Continuity Pipeline**          | L4, L5                      | pipeline service, audit                    | Doc 3 Continuity Pipeline                  | Intent → Action → Evidence → Outcome → State → Memory → Promote to Spine. No technical spec.                                            |\n| **Cross-Cutting Infrastructure** | L1, Cross-cutting           | Gateway, KV, queues, metrics               | Doc 1 §2 (Service Topology)                | Identity, config, ephemeral runtime, queues, observability, deployment, billing, admin.                                                 |\n\n---\n\n## Gap Analysis Summary\n\n### Planes with Full Technical Specification\n\n| Plane             | Status                             |\n| ----------------- | ---------------------------------- |\n| Adaptive Spine    | Partial (Entity360 mismatch)       |\n| Spine Cache       | Partial                            |\n| Capability Fabric | Partial (needs 4 connection paths) |\n| Hermes            | Partial (scope divergence)         |\n| Twin              | Partial (3 of 7 capabilities)      |\n| Twin Memory       | Partial                            |\n| Session Logs      | Partial                            |\n| Twin Audit Logs   | Partial                            |\n\n### Planes with No Technical Specification\n\n| Plane                              | Complexity     | Priority |\n| ---------------------------------- | -------------- | -------- |\n| Configuration Manager              | High           | P2       |\n| Integration Manager (3 of 4 paths) | Very High      | P1       |\n| Activation Bridge                  | High           | P2       |\n| Pipeline (Creamy/Delta/Streaming)  | Very High      | P1       |\n| Sync Engine                        | Very High      | P1       |\n| Continuity Pipeline                | High           | P1       |\n| Knowledge                          | Medium         | P2       |\n| Blobs                              | Low            | P3       |\n| User Workbench                     | N/A (frontend) | P3       |\n\n---\n\n## Governance Model Reconciliation\n\nThe two governance models must be unified. Proposed reconciliation:\n\n### Layered Governance Model\n\n```\n                    GOVERNANCE ENGINE\n                          │\n          ┌───────────────┼───────────────┐\n          │               │               │\n     AUTHORITY        CONFIDENCE       EVIDENCE\n     GOVERNANCE       GOVERNANCE       GOVERNANCE\n          │               │               │\n   Who can do what   How sure is the   What proof exists\n   under what policy  system about      for this action?\n          │           this proposal?        │\n          │               │               │\n          └───────────────┼───────────────┘\n                          │\n                    UNIFIED OUTCOME\n                          │\n              ┌───────────┼───────────┐\n              │           │           │\n           ALLOW       DENY      REQUIRE\n                                  APPROVAL\n```\n\n**Resolution Rules:**\n\n1. Authority gates capability access (RBAC × policy × scope)\n2. Confidence gates auto-approval (≥0.85 auto, 0.70–0.85 HITL, <0.70 discard)\n3. Evidence gates audit trail (every action logged with intent + evidence + outcome)\n4. When authority allows but confidence is low → REQUIRE APPROVAL\n5. When authority denies → DENY (regardless of confidence)\n6. When confidence is high but authority is missing → REQUIRE APPROVAL\n7. When both authority and confidence are satisfied → ALLOW\n\nThis preserves both models without conflict.\n\n---\n\n## Entity360 Reconciliation\n\nThe Entity360 data model must support both the flat struct (for simple lookups) and the rich cross-tool composition (for Workbench surfaces).\n\n### Proposed Entity360 V2\n\n```typescript\ninterface Entity360 {\n  // Core identity (always present)\n  id: string;\n  type: CanonicalEntityType;\n  tenantId: string;\n\n  // Flat properties (fast lookup)\n  properties: Record<string, unknown>;\n\n  // Rich composition (lazy-loaded per Workbench)\n  composition?: {\n    crm?: CrmEntityView;\n    support?: SupportEntityView;\n    billing?: BillingEntityView;\n    product?: ProductEntityView;\n    communication?: CommunicationEntityView;\n    projects?: ProjectEntityView;\n    memory?: MemoryEntityView;\n    decisions?: DecisionEntityView;\n    capabilities?: CapabilityView[];\n  };\n\n  // Metadata\n  traits: Trait[];\n  timeline: TimelineEvent[];\n  projections: ProjectedView[];\n  provenance: ProvenanceRecord[];\n\n  // Governance\n  authority: AuthorityScope;\n  syncPolicy: SyncPolicy;\n}\n```\n\nThe `composition` field is lazy-loaded based on the Workbench's role + department + active context. This preserves the flat struct for internal operations while supporting the rich cross-tool view for the User Workbench.\n\n---\n\n## Next Steps\n\n1. **P0:** This cross-reference table is now the structural bridge\n2. **P0:** Reconcile governance models using the layered model above\n3. **P0:** Reconcile Entity360 using V2 data model above\n4. **P1:** Write technical spec for Data Pipeline (Creamy/Delta/Streaming)\n5. **P1:** Write technical spec for Sync Engine\n6. **P1:** Write technical spec for Integration Manager (4 paths)\n7. **P2:** Write technical spec for Configuration Manager\n8. **P2:** Write technical spec for Activation Bridge\n9. **P2:** Expand Twin specification to cover all 7 capabilities\n"}