{"slug":"strategy/business-strategy/CUSTOMER_ZERO","title":"CUSTOMER ZERO","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/business-strategy/CUSTOMER_ZERO.mdx","bytes":5185,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\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\nStatus: CURRENT\nScope: First real tenant activation model, current evidence, target canonical state\nCanonical Owner: Platform / Customer Zero\nLast Verified: 2026-07-11\nEvidence Basis: docs/CANON.md, docs/architecture/ONBOARDING_FLOW.md, docs/internal/playbooks/tenant-onboarding-and-initial-hydration.md, docs/internal/operations/CUSTOMER_ZERO_FLOW_TEST.md, docs/FINAL_E2E_SYSTEM.md, docs/CANONICAL_STATE.md, docs/operations/ENDPOINT_MAP.md, docs/archive/CUSTOMER_ZERO_LAUNCH.md, docs/archive/IMPLEMENTATION_COMPLETE.md, Option B evidence, wrangler manifests, tests/playwright README\nSupersedes: none\nSuperseded By: none\n\n---\n\n## 1. WHAT CUSTOMER ZERO IS\n\nCustomer Zero means:\n\n```text\nINTEGRATEWISE\nUSES\nINTEGRATEWISE\nAS ITS FIRST REAL TENANT\n```\n\nIt is not a demo wizard.\nIt is not a frontend onboarding flow in isolation.\nIt is first real tenant activation of the actual platform.\n\n---\n\n## 2. CANONICAL CUSTOMER ZERO ACTIVATION MODEL\n\n```text\nLANDING\n   ↓\nACTIVATE WORKSPACE\n   ↓\nPRE-AUTH INTENT if required\n   ↓\nAUTHENTICATE\n   ↓\nUSER RESOLUTION\n   ↓\nORGANIZATION / TENANT RESOLUTION\n   ↓\nWORKSPACE RESOLUTION\n   ↓\nONBOARDING\n   ↓\nCONTEXT LENS / ROLE CONTEXT\n   ↓\nINTEGRATION MANAGER\n   ↓\nCONNECT REAL SYSTEM\n   ↓\nINITIAL HYDRATION\n   ↓\nNORMALIZATION\n   ↓\nSCHEMA SYNTHESIS WHEN REQUIRED\n   ↓\nCANONICAL WRITE\n   ↓\nINITIAL CONTINUITY\n   ↓\nL1 WORKBENCH READY\n```\n\nEach step must be satisfied with evidence before declaring activation advancement.\n\n---\n\n## 3. CURRENT EVIDENCE AND GAPS\n\nCurrent repo evidence:\n\n- Onboarding flow documents exist: `docs/architecture/ONBOARDING_FLOW.md`\n- Tenant onboarding playbook exists: `docs/internal/playbooks/tenant-onboarding-and-initial-hydration.md`\n- Customer Zero flow test exists: `docs/internal/operations/CUSTOMER_ZERO_FLOW_TEST.md`\n- Playwright tests directory exists: `tests/playwright/README.md`\n- Customer Zero launch docs exist in archive\n\nGaps requiring evidence:\n\n- frontend flow type unknown: UI navigation, frontend state, API contract, integration, or true end-to-end\n- Spine hydration state unclear: did hydration write reach canonical state?\n- real system connection evidence unclear: did a real external system authorize, hydrate, normalize, and persist?\n- canonical write authority unknown: wrote to pipeline, spine-writer, or direct database path?\n- continuity initialization evidence unclear: was operational context persisted and recovered?\n- L1 Workbench readiness requires end-to-end readback evidence\n\nA frontend flow may be:\n\n- SIMULATED\n- PARTIAL\n- REAL\n\nDetermine the actual state. Do not declare \"activation complete\" without platform evidence.\n\n---\n\n## 4. DO NOT TREAT FRONTEND FLOW AS ACTIVATION COMPLETION\n\nThe presence of a flow component or route such as `customer-zero-flow.tsx` does not prove:\n\n- external system connection\n- canonical write\n- real hydration\n- normalization execution\n- continuity initialization\n\nEvidence-based activation completion requires:\n\n- successful end-to-end playback of Customer Zero activation\n- verified canonical state after hydration\n- verified Continuity state recovery\n- verified platform runtime behavior, not just UI state transitions\n\n---\n\n## 5. DO NOT TREAT SPINE ROUTES AS PROOF OF SPINE INTEGRATION\n\nIf the Customer Zero frontend calls Next.js routes under `/api/spine/*`, the downstream must be traced:\n\n- does this route proxy to the Gateway?\n- does the Gateway call the canonical Spine writer?\n- does the writer enforce governance and tenant isolation before canonical write?\n\nAbsent evidence, classify this path as UNKNOWN.\n\n---\n\n## 6. MCP AND CUSTOMER ZERO\n\nDo not infer that MCP is required for Customer Zero activation.\n\nAuthorization issues such as the reported `tenant: integratewise`, `client: kiro-iw` 403 response block that path but do not establish MCP as the primary Customer Zero path unless alternative product routing proves it.\n\nCustomer Zero activation documentation must state:\n\n- the exact product route\n- the exact platform route\n- evidence of operational success or failure\n\n---\n\n## 7. CURRENT CUSTOMER-ZERO VERDICT\n\nCurrent evidence-based verdict is:\n\n- Customer Zero documentation/activity exists\n- Customer Zero runtime verification is DOCUMENTED_WITH_KNOWN_GAPS\n\nHigher confidence:\n\n- DOCUMENTED_WITH_KNOWN_GAPS\n\nThis is not a blocking verdict, but it is not a completion verdict.\n\nDo not add Customer Zero to readiness claims until activation criteria above are replayed and readback-verified.\n\n---\n\n## 8. DOCUMENTS THAT PRECEDE THIS\n\n- docs/internal/playbooks/tenant-onboarding-and-initial-hydration.md\n- docs/architecture/ONBOARDING_FLOW.md\n- docs/internal/operations/CUSTOMER_ZERO_FLOW_TEST.md\n- docs/FINAL_E2E_SYSTEM.md\n- docs/CANONICAL_STATE.md\n- docs/archive/CUSTOMER_ZERO_LAUNCH.md\n- docs/archive/IMPLEMENTATION_COMPLETE.md\n- docs/internal/status/TWIN_DEPLOYMENT_STATUS.md\n\nWhen conflict arises between this document and those documents, this document is canonical.\n"}