{"slug":"strategy/business-strategy/17-customer-zero-and-company-lifecycle-os","title":"17 — Customer Zero and Company Lifecycle OS","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/business-strategy/17-customer-zero-and-company-lifecycle-os.mdx","bytes":4054,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** Canonical proof model; acceptance evidence pending per journey\n\n## Rule\n\nCustomer Zero is production proof, not a privileged shortcut. It uses the same\nClerk, Gateway, account/tenant, Nango, connector binding, schema, Pipeline,\nSpine, Projection Engine, Governance, Hermes, sync, and repair paths as every\ncustomer.\n\nThe canonical tenant is `iw-customer-zero`.\n\nCustomer Zero is an operating tenant plus an isolated production-shaped\nenvironment. It is not a separate Product, a single special application or a\nshared test tenant. It has dedicated credentials, data, queues, caches, search,\nevidence and audit boundaries.\n\n## Four-flow lifecycle\n\n| Flow | Customer Zero material                                                                                     | Boundary                                                                             |\n| ---- | ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |\n| A    | IntegrateWise operational entities, relationships, events and lifecycle state                              | Deterministic Normalizer prepares governed candidates.                               |\n| B    | Internal messages, meetings, documents, attachments and evidence                                           | Raw bytes remain in R2; extracted meaning retains lineage.                           |\n| C    | Twin sessions, model output, plans, proposals, agent outcomes and memory candidates                        | Triage routes to Promotion Queue and required human approval; no direct truth write. |\n| D    | Internal identity, tenant, workspace, membership, role, consent, connector, capability and policy bindings | Establishes the authority envelope for A/B/C.                                        |\n\nOperational D1/KV state expires or rebuilds according to policy. Age and\nlifecycle closure never promote truth. Governed Spine Writers commit approved\ncanonical state to the dedicated Customer Zero Neon Fortress.\n\n## Required journey\n\n1. Clean user signs in through Clerk.\n2. Gateway resolves active organisation, account, and tenant.\n3. User opens Integration Manager.\n4. User installs a launch connector through Nango.\n5. Gateway persists the complete server-owned binding.\n6. Initial load and normalisation run.\n7. Pipeline promotes Connection, Connector, Schema, SyncJob, and TimelineEvent.\n8. Integration Manager reads the resulting projection.\n9. Incremental sync or webhook updates the Workbench.\n10. A deliberate mismatch makes the connection stale.\n11. Stale state is excluded everywhere.\n12. Authenticated repair returns the binding to operational.\n13. Governance and Hermes execute one approved action.\n14. Outcome is re-ingested, reconciled, and projected.\n\n## Golden connector set\n\nUse a small production-ready set:\n\n- GitHub for installation identity, repositories, webhooks, and incremental sync;\n- Slack or one collaboration provider for workspace identity and events;\n- one CRM or customer system for schema depth, pagination, and sync.\n\nCatalog presence is not acceptance.\n\n## Evidence pack\n\nCapture deployment and commit IDs, verified principal and organisation\nreferences, account and tenant, binding and schema IDs, opaque authorisation\nreference, provider workspace, Spine Connection, SyncJobs, counts, webhook,\nprojection, approval, execution receipt, stale/repair proof, correlation IDs, and\ntimestamps. Exclude secrets and unnecessary personal data.\n\n## Company lifecycle\n\nCustomer Zero work follows:\n\n```text\nSense → Frame → Decide → Build → Verify → Release → Operate → Learn → Adjust\n```\n\nWork advances when state-specific evidence and exit criteria exist, not because\nactivity was recorded.\n\nOnly reviewed code, schema, configuration and policy artifacts may move from\nCustomer Zero validation into Customer Production. Customer Zero data, memory\nand evidence never do.\n"}