{"slug":"strategy/business-strategy/GO_LIVE_AND_GTM_PLAN","title":"Go-Live and GTM Plan","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/business-strategy/GO_LIVE_AND_GTM_PLAN.mdx","bytes":29666,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nStatus: EXECUTION PLAN — gated, not yet authorized for external launch  \nOwners: Founder (commercial go/no-go) · Platform (technical release) · Product Marketing (narrative)  \nLast verified: 2026-07-22  \nPrecedence: [Platform Lock v1.0](../architecture/PLATFORM_LOCK_v1.0.md) and the\n[Architecture Lock](../architecture/ARCHITECTURE_LOCK.md) govern product and\nruntime behavior. The [Commercial OS](../commercial/README.md) governs\npositioning, pricing, and launch claims.\n\n---\n\n## 1. Decision and purpose\n\nThis is the single operating plan for taking IntegrateWise from a source-ready\nplatform to a controlled technical release, design-partner proof, and then a\npublic narrative launch. It deliberately separates those moments:\n\n1. **Controlled technical availability** makes the supported SDK contracts and\n   governed services available only after their release gates pass.\n2. **Commercial proof** runs guided ecosystem activation around a material,\n   governed operational outcome. A specific Workbench or connector may be the\n   proof path; neither defines the product category.\n3. **Public T1 launch** introduces the _Operational Capability Platform for the\n   AI Era_: people, AI surfaces, systems, Workbenches, governance, and\n   continuity in one connected product story. It happens only after the proof\n   gate, not because a date arrived.\n\nNothing in this plan changes the product contract: the Spine remains the\nsource of truth; the Twin prepares and proposes but never acts without approval;\nand governance is a hard gate. External copy must use the terminology and\nclaims rules in the Commercial OS.\n\n## 2. Release scope\n\n### Supported public contracts\n\n| Surface                         | Consumer promise                                                                           | Boundary                                                                                                                      |\n| ------------------------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |\n| `@integratewise/sdk`            | Typed Gateway client for discovery, preparation, approval, and audit-aware action flows    | It does not expose direct provider execution. A caller resolves, prepares, and presents an approval before an action can run. |\n| `@integratewise/spine-schema`   | Shared TypeScript contracts for canonical Spine entities and workbench projections         | It is a schema contract, not a direct database client.                                                                        |\n| Gateway Platform catalogue      | Read-only discovery at `/api/v1/platform/*` for packages, services, endpoints, and OpenAPI | It exposes Gateway contracts only; Worker bindings, service addresses, provider credentials, and tenant data stay private.    |\n| Gateway and core Worker profile | Governed platform entry point and the supporting runtime path                              | Workers are deployed test first, production second, with Gateway last.                                                        |\n\nServices, connectors, worker internals, and implementation packages remain\nprivate. Frontends use the SDK and the Gateway; they do not import service code\nor acquire direct access to a provider.\n\n### Explicitly out of scope\n\n- A public claim that the whole product is generally available before the T1\n  launch gate passes.\n- Publishing an unverified package version, deploying with configuration\n  warnings, or overriding isolated-environment safeguards.\n- Adding product concepts or user-facing architecture labels outside the frozen\n  product grammar.\n- Paid acquisition, formal partner programs, or regional expansion before their\n  Commercial OS gates open.\n\n## 3. Current readiness record\n\nThe following is a dated evidence record, not a claim of launch readiness.\n\n| Area                  | Evidence as of 2026-07-22                                                                                                                             | State     | Required next result                                                                                                                                                        |\n| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Source baseline       | Public SDK/schema preparation is on `main` at `e0a4e3e0`; the worktree was clean when recorded.                                                       | Green     | Tag the exact release commit once versions are approved.                                                                                                                    |\n| Package quality       | `pnpm release:packages:check` passed: both public packages typecheck, build, test where applicable, and produce inspected tarballs.                   | Green     | Repeat on the release commit.                                                                                                                                               |\n| Static release shape  | `pnpm release:check -- --environment test` and `prod` passed.                                                                                         | Green     | Repeat before each release.                                                                                                                                                 |\n| npm registry          | The active environment is not authenticated to the `@integratewise` npm scope. No package was published.                                              | Blocked   | Authenticate to the correct organization, verify package ownership and new versions, then run the guarded publish workflow.                                                 |\n| Cloudflare validation | Core test dry-run found seven Wrangler warning sets; the matching prod dry-run found eight. Neither dry run published a Worker.                       | Blocked   | Correct every warning; a warning-free dry-run is mandatory.                                                                                                                 |\n| Test isolation        | Core test bindings still share production D1, KV, Queue, Vectorize, and Secrets Store resources; some test service bindings also target legacy names. | Blocked   | Provision/use isolated test D1, KV, Queue, R2, Vectorize, Durable Object, secret, and service-binding targets; apply migrations and verify no test/prod resource is shared. |\n| Remote rollout        | No new test or production release is authorized by this plan.                                                                                         | Pending   | Complete the technical go/no-go gates below.                                                                                                                                |\n| Public launch proof   | Customer activation, design-partner outcomes, security packet, demo readiness, website, and marketplace status are not yet recorded as complete here. | Not ready | Meet and evidence every T1 launch gate in §7.                                                                                                                               |\n\n**Decision now:** technical rollout is **No-Go** until npm authentication,\nwarning-free configuration, and strict test/production isolation are evidenced.\nPublic T1 launch is **No-Go** until its commercial proof gate is complete.\n\n## 4. Technical go-live gates\n\nEvery item below needs an owner, a dated evidence link, and a recorded result in\nthe release issue or change record. A failure keeps the release at its current\nstage; it is not bypassed with a blanket override.\n\n| Gate                        | Accountable function      | Exit evidence                                                                                                                                                            |\n| --------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Release scope frozen        | Founder + Platform        | Exact commit, package versions, supported endpoints, and customer-facing change summary approved.                                                                        |\n| Build and package integrity | Platform                  | `pnpm release:packages:check` passes on the exact commit; tarballs contain no secrets, environment files, or implementation-only dependencies.                           |\n| Registry authorization      | Release owner             | `@integratewise` organization access verified; each package version is new; provenance/access policy is confirmed before publish.                                        |\n| Environment separation      | Platform                  | A binding inventory proves test and prod use different D1, KV, Queue, R2, Durable Object, secret, and service-binding targets. Test migrations are applied only to test. |\n| Configuration correctness   | Platform                  | `pnpm release:check` passes for test and prod and Cloudflare dry-runs complete with **zero** warnings.                                                                   |\n| Test deployment             | Platform                  | Core profile deployed in the locked order to test, with Gateway last; health, route, connector, queue, storage, and service-binding checks pass.                         |\n| Governance proof            | Product + Platform        | An approved action completes with a receipt; an unapproved action fails closed; audit/provenance is visible.                                                             |\n| Security and tenancy        | Platform + Security owner | Authentication, tenant boundaries, CORS/origin policy, secret rotation path, least-privilege bindings, and public security packet reviewed.                              |\n| Operational readiness       | Platform                  | Dashboards, alerts, on-call contact, incident template, rollback procedure, and an immutable source archive/checksum are ready.                                          |\n| Production authorization    | Founder                   | Test evidence reviewed, customer impact assessed, production approval explicitly recorded, and the production confirmation mechanism used.                               |\n\n### Required release sequence\n\n1. **Repair configuration before deployment.** Produce one environment-binding\n   inventory per core Worker. Create or select the isolated test resources,\n   migrate them, seed only synthetic test data, and update every test binding.\n   Do not reuse production IDs or secrets to make a test dry-run pass.\n2. **Establish a clean test candidate.** Run the package checks and both static\n   release checks. Then run the core test dry-run until it has zero warnings.\n3. **Publish the public package versions.** After registry authentication and\n   package/version confirmation, publish only the two supported packages via the\n   guarded package workflow. Record package names, exact versions, shasums, and\n   release commit.\n4. **Deploy and prove test.** Deploy the test core profile in canonical order:\n\n   ```text\n   pipeline → connector → mcp-connector → connector-sync → knowledge\n   → continuity → intelligence → workflow → l2 → gateway\n   ```\n\n   Validate the Gateway and the full governed path with synthetic tenant data.\n\n5. **Review before production.** Compare test configuration and behavior with\n   production without copying test resources into production. Confirm rollback\n   owner, known limitations, and customer communication path.\n6. **Deploy production only under explicit approval.** Use the canonical `prod`\n   environment and production confirmation. Deploy the same sequence with\n   Gateway last, run post-deploy health checks, and record the deployed Worker\n   versions and package versions.\n7. **Observe and stabilize.** Keep the release owner on the operational cadence\n   through the agreed stabilization period. Roll back a Worker version or issue\n   a compatible package patch if a release gate regresses; never erase customer\n   data to recover from a release.\n\nThe detailed commands and guardrails live in\n[Package and Deployment](PACKAGE_AND_DEPLOYMENT.md). This plan owns the\ndecision gates; that runbook owns the mechanical release procedure.\n\n## 5. Controlled availability and design-partner motion\n\nThe post-technical-release motion is category-led, activation-assisted, and\nproof-gated: establish the platform story, activate a bounded connected\necosystem around a material operational problem, prove a governed outcome, then\nexpand through more Workbenches, capabilities, and systems. Customer Success,\nHubSpot, or any other supported path can supply proof; none is the public\ncategory or mandatory first route. Self-serve is an entry point only where the\nactivation journey is genuinely supported.\n\n| Stage                         | Goal                                                                    | Entry condition                 | Exit evidence                                                                                                                         |\n| ----------------------------- | ----------------------------------------------------------------------- | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |\n| P0a — controlled availability | Safely serve the supported SDK/Gateway path and first design partners.  | All technical gates in §4 pass. | Stable test/prod operation, support route tested, and each external user has an explicit enablement path.                             |\n| P0b — prove                   | Turn real operational work into verified platform value.                | P0a stable.                     | Permissioned outcomes across more than one applicable operational pattern; a repeatable activation checklist; evidence for expansion. |\n| P1 — repeat                   | Demonstrate a repeatable discovery → activation → first-outcome motion. | P0 exit criteria met.           | Consistent sponsor/work-owner/control-owner pattern, delivery capacity, conversion/retention evidence, and approved case material.    |\n| P2 — compound                 | Expand from a proven platform motion.                                   | P1 exit criteria met.           | Cohort expansion, supportable partner motion, and channel economics meet Commercial OS gates.                                         |\n\n### Founder operating cadence during P0\n\nFavor direct learning over volume: customer/operator discovery and guided\nactivations; category and proof content; technical/security conversations; and\na weekly evidence/claims review. The allocation follows active pipeline and\nrelease readiness, not a fixed Customer Success quota. Partnership work remains\na seed motion until the core activation-to-outcome path is repeatable.\n\n### Design-partner evidence packet\n\nFor every participant, capture permission and a before/after baseline before\nthe POV begins. The evidence packet contains:\n\n- ICP fit, connected-system scope, champion, economic buyer, and success\n  criteria.\n- Baseline time, cost, risk, and operating context for the selected workflow.\n- A recorded governed-action demonstration: evidence → proposal → human\n  approval → execution receipt.\n- Activation and usage evidence, including the first completed outcome.\n- Outcome measurement, customer quote approval, limitations, and the decision\n  to convert, extend, or exit.\n\nOnly verified, attributed outcomes enter public copy or the claims register.\n\n## 6. GTM execution plan\n\n### Audience, offer, and narrative\n\n| Element          | Operating choice                                                                                                                  |\n| ---------------- | --------------------------------------------------------------------------------------------------------------------------------- |\n| Category         | **The Operational Capability Platform for the AI Era.**                                                                           |\n| Primary audience | Executive sponsors, operational leaders across the twelve Workbenches, IT/security/governance, and developers/ecosystem partners. |\n| Buying motion    | Category demand → qualified operational problem → bounded ecosystem activation → governed outcome → expansion.                    |\n| Core promise     | One governed fabric connects people, AI surfaces, systems, data, Workbenches, and approved outcomes.                              |\n| Trust boundary   | The Twin prepares; the human approves. Every consequential action is governed and auditable.                                      |\n| Calls to action  | Explore Platform, Workbenches, Capabilities, Ecosystem, or Developers; start only a supported activation with clear scope.        |\n\nEvery external asset must show how fragmented AI, people, and systems become a\ngoverned operational capability; carry evidence within two sentences; and give\none next step. Use the platform, Workbench, ecosystem, governance, and\ncontinuity language from the [Current GTM Canon](../commercial/09-gtm/00-current-gtm-canon.md).\nDo not expose internal runtime labels, provider credentials, or unsupported\ncoverage claims.\n\n### Channel plan\n\n| Channel              | P0 action                                                                                                    | Gate / measure                                                                    |\n| -------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- |\n| Founder-led sales    | Qualify cross-system problems with executive, work-owner, and technical/control champions.                   | Qualified activation, first outcome, proof, and expansion quality.                |\n| Founder-led content  | Publish platform, Workbench, capability, ecosystem, developer, governance, and continuity proof.             | Conversations and qualified demand, not impressions alone.                        |\n| Customer proof       | Turn permissioned outcomes into attributable case material only after review.                                | Evidence across more than one operational pattern before public T1 launch.        |\n| Community/newsletter | Nurture operators, executives, builders, and control owners solving ecosystem fragmentation.                 | Subscriber quality, reply/conversation rate, and sourced opportunities.           |\n| Marketplace          | Prepare listings only for supported public integration or activation paths with clear ownership and support. | Listing is optional proof, not a T1 launch requirement.                           |\n| Partners             | Warm ecosystem architects and operational/technical partners aligned to supported capabilities.              | Seed only; no formal program before direct-motion proof and organic wins.         |\n| Events               | Use precise operating and developer audiences; measure booked conversations and activation quality.          | Qualified meetings and follow-up conversion.                                      |\n| Paid acquisition     | No spend in P0/P1.                                                                                           | Revisit only after activation, conversion, and retention economics are evidenced. |\n\n### Asset and enablement backlog\n\nBefore an external technical announcement or customer campaign, the accountable\nowner must complete and link the following assets:\n\n- Release note and developer quickstart for the supported SDK contracts.\n- Current product tour and a backup recording that shows a governed path and\n  the fail-closed refusal.\n- Sales, security, procurement, and developer enablement updated for the exact\n  release scope.\n- Website information architecture for Platform, Workbenches, Capabilities,\n  Ecosystem, Developers, Resources, Pricing, sign-in, and activation.\n- A current claims register covering public counts, logos, certifications,\n  named providers, authentication, and roadmap language.\n- Permissioned proof templates, an escalation route, and press/product-launch\n  assets reserved for the later T1 gate.\n\n## 7. Public T1 launch gate and run of show\n\nThe public launch remains a **No-Go** until every condition below is marked\ncomplete with evidence. It is the Commercial OS gate, reproduced here so the\ntechnical and GTM teams make one decision.\n\n- [ ] The technical go-live gates in §4 remain green in production.\n- [ ] The public Platform, Workbenches, Capabilities, Ecosystem, Developers,\n      Resources, and Pricing/activation surfaces reflect current product scope.\n- [ ] A current product tour and fallback recording show a supported path from\n      context through a governed capability to a human-approved receipt.\n- [ ] At least two permissioned proof cases cover meaningful operational work;\n      they include limitations as well as outcomes.\n- [ ] Developer documentation and public contracts accurately state package,\n      Gateway, API, webhook, and capability boundaries.\n- [ ] Security, identity, approval, tenancy, audit, support, incident, and\n      rollback material is current for the offered scope.\n- [ ] All public counts, logos, certifications, named providers, authentication\n      claims, and roadmap language have a current evidence record—or are\n      removed or clearly marked as roadmap.\n\nOnce the gate passes, set a launch date and use this relative schedule:\n\n| Window       | Deliverable                                                                                                                               | Accountable function     |\n| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------ |\n| D−21 to D−14 | Lock product proof, platform navigation, demo/recording, developer path, security materials, claims, support coverage, and outreach list. | Founder + Platform + PMM |\n| D−7          | Publish the platform/category narrative through the site, founder channels, and newsletter.                                               | Founder + PMM            |\n| D-day        | Publish the platform overview and product tour; route executive, operator, technical, and developer audiences to the right proof surface. | Founder + PMM            |\n| D+1 to D+5   | Publish one proof asset daily: Workbench, capability, ecosystem, developer access, governance, or continuity.                             | Founder + PMM            |\n| D+7          | Publish only permissioned case material and an honest operating learnings post.                                                           | Founder + Product        |\n| D+14         | Complete launch retro: audience quality, activation, incidents, evidence gaps, and the next 30-day operating plan.                        | Founder + all owners     |\n\nDuring launch day, the founder runs 30-minute triage cycles with one owner for\nsite/product health and one for response/escalation. A product incident uses\nthe prepared status and incident communication path; a backup product film\nkeeps the narrative honest while the service is repaired.\n\n## 8. Scorecard and review rhythm\n\n### Technical release scorecard\n\n| Measure                   | Green condition                                                                                           |\n| ------------------------- | --------------------------------------------------------------------------------------------------------- |\n| Package release integrity | Public package checks pass on the shipped commit and published versions resolve/install as expected.      |\n| Environment safety        | No shared test/prod stateful bindings; no warning overrides.                                              |\n| Governed execution        | Approved actions complete with an auditable receipt; unapproved actions fail closed.                      |\n| Service health            | Gateway and core dependencies meet their approved health/readiness checks throughout stabilization.       |\n| Recovery                  | Alerts route to an owner and the rollback procedure has been exercised or reviewed for the exact release. |\n\n### Commercial scorecard\n\nThe P0/P1 phase exit criteria are the primary GTM scoreboard. For the T1 launch,\ntrack qualified platform evaluations by audience, activation requests,\nproduct-tour completion, time to first governed outcome, developer-doc\nactivation, support response, proof conversion, and any claim corrections\nrequired after launch. Compare every number to the Commercial OS definitions;\ndo not introduce a public target or claim that has not been verified.\n\n| Cadence                 | Review                                                                           | Decision                                                     |\n| ----------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------ |\n| Every release candidate | Technical gate review and binding diff.                                          | Advance, remediate, or stop technical rollout.               |\n| Weekly in P0            | Operational proof outcomes, activation, support signals, and pipeline.           | Adjust activation; preserve scope discipline.                |\n| Monthly                 | Founder-time allocation, channel quality, proof inventory, and claims freshness. | Reallocate effort only within P0 constraints.                |\n| At public-launch gate   | Evidence review across technical, product, security, and commercial owners.      | Set date or retain No-Go.                                    |\n| D+14 and D+30           | Launch and activation retrospective.                                             | Feed durable content, sales, product, and ecosystem motions. |\n\n## 9. Authority, communications, and rollback\n\n| Decision                           | Decision owner | Required consultation                                       |\n| ---------------------------------- | -------------- | ----------------------------------------------------------- |\n| Technical test rollout             | Platform owner | Product and security owner                                  |\n| npm package publication            | Release owner  | Platform owner and Founder                                  |\n| Production rollout                 | Founder        | Platform, product, and security owner                       |\n| External technical announcement    | Founder / PMM  | Platform validates scope and claims                         |\n| Public T1 launch date              | Founder        | Platform, PMM, Product, Security, Developer/Ecosystem owner |\n| Rollback or incident communication | Platform owner | Founder; customer-facing owner for material impact          |\n\nNo external announcement may imply that a capability is live before the\nmatching production gate has passed. No release may use a customer environment\nas a test environment. If a technical, security, or governance gate regresses,\npause the campaign, communicate the verified state, and resume only after the\nrelease decision is green again.\n\n## 10. Immediate next actions\n\n1. Create the environment-binding inventory and remediate the seven Cloudflare\n   warning groups, beginning with the test-to-production Spine D1 overlap.\n2. Provision/migrate isolated test resources and complete a warning-free test\n   dry-run for the core profile.\n3. Confirm npm organization access, approve the initial public package versions,\n   and run the guarded public package release on the tagged release commit.\n4. Deploy to test, execute the governed-action and fail-closed acceptance\n   scenarios, then submit production evidence for explicit approval.\n5. Build the Platform, Workbenches, Capabilities, Ecosystem, Developers,\n   Resources, and Pricing/activation launch surfaces; reconcile every public\n   claim with the claims register.\n6. Start/continue guided ecosystem activations and create permissioned evidence\n   packets; do not schedule public T1 launch until the proof gate is complete.\n\n---\n\n## Related sources\n\n- [Package and Deployment](PACKAGE_AND_DEPLOYMENT.md)\n- [Architecture Lock](../architecture/ARCHITECTURE_LOCK.md)\n- [Platform Lock v1.0](../architecture/PLATFORM_LOCK_v1.0.md)\n- [Current GTM Canon](../commercial/09-gtm/00-current-gtm-canon.md)\n- [GTM Strategy](../commercial/09-gtm/50-gtm-strategy.md)\n- [Launch Strategy](../commercial/09-gtm/51-launch-strategy.md)\n- [Product Marketing Guide](../commercial/04-product-marketing/20-product-marketing-guide.md)\n- [Annual GTM Plan](../commercial/13-operations/77-annual-gtm-plan.md)\n"}