{"slug":"strategy/business-strategy/2026-07-27-customer-zero-publication-gates","title":"Customer Zero and External Publication Gates","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/business-strategy/2026-07-27-customer-zero-publication-gates.mdx","bytes":7390,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** Approved\n\n**Date:** 2026-07-27\n\n**Applies to:** July 30 core launch and all subsequent external publication\n\n## Customer Zero Rule\n\nCustomer Zero is production proof, not a privileged shortcut. It authenticates,\nconnects, promotes, synchronizes, fails, repairs, and projects through the same\ncontracts used by every customer.\n\nCustomer Zero uses:\n\n- tenant ID `iw-customer-zero`;\n- verified Clerk users with active membership in the Customer Zero\n  Organization;\n- Gateway-resolved internal account and tenant membership;\n- Nango provider authorization references;\n- the normal connector binding, schema validation, Pipeline promotion, Spine,\n  projection, Governance, and Hermes paths.\n\nNo evidence is accepted if it requires a manual database mutation, browser\nidentity override, demo fallback, direct Spine write, or exposed provider\ncredential.\n\n## Required Customer Zero Journey\n\n1. A clean browser signs in through Clerk.\n2. Gateway resolves the active organization, account, and tenant.\n3. The user opens Integration Manager.\n4. The user installs a launch connector.\n5. Provider authorization completes through Nango.\n6. Gateway persists the complete server-owned binding.\n7. Initial load and normalization run.\n8. Pipeline promotes canonical Connection, Connector, Schema, SyncJob, and\n   TimelineEvent entities.\n9. Integration Manager reads the resulting projection.\n10. Incremental synchronization or a webhook updates the projection.\n11. A deliberate credential, workspace, tenant, or schema mismatch makes the\n    binding stale.\n12. Sync, connected totals, projections, capabilities, Twin context, and\n    execution exclude the stale binding.\n13. The authenticated repair path returns it to operational state.\n14. Audit evidence links the full journey with correlation identifiers.\n\n## Golden Connector Set\n\nCustomer Zero validates a small, production-ready set rather than every catalog\nentry:\n\n- GitHub for installation identity, repositories, webhooks, and incremental\n  sync;\n- Slack or one collaboration provider for workspace identity and events;\n- one CRM or customer system for schema depth, pagination, and incremental\n  synchronization.\n\nA connector is excluded from launch unless its production provider\ncredentials, callback, scopes, schema mappings, monitoring, and rollback are\nready.\n\n## Evidence Pack\n\nCapture for every accepted journey:\n\n- frozen commit, build, and deployment identifiers;\n- verified Clerk subject and organization references;\n- resolved account and tenant references;\n- connector binding ID and lifecycle history;\n- opaque authorization reference and provider workspace ID;\n- schema binding IDs and versions;\n- canonical Spine Connection ID;\n- initial and incremental SyncJob IDs;\n- normalized and rejected record counts;\n- webhook evidence where applicable;\n- Workbench projection result;\n- stale and repair evidence;\n- audit and correlation identifiers;\n- timestamps and accountable operator.\n\nNever include tokens, secrets, raw credentials, or unnecessary personal data.\n\n## Publication Surfaces\n\n### Integration Manager\n\nThe internal product Marketplace is the authoritative customer surface for\ncatalog discovery, installation, authentication, schemas, synchronization,\nwebhooks, capabilities, health, and repair. It consumes the canonical manifest\nand authenticated binding projection.\n\n### Plugin Directory\n\nPublish **IW-Spine-Network Plugin** as an MCP-backed app with focused,\nsandboxed interactive UI resources, workflow skills and optional templates.\nCustomer Zero must prove install, OAuth, isolated tenant activation, UI\nrendering, CSP/sandbox behavior, no-UI fallback, exact action approval and\noutcome reconciliation.\n\nThe installed customer receives the Customer Zero-proven reference activation\nprofile in its own tenant. No Customer Zero data, credentials, memory, cache,\nqueues or audit state is copied. The Plugin does not automatically inherit\nother host-app credentials; those apps participate only through host\ncomposition, explicit delegation or a direct IW connector.\n\n### GitHub\n\nGitHub distribution uses an installable GitHub App for repository and\norganization access, granular permissions, installation identity, and webhooks.\nUser authorization is added only for operations that truly require acting for\na person. The GitHub installation ID becomes the provider workspace identity\nand is mapped by Gateway to the connector binding.\n\nMarketplace submission also requires complete branding, pricing, privacy,\nterms, support, screenshots, installation URLs, and applicable Marketplace\nplan-event handling.\n\n### MCP Marketplace / Official MCP Registry\n\nPublish **IW-Spine-Network MCP** with exactly the frozen public 19-tool IW Spine\nTools contract. Required artifacts are a versioned implementation package or\ndocumented remote server, matching package and MCP names, optional focused MCP\nApp resources, meaningful text/JSON fallback, browser Workbench launch,\nvalidated `server.json`, repository and support metadata, tenant-bound OAuth,\nand automated tool-count and compatibility tests.\n\nTreat published versions as immutable. Do not publish before Customer Zero\nverifies OAuth, tenant isolation, tool inventory, governance, error handling,\nand clean installation.\n\n### Skills\n\nInitial skill packages may cover connector triage, stale binding diagnosis,\ncontinuity retrieval, schema compatibility review, Customer Zero verification,\nand governed capability preparation.\n\nEvery skill has a complete `SKILL.md`, triggers, authority boundaries, required\nevidence, failure behavior, examples, owner, and version. A skill cannot bypass\nGateway identity, Pipeline promotion, Governance, or Hermes.\n\n### Agents\n\nAgents remain runtime profiles composed from Twin and Capability contracts.\nEach distributable profile declares purpose, tools, scopes, tenant boundaries,\nmodel policy, approvals, stopping rules, escalation, evaluations, owner, and\nversion. Twin remains silent by default and never acts without approval.\n\n### Models\n\nThe launch publishes model policy rather than unsupported custom-model claims:\nworkload aliases, provider/model route, fallback, reasoning/latency class,\nprivacy mode, budget, rate limits, evaluation thresholds, deprecation, and\nrollback. Placeholder embedding, reranking, live, or custom routes are not\nadvertised as deployed.\n\n## Publication States\n\n- `draft`: incomplete and internal only;\n- `package_ready`: artifact builds and validates;\n- `staging`: installed in a non-production environment;\n- `customer_zero_verified`: end-to-end evidence accepted;\n- `submission_ready`: listing, security, legal, and support assets complete;\n- `submitted`: external review pending;\n- `published`: publicly discoverable and verified;\n- `deprecated`: no new installs and a migration is supplied;\n- `withdrawn`: unavailable for new installs while history remains.\n\n## Publication Sequence\n\n1. Correct stale claims and superseded names.\n2. Generate artifacts from the canonical catalog.\n3. Validate packages and metadata in CI.\n4. Install privately or in staging.\n5. Run Customer Zero.\n6. Freeze version and evidence.\n7. Submit external listings.\n8. Verify public installation into a clean tenant.\n9. Monitor, support, and deprecate through versioned releases.\n\nThird-party review is not part of the July 30 core product availability promise.\n"}