{"slug":"operations/POST_CLEANUP_SYSTEM_REPORT","title":"IntegrateWise — Post-Cleanup System Report","section":"operations","sectionLabel":"Operations","status":"unclassified","type":"document","path":"operations/POST_CLEANUP_SYSTEM_REPORT.mdx","bytes":16461,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> What the system looks like after all 11 collision categories are resolved.\n> This is the target state. Every path is singular. Every file has one job.\n\n---\n\n## THE SYSTEM AFTER CLEANUP\n\n### One Data Read Path\n\nEvery frontend view reads data the same way:\n\n```\nFrontend View\n    │\n    ▼\nuseWorkspaceEntities(\"entity_type\")\n    │  (delegates internally)\n    ▼\nuseSpine DBEntities → spineDb.rpc(\"get_workspace_entities\")\n    │\n    ▼\nSpine DB PostgreSQL (RLS scoped by tenant_id via auth.uid())\n```\n\nNo Gateway. No BFF. No Hydration Fabric. No SpineProvider. One hook, one RPC, one DB call.\n\nFor composite views (multiple entity types):\n\n```\nuseWorkspaceEntitiesBatch([\"account_master\", \"task_item\", \"risk\"])\n    │\n    ▼\nspineDb.rpc(\"get_workspace_entities\", { p_entity_types: [...] })\n    │\n    ▼\nONE DB call returns all entity types\n```\n\nFor product-scoped views:\n\n```\nuseProductEntities(\"data_sentinel\")\n    │\n    ▼\nspineDb.rpc(\"get_product_entities\", { p_product_id: \"...\" })\n```\n\n**What's eliminated:**\n\n- useHydrateProjection (18 consumers migrated)\n- useSpineEntities in spine-client.tsx (deleted)\n- useSpineEntities in useCognitiveData.ts (deleted)\n- All apiFetch calls for entity reads (295 calls audited, workspace reads converted)\n- useModuleDataContext dependency on SpineProvider (reads from Spine DB directly)\n\n**What stays on Gateway (writes + L2 cognitive):**\n\n- All writes (POST /api/v1/workspace/entities, etc.)\n- L2 cognitive operations (signals, situations, approvals, Flow C triage)\n- Admin operations (RBAC, tenant management)\n- Billing operations\n\n---\n\n### One Schema Source of Truth\n\n```\npackages/types/src/schema.ts\n    │\n    │  DOMAIN_SPINE_CONFIG (12 domains × entity types + priority fields)\n    │  getSpineConfig(industry, department)\n    │  INDUSTRY_SPINE_BASE (11 industry overlays)\n    │  ORGANIC_CAPABILITY_MAP (what frontend shows per domain)\n    │\n    ├── Consumed by: Normalizer (S1 schema resolution, S3 filter, S5 extract)\n    ├── Consumed by: Spine-v2 (ENTITY_TYPE_TO_TABLE derives from this)\n    ├── Consumed by: entity_type_map SQL table (migration 070, derives from this)\n    └── Consumed by: Frontend (via Spine DB RPC, never directly)\n```\n\n**What's eliminated:**\n\n- DOMAIN_SPINE_CONFIG duplicate in services/workflow/src/index.ts (deleted, imports from packages/types)\n- ADAPTIVE_DOMAIN_TO_ENTITY_TYPES in adaptive-schema.ts (synced to 12 domains, derives from schema.ts)\n- spineProjection in domain-types.ts (removed — Spine DB RPC bypasses it entirely)\n\n**What stays:**\n\n- ENTITY_TYPE_TO_TABLE in spine-v2 (needed for write routing, aligned with schema.ts)\n- entity_type_map SQL table (needed for RPC, aligned with ENTITY_TYPE_TO_TABLE)\n- domain-data-registry.ts (seed data, not schema — clearly labeled)\n\n---\n\n### One Entity 360 Path\n\n```\nFrontend (Entity360View.tsx)\n    │\n    ▼\nspineDb.rpc(\"get_entity_360\", { p_entity_id: \"...\" })\n    │  OR\napiFetch(\"/api/entity360/:id\") → Gateway → Spine-v2\n    │\n    ▼\nSpine-v2: assembleEntity360()\n    │\n    ├── Truth: spine.entities + department table\n    ├── Context: context_extractions\n    ├── Knowledge Memory: consolidated_memories (Flow C, governed)\n    ├── Signals: signals table\n    └── Relationships: entity graph\n    │\n    ▼\nKV Cache (60s TTL)\n    │\n    ▼\nEntity 360 Response (all layers assembled)\n```\n\n**What's eliminated:**\n\n- Think's thin Entity360Client (entity360-client.ts) — deleted, Think calls Spine-v2 assembler via service binding\n- Third path in cognitive-brain.ts:2037 — deleted, uses Spine-v2 assembler\n- Frontend calling Think directly for Entity 360 — redirected to Spine-v2\n\n**What stays:**\n\n- Spine-v2 assembleEntity360() — THE assembler (rich, cached, relationships included)\n- Twin 360 endpoint (/v1/twin/360/:entityId) — calls Spine-v2 assembler, then evaluates triggers\n- Frontend Entity360View — calls Spine-v2 (not Think)\n\n---\n\n### One HITL / Approval Path\n\n```\nTwin generates insight\n    │\n    ▼\nThink writes to Spine DB `actions` table (status: pending_approval)\n    │\n    ▼\nFrontend reads pending actions (Spine DB direct: spineDb.from(\"actions\").select(\"*\").eq(\"status\", \"pending_approval\"))\n    │\n    ▼\nUser approves/rejects in L2 overlay\n    │\n    ▼\nFrontend calls: POST /api/v1/cognitive/hitl/approve (Gateway → Workflow)\n    │\n    ▼\nWorkflow handleApproval():\n    ├── Approve: generates approval_token → ACT_QUEUE\n    ├── Reject: writes to decision_memory → notifies Think (ADJUST)\n    │\n    ▼\nAct service receives from ACT_QUEUE:\n    ├── Validates approval_token\n    ├── Calls Govern for policy check\n    ├── Executes via Connector (external tool)\n    ├── Re-ingests result to Pipeline (REPEAT)\n    └── Sends outcome feedback to Think (ADJUST)\n```\n\n**What's eliminated:**\n\n- POST /v1/approve + POST /v1/reject on Govern (consolidated into Workflow path)\n- POST /api/v1/cognitive/act/approve (consolidated into Workflow path)\n- POST /api/v1/l2/recommendations/:id/decision (consolidated into Workflow path)\n- HITLGateDO Durable Object direct path (consolidated — all approvals go through Spine DB-backed Workflow)\n\n**What stays:**\n\n- ONE approval endpoint: POST /api/v1/cognitive/hitl/approve\n- ONE rejection endpoint: POST /api/v1/cognitive/hitl/reject\n- Govern policy check (called by Act, not directly by frontend)\n- Act execution (called by ACT_QUEUE, not directly by frontend)\n\n---\n\n### One L2 Overlay\n\n```\nworkspace-shell-new.tsx\n    │\n    ▼\nL2DrawerProvider (l2-drawer-animated.tsx)\n    │\n    ├── ⌘J keyboard shortcut\n    ├── Bottom bar trigger\n    ├── Event listeners (iw:evidence:open, iw:cognitive:open)\n    │\n    ▼\nSurface tabs: Spine | Context | Knowledge | Entity 360 | Think | Act | Adjust | Twin\n    │\n    ▼\nPanel components from l2/cognitive/panels/\n    │\n    ├── SpinePanel, ContextPanel, KnowledgePanel\n    ├── ThinkPanel, EvidencePanel, SignalsPanel\n    ├── MemoryPanel, AuditPanel\n    ├── PolicyPanel, CorrectRedoPanel\n    ├── WorkflowsPanel, ProactiveTwinPanel\n    └── ActSurface (HITL approval queue — merged from CognitiveLayer.tsx)\n```\n\n**What's eliminated:**\n\n- intelligence-overlay-new.tsx (deleted — orphan)\n- CognitiveLayer.tsx (HITL approval code merged into l2-drawer-animated, file deleted)\n- l2-drawer.tsx (deleted — duplicate of l2-drawer-animated)\n\n**What stays:**\n\n- l2-drawer-animated.tsx — THE L2 overlay (active, imported by workspace-shell-new)\n- All panel components in l2/cognitive/panels/ (unchanged)\n\n---\n\n### Clean File Structure\n\n**l1/views/ — 5 active files (31 orphans deleted):**\n\n- entity-browser.tsx\n- Entity360View.tsx\n- duplicate-resolution-view.tsx\n- knowledge-hub.tsx\n- product-view.tsx\n\n**l1/domains/ — 12 domains, no dead shells:**\n\n- Each domain has: dashboard.tsx, views/, modules.ts\n- shell.tsx files deleted (content-router handles all routing)\n- No duplicate executive dashboards\n\n**l1/navigation/ — 1 command palette:**\n\n- command-palette.tsx (the active one)\n- l1/command-palette.tsx deleted\n- l1/command-palette/ directory deleted\n\n**l2/ — 1 overlay, clean panels:**\n\n- cognitive/l2-drawer-animated.tsx (THE overlay)\n- cognitive/panels/ (all panel components)\n- approvals/ (approval components, evidence-drawer.tsx kept)\n- knowledge/ (knowledge components)\n- No orphan overlays, no duplicate drawers\n\n---\n\n### Service Architecture (Consolidated)\n\n```\nACTIVE WORKERS (7):\n├── integratewise-gateway        — API routing, auth, CORS\n├── integratewise-bff            — Workflow service (HITL, DOs, real-time)\n├── integratewise-intelligence   — Think + Act + Govern + Agents (consolidated)\n├── integratewise-pipeline       — Normalizer + Spine-v2 (consolidated)\n├── integratewise-knowledge      — Knowledge service + Memory Consolidator\n├── integratewise-connector      — Connector + Loader + MCP + Store (consolidated)\n└── integratewise-connector-sync — Connector sync scheduling\n\nQUEUES (9, all properly consumed):\n├── pipeline-process       → pipeline\n├── knowledge-ingest       → knowledge\n├── intelligence-events    → intelligence\n├── intelligence-act       → intelligence\n├── signals                → intelligence\n├── accelerator-trigger    → pipeline\n├── ops-dlq                → intelligence\n├── connector-sync         → connector-sync\n└── memory-consolidation   → knowledge\n```\n\n**What's eliminated:**\n\n- 6 deprecated wrangler.toml files (act, agents, govern, normalizer, spine-v2, think)\n- Worker name collision (integratewise-mcp-connector — one wrangler.toml kept)\n- Placeholder D1 ID in mcp-connector\n\n---\n\n### Database Architecture (Resolved)\n\n```\nREADS: get_workspace_entities() RPC\n    │\n    ├── Checks entity_type_map for schema routing\n    ├── If Architecture A table exists → reads from domain schema (e.g., cs.account_health)\n    ├── If Architecture A table missing → falls back to public.entities (Architecture B)\n    └── Returns unified result regardless of which architecture stores the data\n\nWRITES: Spine-v2 writeToSpine()\n    │\n    ├── Tries Architecture A table first (domain schema)\n    ├── Falls back to public.entities if schema table doesn't exist\n    └── Logs which path was used (fallback tracking)\n```\n\nThe split-brain is acknowledged and handled gracefully. Both architectures coexist. The RPC abstracts the difference. Over time, Architecture A tables can be created for the missing 93 entity types, but the system works correctly with the fallback.\n\n---\n\n## FUNCTIONALITY AFTER CLEANUP\n\n### What Works End-to-End\n\n**1. Onboarding → Workspace**\n\n- User signs up (Spine DB Auth)\n- Selects department + industry (OnboardingFlow.tsx)\n- tenant_spine_config activates (schema resolves)\n- Connects first tool (OAuth)\n- Loader extracts data → Pipeline processes (S1-S8) → Spine populates\n- Workspace renders with real data (Spine DB direct reads)\n- L1 sections hydrate per connector\n\n**2. Entity 360 → Twin → AI Insights**\n\n- Entity 360 assembles from Spine-v2 (Truth + Context + Knowledge Memory + Signals)\n- Twin evaluates 10 triggers against assembled data\n- Proactive insights written to signals table\n- Frontend picks up new insights via Spine DB Realtime subscription\n- Insights appear in L2 overlay and notification badge\n\n**3. HITL Approval → Act → Repeat**\n\n- Twin proposes action → written to actions table (pending_approval)\n- User sees pending action in L2 overlay\n- User approves → Workflow generates token → ACT_QUEUE\n- Act validates token → Govern policy check → Connector executes on external tool\n- Result re-ingested through Pipeline → Spine updates → Entity 360 updates\n- Twin re-evaluates → loop continues\n\n**4. Flow C → Knowledge Memory**\n\n- AI session ends → Knowledge service triage\n- Triage Bot scores confidence (Workers AI)\n- > = 0.85 confidence → auto-approve\n- < 0.5 confidence → auto-discard\n- Between → pending in Triage Inbox (Knowledge Hub)\n- User approves → Memory Consolidator → consolidated_memories\n- Entity 360 reads from consolidated_memories (governed knowledge)\n- Twin uses verified memory for reasoning\n\n**5. 20 Products Across 3 Surfaces**\n\n- Product catalog in Spine DB (migration 071)\n- Product-scoped navigation (migration 072)\n- Generic ProductView auto-renderer for products without custom views\n- 3 custom views: SuccessPilot (csm-accounts-hub), ChurnShield (intelligence-center), SuccessCommand (strategic-account-success)\n- 15 generic product views via ProductView wrapper\n\n**6. Billing**\n\n- Free subscription created on onboarding\n- Plan IDs: free/starter/growth/enterprise\n- Entitlement checks (dual-schema read)\n- SubscriptionsPage in all 12 domain content maps\n\n**7. 73 Connectors**\n\n- 60+ SaaS connectors\n- 6 India/Dubai connectors (Google Sheets, Tally, Razorpay, Vyapar, Khatabook, Shiprocket)\n- 6 accelerators (health_score, churn_prediction, revenue_forecast, pipeline_velocity, nps_analysis, data_quality)\n- 3 AI connectors (OpenAI, Anthropic, Cohere)\n- MCP connector (live endpoint)\n- Webhook Ingress (universal)\n- 52 sync adapters wired to universalSync()\n- OAuth token refresh (44 provider endpoints)\n\n---\n\n## METRICS AFTER CLEANUP\n\n| Metric                             | Before                    | After                                   |\n| ---------------------------------- | ------------------------- | --------------------------------------- |\n| Data read paths                    | 6 parallel hooks          | 1 (useWorkspaceEntities → Spine DB RPC) |\n| Schema sources                     | 5 definitions             | 1 (schema.ts, everything derives)       |\n| Entity 360 paths                   | 3 endpoints, 2 assemblers | 1 assembler (Spine-v2), 1 frontend path |\n| HITL/approval paths                | 4 frontend endpoints      | 1 (POST /api/v1/cognitive/hitl/approve) |\n| L2 overlay implementations         | 4 files                   | 1 (l2-drawer-animated.tsx)              |\n| Orphan files in l1/views/          | 31                        | 0                                       |\n| Dead domain shells                 | 11                        | 0                                       |\n| Duplicate command palettes         | 3                         | 1                                       |\n| Duplicate evidence drawers         | 2                         | 1                                       |\n| Duplicate onboarding flows         | 2                         | 1                                       |\n| Duplicate executive dashboards     | 2                         | 1 (wired version)                       |\n| Deprecated wrangler.toml files     | 6                         | 0                                       |\n| apiFetch calls for workspace reads | ~50                       | 0 (all Spine DB direct)                 |\n| Typecheck                          | 31/31                     | 31/31 (maintained)                      |\n| Active workers                     | 7                         | 7 (unchanged, configs cleaned)          |\n| Queues                             | 9                         | 9 (unchanged, all properly consumed)    |\n\n---\n\n## WHAT THE USER EXPERIENCES\n\n### Day 1 (After connecting first tool)\n\nL1 Workspace:\n\n- Dashboard shows real data from connected tool\n- Only sections with data are visible (progressive hydration)\n- Empty sections show \"Connect [tool name] to see this data\"\n- Navigation is clean — no 26-item sidebar, just relevant sections\n\nL2 Cognitive Overlay (⌘J):\n\n- Mostly empty — not enough data for Twin to reason\n- Knowledge Hub available (Triage Inbox, Memories, Sessions)\n- AI Chat available but limited context\n\n### Week 1 (After connecting 3-4 tools)\n\nL1 Workspace:\n\n- Multiple sections hydrated (accounts, contacts, tasks, calendar, revenue)\n- Entity 360 shows assembled profiles with Truth + Context\n- Cross-tool data visible in unified views\n\nL2 Cognitive Overlay:\n\n- Twin starts generating proactive insights\n- Signals appear in notification badge\n- Evidence panels show source attribution\n- HITL approval queue starts receiving proposals\n\n### Month 1 (Full stack connected)\n\nL1 Workspace:\n\n- All sections hydrated\n- Health scores computed\n- Renewal tracking active\n- Cross-department visibility (BizOps users)\n\nL2 Cognitive Overlay:\n\n- Full Twin active — 10 triggers evaluating\n- Knowledge Memory growing daily (Flow C)\n- HITL approval workflow in regular use\n- Decision memory accumulating (ADJUST)\n- AI Chat deeply contextual\n\n### The Continuous Loop\n\n```\nConnect tools → Data flows through Pipeline → Spine populates\n    → Entity 360 assembles → Twin reasons → Insights surface\n    → Human decides → Actions execute → Tools update\n    → Data flows back through Pipeline → Spine updates\n    → Entity 360 refreshes → Twin re-evaluates\n    → Knowledge Memory grows → System gets smarter\n    → No retraining needed → Context always current\n```\n\n---\n\n_This is the system after cleanup. One path for everything. No collisions. No confusion. Development and enhancements flow naturally because every developer knows exactly where to look, what to call, and how data moves._\n"}