Unclassified
Spine Workspace final go-to-market and release plan
Status: Final product framing and evidence-gated release plan
Company: IntegrateWise
Product: Spine Workspace
Updated: 2026-08-20
Authority: Commercial and release plan, subordinate to the canonical architecture and its architecture index
Prerequisite: The Deployment Prerequisites defines the mandatory infrastructure, contract, and proof gates that must exist before any deployment event. This GTM plan cannot be executed until those prerequisites are satisfied.
This plan turns the final product framing into an executable release sequence. It distinguishes contracts and repository implementations from capabilities proven in a deployed tenant. It does not replace architecture doctrine or the current GTM canon.
1. Executive release decision
Decision: IntegrateWise may market the company, the Spine Workspace category, the connected-workbench vision, its mature domain experiences, and the governed product direction now. Customer Zero may privately activate selected surfaces behind explicit scope and support. IntegrateWise must not publicly release or imply the universal connection-reuse promise until identity, tenant isolation, consent, connection reuse, projection binding, action reconciliation, revocation, and clean-tenant evidence pass the gates in this plan.
Release posture by claim
| Posture | What may be said or used | Required qualification |
|---|---|---|
| Market now | IntegrateWise is the company. Spine Workspace is the product. It is a connected workbench with specialized role and domain surfaces. Spine is the tenant-wide organizational-context core. Existing surfaces include the browser Workbench and mature domain experiences. | Describe the product model and demonstrated UI or repository assets. Do not describe unverified substrate as live. |
| Private or Customer Zero only | Selected browser Workbench, platform controls, domain workbenches, connector flows, Twin experiences, MCP tools, and governed-action demonstrations. | Name the exact environment, tenant, providers, supported flows, limitations, operator involvement, and rollback path. |
| Do not claim or release | “Connect once and every authorized surface can reuse it” as a production fact; seamless cross-host discovery; complete provider coverage; live tenant-wide projection correctness; autonomous action; full proposal-to-reconciliation closure; clean-tenant portability; certifications, reliability levels, or outcome improvements without evidence. | These become claims only after the matching release gate has dated evidence. |
The release promise is non-negotiable:
One provider connection is created once per tenant, then reused by every authorized Workbench, product, agent, and artificial intelligence host through governed identity, consent, role-based access control, capability, provenance, and audit boundaries.
This promise is the release acceptance contract, not a current-state assertion.
2. Product packaging and surface strategy
Spine Workspace is one product with several connected interaction surfaces. A surface may specialize for a role, domain, host, or task. It may not create a second identity authority, provider grant, credential store, canonical truth store, projection authority, approval path, or audit history.
IntegrateWise (company)
└── Spine Workspace (product and shared tenant context)
├── Browser Workbench (primary complete experience)
├── Domain Workbenches (specialized projections)
├── Plugin / embedded host surfaces (focused interaction)
├── Public MCP distribution (semantic tools)
└── Connector Marketplace (tenant capability expansion)
Packaging rules
| Surface | Commercial job | Product boundary | Release rule |
|---|---|---|---|
| Spine Workspace | Primary product and subscription boundary | Tenant, membership, organizational context, governed capability access, provenance, audit, and continuity | Every other surface resolves this same product boundary |
| Browser Workbench | Primary activation, administration, and complete daily-work experience | Role and domain projection over shared Spine context | First complete proof surface; must show disclosed freshness and degraded states |
| Domain Workbenches | Deliver specialized workflows for Sales, Marketing, Account Success, Technical Account Success, Business Intelligence, Operations, Brand Store, and other mature domains | Adopters of shared identity, connection, Spine, projection, governance, and continuity contracts | Existing repositories and experiences are adoption targets, not reasons to rebuild them |
| Plugin and embedded host surfaces | Acquisition and focused work inside an AI host | Reduced or host-appropriate projection of the same tenant and governed contract | Must not imply feature parity; resolve overlapping audience and host-surface policy before listing |
| Public MCP distribution | Tool-first access and developer/AI-host distribution | The architecture-defined semantic public contract, never the internal MCP Pool | Exact tool surface, OAuth, tenant resolution, fallback, revocation, and support must be proven |
| Connector Marketplace | Add provider capabilities to an activated tenant | Catalog, consent, credential reference, connection lifecycle, schema binding, health, sync, and revoke | A listing is not “supported” until one connector passes its entire lifecycle |
Preventing product fragmentation
Every surface must consume a versioned workspace discovery contract and a tenant-scoped connection/capability projection. A domain surface may own its interaction design and workflow composition. The Platform owns identity resolution, tenant authority, provider connections, canonical promotion, projections, policy, execution coordination, reconciliation, and audit. A surface that cannot use those shared authorities remains a prototype or private legacy adapter.
3. Target markets, personas, and value narrative
The initial market is an organization with multiple operational systems, more than one work surface or AI host, and a material cost from repeated authentication, context reconstruction, and ungoverned action. Initial proof should favor a bounded workflow with an executive sponsor, an operating owner, and a security or platform owner.
| Persona | Pain | Spine Workspace value | Proof required |
|---|---|---|---|
| Executive sponsor, chief operating officer, chief information officer, founder, or AI leader | Fragmented systems and AI initiatives create duplicated work and uncontrolled risk | One organizational-context core and a governed path from context to outcome | Cross-system approved outcome, operating control, and adoption evidence |
| Operational leader | Teams reconstruct context and repeat setup across tools | A specialized Workbench starts from shared current context and reusable authorized connections | Time to first relevant answer and first approved outcome in the selected workflow |
| Daily operator | Work begins with searching, copying, and re-explaining | Role-appropriate prepared work with provenance and explicit approval | Daily-use cohort, freshness disclosure, reduced repeated setup, and completed receipts |
| IT, security, privacy, and governance | Credentials, AI access, and actions lack a coherent tenant boundary | Central identity, consent, role-based access control (RBAC), least privilege, revocation, provenance, and audit | Negative tenant tests, grant and revoke trace, audit packet, and incident drill |
| Developer and ecosystem partner | Every host and product needs bespoke integration | One supported connection, projection, and semantic capability substrate | Clean-tenant activation, versioned contracts, support path, and compatibility evidence |
Value narrative
- Connect once: create one provider connection for the tenant rather than one grant per product, Workbench, agent, and host.
- Understand together: Spine supplies authorized organizational context with source lineage, freshness, and completeness state.
- Work in the right surface: each role or domain receives a specialized projection without creating another product authority.
- Act under control: the Twin or another authorized participant may prepare and propose; a person approves consequential action.
- Close the loop: execution produces a receipt, provider state is re-observed, and reconciliation updates the governed projection.
The north-star metric is time to first approved governed outcome. A completed outcome requires a resolved tenant, an authorized reused or newly created connection, grounded context, a human approval, an execution receipt, and reconciliation. Installation, sign-in, or a successful model response alone does not count.
4. Current state and target state
The following state is grounded in this checkout. “Implemented” means repository evidence exists. It does not mean the capability is deployed, reachable, isolated, or proven.
| Capability | Current repository evidence | Evidence state | Release target |
|---|---|---|---|
| Product and domain surfaces | Browser, platform, marketing, One Access, role/domain configurations, and specialized domain assets exist | Implemented in multiple forms; maturity varies | Existing surfaces adopt one shared substrate and claims register |
| Shared connection registry | apps/platform/app/api/v1/connections/route.ts describes one provider connection per tenant and shared reuse | Scaffolded; not live verified | Authoritative registry with consent version, scopes, memberships, consumers, health, credential reference, revoke, and audit |
| Identity authority | Architecture decision D11 records a Clerk versus Descope conflict | Unresolved | One authority and migration/compatibility rule across browser, plugin, MCP, and domain surfaces |
| Tenant isolation | User-provided decision D12 remains unresolved; architecture requires negative isolation evidence | Unresolved and unproven | Chosen isolation model with test/prod separation and cross-tenant denial tests |
| Projection manifests | Workbench and Gateway projection code and tests exist | Implemented in parts | Tenant/RBAC/source-aware projection registry with explicit per-projection bindings and invalidation |
| Projection audiences | Browser, plugin, MCP, role, domain, and operational projection audiences overlap | Policy unresolved | One audience and precedence matrix with reduced-surface rules |
| Generic D1 projection reads | D1 is documented as bounded operational state; generic read paths remain a known risk | Not sufficient for release | Reads bind tenant, actor, role, source, projection, policy version, freshness, and completeness |
| Canonical promotion | Pipeline and Spine promotion contracts and code exist | Implemented in parts | Shared canonical-to-operational promotion with receipts, outbox, replay, and projection invalidation evidence |
| Governed action and reconciliation | Governance, Hermes, connector, workflow, and reconciliation code exists; architecture records Hermes reachability and loop gaps | Not end-to-end proven | Proposal → approval token → Hermes → provider → re-ingestion → reconciliation → projection refresh |
| Twin and agent runtime ownership | User-provided decision D13 remains unresolved; repository contains overlapping Twin/ADK/runtime ownership | Unresolved | One accountable runtime boundary that preserves the Twin and Authority Laws |
| Source attachment set | Repository documents reconcile an attachment set, but the delegated checkout does not expose an independently observable source attachment folder | Unobserved in this release review | Source inventory, checksums, authority classification, sensitive exclusions, and retained archive evidence |
| Customer Zero and clean tenant | Architecture defines the promotion sequence but no complete evidence packet is present in this review | Not live verified | Daily-use Customer Zero evidence followed by unrelated clean-tenant installation without code changes |
5. Delivery roadmap and dependencies
No calendar date overrides an exit criterion. A phase may run discovery work in parallel, but its release exit depends on all earlier authority and safety gates.
Phase 0: settle authority and release scope
| Field | Definition |
|---|---|
| Scope | Resolve D11 identity authority, D12 tenant isolation, D13 Twin/Agent Development Kit ownership, plugin audience, projection audience precedence, and external release scope |
| Owner boundary | Founder decides product/authority forks; Platform and Security propose implementable options; Product records surface consequences |
| Artifacts | Architecture decision records, authority matrix, tenant/isolation model, surface audience matrix, claims register, release support matrix, versioned scope |
| Entry | This plan accepted as the release operating plan |
| Exit | Each decision has one owner, chosen option, migration rule, compatibility rule, test obligation, and effective version |
| Evidence | Merged decision records linked from the canonical decision register; review sign-off from Product, Platform, Security, and release owner |
| No-go | Competing identity providers remain authoritative; tenant model is ambiguous; Twin and ADK can both own action; a public surface lacks an audience policy |
Phase 1: build shared identity, tenancy, consent, and connection authority
| Field | Definition |
|---|---|
| Scope | Canonical actor, tenant, workspace, membership, RBAC, consent, credential reference, provider connection, host binding, connection consumer, and revocation lifecycle |
| Owner boundary | Platform owns authority and registry; surfaces only request, bind, display, and revoke through Gateway contracts |
| Artifacts | Versioned schemas and APIs, migrations, credential indirection, consent receipts, consumer/binding registry, audit events, revocation cascade, adoption adapter for each selected mature surface |
| Entry | Phase 0 decisions merged |
| Exit | A tenant creates one provider connection; two authorized surfaces reuse it; an unauthorized actor and tenant cannot discover or use it; revoke removes capability and invalidates projections |
| Evidence | Contract tests, negative RBAC/tenant tests, credential rotation test, consent history, revoke trace, and deployed Customer Zero trace |
| No-go | Credentials enter browser or logs; reuse bypasses consent or capability scope; tenant is inferred from client input; test and production resources overlap |
Phase 2: prove connector runtime and Connector Marketplace lifecycle
| Field | Definition |
|---|---|
| Scope | Catalog, provider app, schema mapping, capability manifest, install, consent, initial hydration, delta sync, health, retry, dead letter, upgrade, disable, and revoke |
| Owner boundary | Connector Platform owns lifecycle and provider adapters; Marketplace owns discovery and activation UX; domain Workbenches consume projected capabilities |
| Artifacts | One reference connector, connector certification suite, listing schema, support/runbook, rate-limit behavior, health dashboard, provider change policy |
| Entry | Shared registry and revocation contracts pass Phase 1 |
| Exit | One real provider completes the full lifecycle in Customer Zero with no second provider grant when another surface adopts it |
| Evidence | Provider-side grant evidence, hydration counts, delta trace, failure and replay trace, health history, revoke and projection invalidation trace |
| No-go | Marketplace listing outruns runtime support; connector state can diverge silently; revoke leaves usable tokens, cached data, or capabilities |
Phase 3: close Spine promotion, read-model, and projection-registry gaps
| Field | Definition |
|---|---|
| Scope | Canonical-to-operational promotion, provenance, outbox, D1 read models, per-projection bindings, audience policy, freshness, completeness, invalidation, rebuild, and overlapping projection resolution |
| Owner boundary | Pipeline is the sole canonical writer; Spine owns canonical truth; Projection Platform owns reconstructable read models; surfaces never query stores directly |
| Artifacts | Promotion record, source and authority envelope, projection binding registry, projection audience matrix, invalidation event, rebuild command/runbook, degraded-state contract |
| Entry | One connector emits governed source evidence and structured updates |
| Exit | Two domain surfaces receive different authorized projections of the same canonical entity; changes invalidate both; rebuild yields equivalent read models; generic D1 access cannot bypass projection policy |
| Evidence | Golden trace from source to canonical promotion to projection, cross-role and cross-tenant negative tests, stale/degraded behavior, invalidation timing, rebuild equivalence |
| No-go | A projection lacks an explicit tenant/actor/audience/source binding; D1 is treated as canonical; freshness or partial state is hidden |
Phase 4: prove governed action, sync, reconciliation, and invalidation
| Field | Definition |
|---|---|
| Scope | Capability resolution, proposal, policy, approval token, Hermes coordination, provider execution, ambiguous outcome handling, receipt, re-ingestion, reconciliation, canonical promotion, and projection refresh |
| Owner boundary | Twin prepares; Governance authorizes; Hermes coordinates; connector executes provider semantics; Sync verifies outcome; Pipeline promotes; surfaces display state and receipts |
| Artifacts | Versioned action plan, scoped approval token, idempotency key, execution receipt, reconciliation record, unknown-outcome queue, governed replay, invalidation trace, operator runbook |
| Entry | Projection and connector lifecycle evidence is green |
| Exit | One material action completes end to end; an unapproved action fails closed; duplicate and ambiguous outcomes do not duplicate side effects; revoked access blocks execution |
| Evidence | One trace ID across every stage, approval identity and scope, provider evidence, reconciliation result, audit export, failure injection, replay and rollback exercise |
| No-go | Hermes is unreachable; any route bypasses approval; success is inferred without provider evidence; retries can repeat a side effect; projections remain stale |
Phase 5: integrate Twin, continuity, MCP, and mature domain adopters
| Field | Definition |
|---|---|
| Scope | Grounded context, silent Twin, public semantic MCP contract, plugin reduced surface, continuity, browser launch, and adoption by selected mature domain experiences |
| Owner boundary | Intelligence owns reasoning within D13; Platform supplies authorized context and capabilities; Product/domain teams own interaction and composition |
| Artifacts | Context envelope, provenance citations, Twin trigger policy, MCP conformance suite, plugin/browser handoff, domain adopter checklist, compatibility matrix |
| Entry | D13 resolved and governed action loop proven |
| Exit | Browser, one domain Workbench, and one AI-host surface resolve the same tenant, reuse the same authorized connection, receive correct projections, and preserve approval/receipt continuity |
| Evidence | Cross-surface trace, exact public tool listing, ordinary-client fallback, host denial tests, continuity handoff, silence and unsafe-action tests |
| No-go | Model output can become truth; a host receives unrelated credentials or projections; MCP exposes internal tools; a surface creates its own authority |
Phase 6: Customer Zero proof
| Field | Definition |
|---|---|
| Scope | Private activation followed by daily operational use across selected mature surfaces |
| Owner boundary | Customer Zero owns real workflow selection and feedback; Release owns support and evidence; Platform owns incident response |
| Artifacts | Activation plan, workflow baseline, daily-use cohort, support rota, incident log, evidence packet, claims candidates, go/no-go record |
| Entry | Phases 1 through 5 pass in an isolated Customer Zero environment |
| Exit | Defined users complete recurring work and multiple approved outcomes for the agreed proof window; failures, revokes, and support are handled through documented paths |
| Evidence | Usage and outcome traces, connection reuse rate, support tickets, reliability and latency, user interviews, approved screenshots, limitations, incident drill |
| No-go | Demo data substitutes for daily use; operators repair state manually without recording it; unsupported claims enter marketing; a critical incident lacks containment |
Phase 7: external clean-tenant beta
| Field | Definition |
|---|---|
| Scope | Install the frozen artifacts into an unrelated tenant with customer-owned identity, credentials, data, bindings, queues, caches, audit, and support |
| Owner boundary | External beta customer owns data and consent; Release runs activation; Security verifies isolation; Product observes without privileged shortcuts |
| Artifacts | Release manifest, clean-tenant installer, data-processing and support terms, tenant deletion/export path, beta limitations, rollback and offboarding runbook |
| Entry | Customer Zero daily-use exit accepted and versions frozen |
| Exit | External tenant reaches first approved reconciled outcome without code changes or Customer Zero state; offboarding, revoke, export, and deletion are proven |
| Evidence | Installation trace, resource inventory, isolation tests, customer consent, support history, outcome receipt, deletion/export evidence |
| No-go | Customer Zero data or credentials cross the boundary; tenant-specific code is required; privileged operator access is undocumented; legal terms are incomplete |
Phase 8: controlled marketplace and direct launch
| Field | Definition |
|---|---|
| Scope | Controlled direct activation, Connector Marketplace, public MCP and plugin submissions, launch assets, support, and staged availability |
| Owner boundary | Release controls versions and availability; GTM controls verified claims; Support owns intake; Platform owns live service; marketplace owners govern listings |
| Artifacts | Listings, product tour, developer docs, security packet, pricing/packaging decision, status page, support policy, release notes, compatibility and deprecation policy |
| Entry | Clean-tenant beta passes every mandatory gate and launch claims are evidence-backed |
| Exit | New tenant install and first outcome succeed under controlled availability; support and incident objectives hold through stabilization |
| Evidence | Marketplace review, production smoke trace, activation funnel, incidents, rollback test, support response, cohort retention and expansion |
| No-go | Any mandatory gate in section 8 is red; support capacity is absent; claims exceed evidence; marketplace install cannot be revoked cleanly |
6. Release train and surface availability
| Train stage | Eligible users | Browser Workbench | Domain Workbenches | Platform controls | Plugin/MCP | Connector Marketplace |
|---|---|---|---|---|---|---|
| R0 Internal foundation | Named employees and build operators | Development and synthetic test only | Adoption work only | Operator-only | Contract test clients only | Catalog and reference connector test only |
| R1 Customer Zero private activation | Named Customer Zero users | Selected workflows | Selected mature adopters | Restricted operators | Private installation; exact supported tools only | One approved connector path |
| R2 Customer Zero daily-use proof | Defined Customer Zero cohort | Daily use in agreed workflows | Add only after adopter gate | Support and audit use | Private cross-surface proof | Proven connectors only |
| R3 External clean-tenant beta | One or more contracted design partners | Guided beta | Only supported adopter surfaces | Customer admin subset plus internal operations | Private beta distribution | Supported reference connector(s) |
| R4 Controlled marketplace/direct launch | Approved waitlist or availability cohort | Production | Published supported surfaces | Customer admin and operator boundaries | Controlled listings and direct activation | Certified listings only |
| R5 Broader release | Eligible target market | General supported scope | Expand by evidence | Scaled admin/support | Broader availability | Expand providers after certification |
Promotion is one-way: source commit → internal artifacts → Customer Zero evidence → frozen release → clean tenant → controlled publication → broader release. Tenant data, credentials, bindings, runtime queues, caches, audit records, and evidence never promote between tenants.
7. GTM motions, channels, and readiness
Commercial motions
| Motion | Audience | Offer | Conversion event |
|---|---|---|---|
| Founder-led category and proof | Executive and operating leaders | Spine Workspace briefing tied to a real fragmentation problem | Qualified workflow, sponsor, operator, and control owner |
| Guided activation | Design partners and high-intent teams | Bounded provider, Workbench, and approved-outcome activation | First approved reconciled outcome |
| Domain-led adoption | Leaders already using or evaluating a mature surface | Connect that experience to shared tenant context and governed capabilities | Reused connection plus recurring domain workflow |
| Security and architecture evaluation | IT, security, privacy, procurement | Authority, isolation, data-flow, consent, revocation, and audit review | Approved beta scope and risk acceptance |
| Developer and ecosystem | Builders, AI-host users, integration partners | MCP, plugin, connector, and projection contracts | Clean installation or certified connector completion |
| Marketplace discovery | Users searching inside an AI host or connector catalog | Focused installation into the same Spine Workspace | Activated workspace, connection reuse/new consent, and first grounded value |
Use the website, founder/operator content, direct sales, guided demos, technical documentation, design-partner referrals, targeted communities, and controlled marketplace listings. Defer paid acquisition until activation, retention, support cost, and conversion are measured.
Required launch assets
- Product architecture and data-flow overview with current-state labels
- A product tour and backup recording showing connection creation or reuse, provenance, approval, receipt, and reconciliation
- Browser, plugin/MCP, connector, and domain-surface support matrix
- Identity, tenant isolation, consent, credential, RBAC, audit, retention, deletion, export, and incident security packet
- Developer quickstart, semantic MCP reference, connector certification guide, version compatibility, limits, and deprecation policy
- Sales discovery guide, qualification checklist, demo script, objection handling, procurement answers, and claims register
- Customer onboarding plan, administrator guide, operator guide, support route, status page, incident communications, and offboarding guide
- Release notes, known limitations, rollback criteria, revocation procedure, and launch-day operating roster
Onboarding promise
Onboarding must preserve the user’s original intent. It resolves identity and tenant, creates or reuses an authorized provider connection, records consent, starts hydration, discloses completeness, returns to the initiating task, and guides the user to a first approved outcome. Administrative completion without grounded value is not activation.
Pricing and packaging decisions
Do not invent prices or entitlements. Record decisions for:
| Decision | Required answer before controlled launch |
|---|---|
| Product unit | Is purchase tenant, workspace, member, active Workbench, capability, connector, outcome, usage, or a hybrid? |
| Included surfaces | Which browser and domain surfaces are included, and are plugin/MCP channels distribution or paid add-ons? |
| Connection economics | Is one shared provider connection included, tiered by provider class, usage, sync volume, or support burden? |
| Governance and audit | Which retention, policy, export, approval, and audit capabilities belong in each package? |
| Marketplace economics | Who pays for connector certification, provider usage, premium connectors, and partner revenue share? |
| Services | Which guided activation, migration, mapping, training, support, and custom connector work is packaged? |
| Beta conversion | What price protection, service level, data handling, term, and exit rights apply to design partners? |
| Limits | Which measured limits apply to members, sources, objects, sync, storage, actions, model use, and support? |
8. Mandatory release gates
Every gate requires an accountable owner, dated evidence, environment, version, result, and exception status. No blanket founder override may bypass identity, isolation, human approval, credential, data protection, or audit invariants.
| Gate | Required proof | Stop-ship condition |
|---|---|---|
| Identity and tenant authority | D11 and D12 resolved; actor/tenant/workspace/membership lifecycle; cross-tenant and impersonation negative tests | Competing authorities or client-controlled tenant selection |
| Connection and consent | One connection reused by two authorized surfaces; scoped consent receipt; credential rotation; consumer registry | Duplicate grant required, consent bypass, exposed credential, or unknown consumer |
| RBAC and capability | Least-privilege projection and capability tests; deny-by-default behavior | Unauthorized discovery, read, proposal, approval, or execution |
| Canonical truth and projection | Proven promotion, provenance, per-projection binding, invalidation, rebuild, freshness, partial/degraded states | Generic D1 read bypass, hidden staleness, or projection without audience binding |
| Governed action | Approval scope, Hermes reachability, provider receipt, reconciliation, replay, and no-action-without-token test | Approval bypass, blind retry, inferred success, or missing reconciliation |
| Security and privacy | Threat model, secret handling, encryption, retention, deletion, export, data processing, vulnerability response, access review | Critical unresolved finding, unbounded operator access, or absent customer data lifecycle |
| Reliability | Service objectives chosen; dependency failure, queue, retry, dead-letter, backup/restore, and capacity tests | Data loss, unbounded retry, no restore evidence, or unsupported load |
| Observability and audit | One trace across activation, read, approval, action, sync, and revoke; dashboards and alerts tested | Operators cannot identify affected tenant, connection, action, or release |
| Support readiness | Severity model, coverage hours, escalation, customer communications, runbooks, owner rota, and ticket rehearsal | No accountable responder or customer communications path |
| Legal and commercial | Terms, privacy notice, data-processing terms, subprocessors, provider terms, marketplace rules, acceptable use, beta and support terms | Offered scope lacks approved terms or conflicts with provider/marketplace obligations |
| Rollback and revocation | Version rollback, feature disable, connector revoke, credential rotate, tenant suspend, export/delete, and marketplace uninstall drills | Rollback risks canonical corruption or revoke leaves access active |
| Incident readiness | Tabletop covers credential compromise, cross-tenant exposure, bad action, provider outage, stale projection, and model safety issue | No containment, notification owner, evidence preservation, or recovery criterion |
| Release provenance | Exact commits, artifacts, checksums, migrations, environment bindings, compatibility matrix, source archive, and approvals | Unreproducible artifact, shared test/prod resources, or unobserved source dependency |
| Customer proof | Customer Zero daily use and unrelated clean-tenant first outcome with known limitations | Demo-only proof, tenant-specific code, or Customer Zero state copied externally |
9. Metrics and feedback loops
Outcome and activation metrics
- Median and 90th-percentile time to first grounded value
- Median and 90th-percentile time to first approved reconciled outcome
- Connection reuse rate: eligible surface bindings that reuse an existing tenant connection
- Duplicate-grant rate, with a target of zero for eligible reuse paths
- Activation completion by stage: identity, tenant, consent, connection, hydration, projection, first value, approval, receipt, reconciliation
- Approval-to-receipt and receipt-to-reconciliation completion rates
- Projection freshness, disclosed partial/degraded responses, and invalidation lag
- Connector health, sync failure, dead-letter, revoke completion, and credential rotation success
- Weekly active tenants, active members, active Workbenches, authorized surfaces per connection, and recurring approved outcomes
- Support contacts per activation, incident rate, mean time to detect, contain, recover, and notify
- Retention, expansion to a second surface/provider/domain, and design-partner conversion
Learning loop
Instrument the runtime states once and use them for product and GTM analysis. Review activation failures daily during private release, reliability and support weekly, claims and evidence weekly, and packaging monthly. Every customer interview should connect qualitative feedback to a trace or observed workflow when permission allows. Remove or narrow a claim when its evidence expires.
10. Decision and dependency register
| ID | Decision or dependency | Accountable owner | Blocks | Required record |
|---|---|---|---|---|
| D11 | Choose the browser and cross-channel identity authority: Clerk or Descope, with migration and compatibility policy | Founder + Identity Platform | Every activation and marketplace path | Canonical architecture decision |
| D12 | Choose tenant isolation model across database, D1/KV/R2/queues, Durable Objects, secrets, compute, and operator access | Founder + Platform + Security | Customer Zero isolation and all external tenants | Threat model, architecture decision, resource matrix, negative-test plan |
| D13 | Choose Twin/Agent Development Kit ownership and prevent two action authorities | Founder + Intelligence + Platform | Twin, continuity, agent, MCP, and action integration | Authority decision and runtime contract |
| D-PROJ-1 | Resolve overlapping browser, plugin, MCP, role, domain, and operational projection audiences | Product + Projection Platform | Surface composition and data minimization | Audience/precedence matrix |
| D-PROJ-2 | Define and implement per-projection binding registry | Projection Platform | Correct reads, invalidation, and audit | Schema, API, migration, and tests |
| D-CONN-1 | Define connection uniqueness, ownership, consent renewal, scope changes, consumer binding, and revoke cascade | Connector Platform + Security | Non-negotiable connect-once promise | Connection lifecycle contract |
| D-ACT-1 | Select one reachable Hermes execution path and ambiguous-outcome policy | Execution + Governance | Approved outcomes | Deployment binding, state machine, replay policy |
| D-EVID-1 | Locate and attest the source attachment folder or record it as unavailable | Architecture owner + Release | Reproducibility and source provenance | Inventory, checksums, authority disposition |
| D-PKG-1 | Decide commercial unit, entitlements, limits, marketplace economics, beta terms, and support | Founder + Finance + Product + GTM | Offer publication and contracting | Approved packaging and price book |
| D-SLO-1 | Select service, sync, action, revoke, support, and recovery objectives | Platform + Support + Security | External beta and support terms | Service objectives and error budgets |
The release owner maintains this register. A decision is closed only when its implementation and test obligations are linked, not when a meeting selects an option.
11. First 30, 60, and 90 days after Customer Zero starts
The clock begins when the first named Customer Zero cohort uses an isolated release candidate for real work, not when code merges.
Days 0 to 30: establish a trustworthy daily loop
- Activate one provider, one primary browser workflow, one mature domain adopter, and one bounded governed action
- Baseline the old connection/setup burden, workflow time, failure modes, and control requirements
- Verify connection create/reuse, consent, RBAC, provenance, approval, receipt, reconciliation, revoke, and support routes
- Run daily activation and incident review; repair severity-zero and severity-one gaps before adding scope
- Capture every manual operator intervention and convert it into a product requirement, runbook, or explicit limitation
- Produce the first evidence packet and decide whether the cohort can proceed to daily-use proof
Days 31 to 60: prove recurrence and cross-surface reuse
- Add recurring daily or weekly work and a second authorized surface using the same tenant connection
- Prove projection audience, invalidation, partial/degraded state, and continuity across browser and selected domain or AI-host surface
- Exercise credential rotation, connection scope change, provider outage, ambiguous action outcome, rollback, and incident communication
- Measure time to first outcome, reuse rate, approval-to-reconciliation completion, support load, and recurring use
- Freeze candidate claims only when evidence includes scope, environment, version, limitations, and permission
- Decide whether the product is ready for a frozen external clean-tenant candidate
Days 61 to 90: externalize without copying Customer Zero
- Freeze compatible product and platform versions and create the release manifest
- Install into an unrelated clean tenant using customer-owned identity, connections, credentials, data, bindings, and audit
- Prove first value, first approved reconciled outcome, revoke, export/delete, support, and offboarding without code changes
- Complete legal, security, pricing/packaging, support, marketplace, and launch asset decisions
- Review beta cohort economics and operational capacity
- Make a recorded go/no-go decision for controlled direct activation and marketplace submission
12. What is pending now
The mature product and domain repositories are not the critical path and should not be rebuilt. Treat IntegrateWise OS, AI Workspace, IntegrateWise Live, Business Intelligence, Account Success, Technical Account Success, Brand Store, IntegrateWise Ops, documentation, and other role/domain surfaces as adopters.
The critical path is the shared release substrate, in this order:
- Resolve D11 identity authority, D12 tenant isolation, and D13 Twin/ADK ownership.
- Turn the scaffolded tenant connection route into an authoritative identity, consent, connection, credential-reference, consumer-binding, audit, and revocation service.
- Prove one provider lifecycle once, then reuse the connection from at least two authorized surfaces.
- Implement explicit per-projection bindings and audience precedence; remove generic D1 reads that cannot prove tenant, actor, role, source, policy, freshness, and completeness.
- Prove shared canonical promotion, outbox, read-model rebuild, invalidation, and cross-surface projection refresh.
- Make Hermes reachable and close one proposal-to-approval-to-provider-to-reconciliation loop, including ambiguous outcomes and governed replay.
- Adopt the shared contracts in the browser Workbench and selected mature domain surfaces without rewriting their product value.
- Run Customer Zero private activation and daily-use proof.
- Freeze the release and prove an unrelated clean tenant with customer-owned state.
- Complete security, legal, support, reliability, observability, rollback, pricing, launch assets, and marketplace review before controlled publication.
Until these items have live evidence, the correct public posture is product vision plus verified surface proof, not a claim that the shared ecosystem promise is already delivered.
13. Evidence and operating references
- Canonical architecture
- Architecture index and authority hierarchy
- Current GTM canon
- Marketplace strategy
- GTM strategy
- Launch strategy
- Go-live and GTM operating plan
- Product/platform boundary and go-live standard
- Runtime substrate and surface contract
- Frontend platform API and discovery spec
- Plugin and MCP marketplace contract
- Source pack reconciliation
14. Authority and version note
The delegated request identifies INTEGRATEWISE_ARCHITECTURE.md as version 2.2. The file in this checkout identifies itself as version 2.1 dated 2026-07-31 and records D11 but not D12 or D13. This plan therefore treats the checked-out file as current local authority and records D12 and D13 as explicit user-provided release dependencies. It does not silently amend the canonical architecture. Before plan approval, reconcile the missing v2.2 source or update the canonical decision register through its normal authority process.