Unclassified

Customer Zero and External Publication Gates

Status: Approved

Date: 2026-07-27

Applies to: July 30 core launch and all subsequent external publication

Customer Zero Rule

Customer Zero is production proof, not a privileged shortcut. It authenticates,
connects, promotes, synchronizes, fails, repairs, and projects through the same
contracts used by every customer.

Customer Zero uses:

  • tenant ID iw-customer-zero;
  • verified Clerk users with active membership in the Customer Zero
    Organization;
  • Gateway-resolved internal account and tenant membership;
  • Nango provider authorization references;
  • the normal connector binding, schema validation, Pipeline promotion, Spine,
    projection, Governance, and Hermes paths.

No evidence is accepted if it requires a manual database mutation, browser
identity override, demo fallback, direct Spine write, or exposed provider
credential.

Required Customer Zero Journey

  1. A clean browser signs in through Clerk.
  2. Gateway resolves the active organization, account, and tenant.
  3. The user opens Integration Manager.
  4. The user installs a launch connector.
  5. Provider authorization completes through Nango.
  6. Gateway persists the complete server-owned binding.
  7. Initial load and normalization run.
  8. Pipeline promotes canonical Connection, Connector, Schema, SyncJob, and
    TimelineEvent entities.
  9. Integration Manager reads the resulting projection.
  10. Incremental synchronization or a webhook updates the projection.
  11. A deliberate credential, workspace, tenant, or schema mismatch makes the
    binding stale.
  12. Sync, connected totals, projections, capabilities, Twin context, and
    execution exclude the stale binding.
  13. The authenticated repair path returns it to operational state.
  14. Audit evidence links the full journey with correlation identifiers.

Golden Connector Set

Customer Zero validates a small, production-ready set rather than every catalog
entry:

  • GitHub for installation identity, repositories, webhooks, and incremental
    sync;
  • Slack or one collaboration provider for workspace identity and events;
  • one CRM or customer system for schema depth, pagination, and incremental
    synchronization.

A connector is excluded from launch unless its production provider
credentials, callback, scopes, schema mappings, monitoring, and rollback are
ready.

Evidence Pack

Capture for every accepted journey:

  • frozen commit, build, and deployment identifiers;
  • verified Clerk subject and organization references;
  • resolved account and tenant references;
  • connector binding ID and lifecycle history;
  • opaque authorization reference and provider workspace ID;
  • schema binding IDs and versions;
  • canonical Spine Connection ID;
  • initial and incremental SyncJob IDs;
  • normalized and rejected record counts;
  • webhook evidence where applicable;
  • Workbench projection result;
  • stale and repair evidence;
  • audit and correlation identifiers;
  • timestamps and accountable operator.

Never include tokens, secrets, raw credentials, or unnecessary personal data.

Publication Surfaces

Integration Manager

The internal product Marketplace is the authoritative customer surface for
catalog discovery, installation, authentication, schemas, synchronization,
webhooks, capabilities, health, and repair. It consumes the canonical manifest
and authenticated binding projection.

Plugin Directory

Publish IW-Spine-Network Plugin as an MCP-backed app with focused,
sandboxed interactive UI resources, workflow skills and optional templates.
Customer Zero must prove install, OAuth, isolated tenant activation, UI
rendering, CSP/sandbox behavior, no-UI fallback, exact action approval and
outcome reconciliation.

The installed customer receives the Customer Zero-proven reference activation
profile in its own tenant. No Customer Zero data, credentials, memory, cache,
queues or audit state is copied. The Plugin does not automatically inherit
other host-app credentials; those apps participate only through host
composition, explicit delegation or a direct IW connector.

GitHub

GitHub distribution uses an installable GitHub App for repository and
organization access, granular permissions, installation identity, and webhooks.
User authorization is added only for operations that truly require acting for
a person. The GitHub installation ID becomes the provider workspace identity
and is mapped by Gateway to the connector binding.

Marketplace submission also requires complete branding, pricing, privacy,
terms, support, screenshots, installation URLs, and applicable Marketplace
plan-event handling.

MCP Marketplace / Official MCP Registry

Publish IW-Spine-Network MCP with exactly the frozen public 19-tool IW Spine
Tools contract. Required artifacts are a versioned implementation package or
documented remote server, matching package and MCP names, optional focused MCP
App resources, meaningful text/JSON fallback, browser Workbench launch,
validated server.json, repository and support metadata, tenant-bound OAuth,
and automated tool-count and compatibility tests.

Treat published versions as immutable. Do not publish before Customer Zero
verifies OAuth, tenant isolation, tool inventory, governance, error handling,
and clean installation.

Skills

Initial skill packages may cover connector triage, stale binding diagnosis,
continuity retrieval, schema compatibility review, Customer Zero verification,
and governed capability preparation.

Every skill has a complete SKILL.md, triggers, authority boundaries, required
evidence, failure behavior, examples, owner, and version. A skill cannot bypass
Gateway identity, Pipeline promotion, Governance, or Hermes.

Agents

Agents remain runtime profiles composed from Twin and Capability contracts.
Each distributable profile declares purpose, tools, scopes, tenant boundaries,
model policy, approvals, stopping rules, escalation, evaluations, owner, and
version. Twin remains silent by default and never acts without approval.

Models

The launch publishes model policy rather than unsupported custom-model claims:
workload aliases, provider/model route, fallback, reasoning/latency class,
privacy mode, budget, rate limits, evaluation thresholds, deprecation, and
rollback. Placeholder embedding, reranking, live, or custom routes are not
advertised as deployed.

Publication States

  • draft: incomplete and internal only;
  • package_ready: artifact builds and validates;
  • staging: installed in a non-production environment;
  • customer_zero_verified: end-to-end evidence accepted;
  • submission_ready: listing, security, legal, and support assets complete;
  • submitted: external review pending;
  • published: publicly discoverable and verified;
  • deprecated: no new installs and a migration is supplied;
  • withdrawn: unavailable for new installs while history remains.

Publication Sequence

  1. Correct stale claims and superseded names.
  2. Generate artifacts from the canonical catalog.
  3. Validate packages and metadata in CI.
  4. Install privately or in staging.
  5. Run Customer Zero.
  6. Freeze version and evidence.
  7. Submit external listings.
  8. Verify public installation into a clean tenant.
  9. Monitor, support, and deprecate through versioned releases.

Third-party review is not part of the July 30 core product availability promise.