Product–Platform Boundary and Go-Live Standard
Status: SUPERSEDED — absorbed into INTEGRATEWISE_ARCHITECTURE.md v2.1. Historical reference only.
Date: July 28, 2026
Purpose: Turn the canonical Product/Platform separation into release gates, ownership rules, and a minimum viable production sequence.
1. Decision
IntegrateWise has one product experience and one platform authority:
Product (Workbench experience)
→ versioned Platform contracts
→ Platform capability and governance
→ configured provider adapters and connected systems
The Product owns what a person sees and does in the Workbench. The Platform owns the truth path, capability resolution, configuration, integrations, identity, governance, execution, and reconciliation. Providers implement configured adapters; they do not define product behavior.
This standard resolves the operational question behind that boundary: a frontend repository may contain local operational implementation state, but it must never become an independent authority for tenant configuration, provider selection, credentials, agent memory, canonical operational truth, or execution approval.
2. Authority and storage wall
| Concern | Authoritative owner | Product may do | Product must not do |
|---|---|---|---|
| Canonical operational truth, relationships, lineage, approvals, promoted outcomes | Adaptive Spine in Platform (Neon) | Render scoped projections; submit observations through Gateway | Query or write canonical tables directly |
| Raw evidence, files, attachments | Platform evidence store (R2) | Upload and display authorized artifacts through contracts | Treat browser storage or app data as evidence authority |
| Active context, idempotency, projection snapshots, runtime indexes | Platform bounded operational state (D1/KV) | Read contract results and show freshness/partial-evidence state | Promote cache state to canonical truth |
| Presentation-only operational state | Product repository/runtime | Maintain form state, UI preferences, optimistic display state, and route-local view models | Persist a competing business record, approval, or synchronization authority |
| Tenant runtime, environment, provider/model selection, feature and policy configuration | Configuration Manager | Display effective configuration to authorized operators | Choose a provider, model, environment, or memory system in browser code |
| Connections, OAuth lifecycle, connector health, schema mapping, sync | Integration Manager | Start and monitor an authorized connection flow | Store credentials, duplicate an existing tenant connection, or implement provider transport in the UI |
| Twin memory and active context | Continuity/Memory Platform contracts | Request permitted context and display grounded responses | Decide where memory lives or inject hidden provider-specific memory |
| External mutation | Governance → Hermes → connector | Create intent, present proposal, collect explicit approval | Call a provider API after approval or bypass the approval token |
Rule: “Operational DB in the frontend repo” is acceptable only as implementation location for non-authoritative Product state. Its schema, tenancy, access, retention, and synchronization behavior remain governed by Platform contracts. It cannot define platform truth.
3. Runtime contract
Configuration Manager resolves tenant policy and active adapters
→ Integration Manager resolves reusable tenant connections and capabilities
→ Pipeline normalizes inbound source data
→ Adaptive Spine holds promoted truth
→ Projection Engine composes the role-aware Workbench response
→ Twin reasons only over permitted, grounded context
→ Governance validates a proposed action
→ explicit approval yields an approval token
→ Hermes executes through the resolved connector
→ sync and pipeline promotion reconcile the outcome
The Workbench only knows Entity, Projection, Capability, Signal, Context, and Twin. It does not know database vendors, AI vendors, OAuth tokens, connector SDKs, or the environment-selection algorithm.
3.1 Infrastructure partitions
Two infrastructure purposes must be isolated. They may use the same platform code and Marketplace application, but they must not share tenant data, credentials, queues, caches, database bindings, or deployment authority.
| Partition | Purpose | Required isolation |
|---|---|---|
| Product engineering | Build, CI/CD, local development, integration testing, staging, and platform administration | Non-production credentials and seeded/test tenants only; cannot operate Customer Zero sources |
| Customer Zero operations | IntegrateWise operating its own business through the product | Dedicated iw-customer-zero tenant, production-grade credentials, data, audit, queues, and runtime policies; cannot be used as generic test data |
| Customer production tenants | Customer-facing production operation | Separate tenant-scoped canonical data, connections, credentials, policies, and capability grants |
| Connector Marketplace | Shared product surface for catalog and activation | May be one application, but its catalog, install state, and every activation must resolve within the requester’s partition and tenant |
The internal MCP Pool is Platform/Customer Zero operational infrastructure; it is not a general customer-facing control plane. Other tenants consume the governed Spine Network interfaces: Gateway projections and capabilities, the public OAuth-protected 19-tool Spine MCP where applicable, and the ADK/Twin runtime behind those contracts. No tenant imports or discovers the Pool’s internal topology.
3.1.1 Deployment and distribution law
IntegrateWise may deploy multiple Product applications: role-specific Workbench apps, onboarding, Marketplace, marketing, or full-stack product applications. They may be hosted on Vercel, Netlify, or another compatible edge host. That is a Product delivery choice, not a Platform deployment.
Every such application uses the same rule:
Product app on any host
→ authenticated Gateway / public Spine Network contract
→ Cloudflare-hosted Platform services and Fortress state
→ configured provider adapters
- The Fortress, canonical Spine, Gateway, configuration, integration, governance, Hermes, sync, and internal MCP Pool remain Cloudflare-hosted Platform services.
- A full-stack Product app may have its own route handlers for presentation, authentication hand-off, and backend-for-frontend work, but it must not become a second Platform, connector runtime, credential wall, canonical writer, or execution path.
- A hosting fallback improves Product availability; it does not duplicate the Platform or permit direct access to provider services.
- Product apps must use the published versioned contract; host-specific environment variables only identify the Gateway and public identity configuration.
3.1.2 Marketplace publishing model
The public distribution identity is IW-Spine-Network. It is published as
two artifacts over the same IW Spine Tools contract:
- IW-Spine-Network Plugin in plugin marketplaces/directories;
- IW-Spine-Network MCP in MCP marketplaces/registries.
When a user installs either artifact, the deployment model is:
Plugin install or MCP connection
→ quick Customer Zero-like self-provisioned deployment
→ identity + tenant resolution
→ apply Customer Zero-proven reference activation profile to isolated tenant
→ host-embedded Plugin UI or browser-based MCP Workbench is created
→ Discovery advertises permitted projections and capabilities
→ explicitly delegated or directly connected systems join Spine Network
→ user selects additional connector only when required
→ Configuration + Integration + Activation compile the active workspace
ChatGPT control surface: when ChatGPT is the host, ChatGPT controls the
conversation and declared app orchestration through the sandboxed IW MCP App
UI. It does not grant IW direct access to ChatGPT's DOM or other app
credentials.
Standalone MCP marketplace lane: when the user installs from an MCP registry/directory, IntegrateWise provides its own browser-based software instead of relying on the host’s native UI.
Marketplace channels fall into three categories:
| Channel type | Examples named in the product strategy | Published artifact | What it must never do |
|---|---|---|---|
| Plugin marketplaces/directories | ChatGPT/Codex and compatible AI hosts | IW-Spine-Network Plugin: MCP-backed app, focused embedded UI, skills and optional templates | Claim DOM access, inherit unrelated app credentials, expose the internal Pool or execute without approval |
| MCP marketplaces/registries | MCP Registry and compatible MCP directories/clients | IW-Spine-Network MCP: remote 19-tool server, optional MCP App UI resources and browser Workbench launch | Publish the 55-tool internal Pool or require ChatGPT as the controller |
| Tool/developer marketplaces | Vercel, Notion, Coda, GitHub and compatible hosts | Appropriate IW native package and inbound connector when required | Create a separate canonical store or force the customer to adopt a particular database, model, or infrastructure vendor |
Marketplace eligibility, packaging, review requirements, and current publisher policies vary by channel and must be confirmed per listing before release. The architecture stays the same across all of them.
The plugin's embedded UI is a sandboxed MCP App surface. The browser Workbench
is the full standalone UI for the MCP-marketplace lane. Both use the same
Gateway and tenant truth. Host-connected apps join persistent discovery only
through explicit host delegation or a direct IW connector binding.
Vercel Marketplace package
For the Vercel channel, publish a provider integration called
IW-Spine-Network with a native product called IW-Spine-Network MCP. This
is the required package when the intended user experience is: install
IntegrateWise in Vercel, then use its governed Spine tools through Vercel Agent
Tools.
| Published component | Why it exists | Platform implementation |
|---|---|---|
| IW-Spine-Network listing | Marketplace discovery, legal/support metadata, install entry point | Listing metadata, documentation, privacy policy, EULA, support contact, configuration and redirect URLs |
| IW-Spine-Network MCP native product | Makes the approved IW MCP tool surface available to an installed Vercel team through Agent Tools | Cloudflare-hosted native-integration server plus the OAuth-protected public 19-tool IW Spine Tools MCP contract |
| Vercel connector | Brings authorized Vercel project/deployment/operational context into IntegrateWise | Integration Manager connector; it normalizes Vercel data through Pipeline and exposes governed Vercel capabilities |
| Installation and configuration surface | Lets a team choose the IW tenant/workspace, permitted Vercel projects, sync policy, and activation scope | Cloudflare-hosted configuration application; invokes Configuration, Integration, and Activation Managers |
| Webhook endpoint | Receives Vercel installation, lifecycle, and allowed resource events | Verified ingress → Gateway → Integration Manager/Pipeline; no browser-mediated secrets |
| MCP tool manifest | Declares the semantic tools exposed in Vercel Agent Tools | Maps only to the frozen public IW Spine Tools; never exposes internal Pool/provider/credential tools |
The Marketplace product and Vercel connector are two directions of one connection:
Vercel Agent Tools → IW-Spine-Network MCP native product → Gateway → permitted Spine context/capabilities
Vercel project events/data → Vercel connector → Pipeline → Spine → Workbench/Twin
Vercel installation, consent, and identity
Vercel team installs IW-Spine-Network MCP
→ Vercel installation identity is verified server-to-server
→ user signs in to IntegrateWise or creates an IW tenant
→ administrator selects target IW tenant/workspace and permitted Vercel projects
→ consent records scopes, source access, policy, and data-sharing purpose
→ Installation ↔ IW tenant/workspace ↔ Vercel connection is recorded
→ MCP tools and Vercel connector are enabled through Discovery
Required records are: Vercel installation/team reference, IW tenant/workspace reference, connection id, allowed project/resource scope, granted capabilities, consent/policy version, credential reference, and audit lineage. Secrets and access tokens remain in the credential wall; they are never published to the listing, browser, or MCP tool result.
The IW user login remains the canonical human identity. The Vercel installation identifies the Vercel team and installation, not an independent IntegrateWise tenant. Reinstallation receives a new installation identity and must repeat the binding/consent flow.
3.1.3 Provider-neutral connector tray
The Workbench and Marketplace show a connector tray/catalog based on what the tenant is permitted to use. A user chooses a desired system or capability; they do not select an infrastructure implementation that IntegrateWise has hard-coded as mandatory.
User intent / selected tool
→ Integration Manager identifies compatible connector contracts and existing connections
→ Configuration Manager resolves tenant policy, provider choice, and environment
→ Activation Bridge compiles the enabled capability into the Workbench
→ Gateway/Capability Fabric routes the request to the resolved adapter
No Product app requires Neon, Supabase, a particular blob store, a particular model provider, or a particular agent-mail provider. Those are provider choices made through configuration and connection policy. The user-facing choice is the operational system or capability they want to connect; the Platform resolves the implementation behind it.
3.2 Required access, credential, and connectivity matrix
Everything below must be provisioned, scoped, stored outside the browser, and testable before an integrated environment event.
| Boundary | Required prerequisite | Owner | Verification |
|---|---|---|---|
| Browser → Workbench | Public runtime URL, Clerk publishable key, Gateway base URL, CSP/CORS allowlist | Product + Identity | User can sign in and obtain a tenant-scoped session without a secret in browser storage |
| Workbench → Gateway | Versioned Platform client, Clerk session/JWT forwarding, request correlation, API error/freshness contract | Product + Gateway | Every UI read/action reaches Gateway; no browser-to-Neon/provider traffic |
| Gateway → internal services | Service bindings, internal service identity, typed request/response contracts, environment routing | Platform | Gateway can reach only allowlisted internal services in the same partition |
| Gateway → Spine/projection | Neon connection, R2 binding, D1/KV bindings, migrations, projection cache/invalidation | Spine + Gateway | Authorized projection is tenant-scoped, provenance-bearing, and returns an explicit partial state on cache/source failure |
| Connector → provider | Registered connector, tenant-owned OAuth client or API key reference, callback URL, scopes, encryption/secret binding, webhook signature secret, rate limits | Integration Manager | Connection test, health check, schema discovery, initial load, delta sync, and revoke/rotate test pass |
| MCP consumer → public IW Spine Tools MCP | OAuth client registration, redirect/callback configuration, audience/scopes, session/transport endpoint, tenant and user authorization | MCP Connector + Identity | Unauthenticated or cross-tenant calls fail; the authenticated catalog exposes exactly the 19 public semantic tools |
| Internal MCP Pool → capability provider | Service identity, binding/egress policy, capability manifest/version, allowed tenant/user policy, health and audit configuration | MCP Pool | Unauthorised tenant/user cannot resolve or invoke a capability; invocation is traceable |
| Twin/ADK → context and models | Permitted-context policy, model/provider configuration in Configuration Manager, memory scope, retrieval/index credentials, audit binding | Intelligence + Configuration | Twin receives grounded context only and cannot select its own provider, write canonical truth, or execute externally |
| Governance → Hermes → connector | Policy configuration, immutable plan store, approval-token issuer/validator, execution identity, callback/sync path | Governance + Hermes | A write fails without approval; an approved write is audited and reconciled through Pipeline |
| Marketplace → activation | Catalog API, tenant-aware discovery, connection eligibility check, installation policy, onboarding hand-off | Marketplace + Integration | Marketplace reuses a compatible tenant connection or starts governed OAuth; it never creates a hidden duplicate |
Secret rule: API keys, OAuth secrets/refresh tokens, webhook secrets, database credentials, service credentials, and model-provider keys belong only in the designated secret/credential wall. NEXT_PUBLIC_* values may identify public endpoints or public identity configuration; they must never contain a privileged key.
3.3 Frontend-to-backend traceability rule
Do not create a one-to-one UI-table-to-database-table mapping. It would violate the projection contract and make the frontend a second data authority. Create one owned contract mapping for every frontend read and action instead:
Workbench route/view
→ projection or capability contract (versioned)
→ Gateway endpoint
→ owning Platform service
→ canonical entities / evidence / permitted source systems
→ authorization, freshness, and audit requirements
Each user-visible read or action has exactly one owning contract and one owning Platform service. A projection may compose many canonical entities and sources; a UI never receives ownership of their underlying tables. This mapping is the required test artifact for every route before integrated testing.
4. Connection reuse standard
An external system is connected once per tenant and permission boundary, then reused through the Spine Network. A new Workbench module, Twin task, or MCP consumer requests a permitted capability against the existing Connection; it does not create another OAuth connection merely because it has a new UI.
Marketplace install / admin request
→ connector catalog entry
→ existing eligible Connection? ── yes → grant scoped capability use
no → governed OAuth/credential connection flow
→ Integration Manager registers sync, mappings, health, and capabilities
→ Pipeline promotes normalized source context to Spine
→ authorized Workbenches, Twins, and MCP consumers reuse it by capability
Reuse is permitted only when tenant, source account, scopes, data classification, purpose, and governance policy are compatible. A second connection remains legitimate when those boundaries differ; reuse must never silently expand access.
4.1 Three-direction delivery rule: publish to activation
Every connector, public MCP channel, capability, and Marketplace change is complete only when it is defined in all three directions below. A connector is not “done” because code compiles, a listing is approved, or an OAuth screen appears.
| Direction | Required responsibility | Required evidence |
|---|---|---|
| 1. Development base | Build and test the connector/MCP contract against isolated engineering infrastructure. Register manifests, mappings, fixtures, schema validation, health checks, and automated contract tests. Use only development credentials and tenant data. | Passing unit, integration, authorization, and failure/retry tests; no production tenant or secret used |
| 2. Production Platform base | Deploy the governed shared runtime: DNS, Gateway, OAuth, credential wall, Pipeline, Spine, projection, audit, observability, policy, rate limits, and rollback. Publish the approved marketplace artifact and webhook/configuration endpoints. | Environment isolation, deployment verification, security review, public endpoint verification, rollback/runbook, and marketplace approval where applicable |
| 3. Customer / Customer Zero projection | Allow an authorized administrator to discover, consent to, configure, activate, reuse, monitor, suspend, and disconnect the capability through the Workbench/Marketplace. Resolve the enabled adapter through Configuration, Integration, and Activation—not product code. | Tenant-scoped installation, consent record, connection binding, initial and delta sync, projection evidence, governed action proof, and disconnect/revocation proof |
The mandatory lifecycle is:
Publish connector / MCP artifact
→ install or discover
→ identity and tenant binding
→ consent and scope selection
→ existing-connection reuse check
→ credential/connection authorization
→ Configuration policy resolution
→ Integration registration and health validation
→ Activation Bridge workspace compilation
→ Spine hydration and projection
→ governed capability use
→ monitoring, sync, revocation, and removal
Completion rule
For each connector or MCP listing, maintain one release record with these three columns: Development readiness, Platform release readiness, and Customer activation readiness. A missing column blocks launch. Customer Zero must complete the same activation column as every external customer; it is never treated as development data or a deployment shortcut.
5. Marketplace and MCP boundary
The Connector Marketplace is a Product surface for discovery, review, installation intent, connection status, and activation. It is not a second integration runtime.
- Marketplace UI calls the Integration and Configuration contracts.
- Integration Manager owns connector registration, connection lifecycle, credentials references, sync, mapping, health, and capability publication.
- Configuration Manager determines whether the connector/capability is enabled for a tenant and environment.
- MCP Pool is internal capability registration, resolution, health, routing, and versioning.
- The only public continuity MCP surface is the frozen 19-tool IW Spine Tools contract. Provider operations, raw connector transport, credentials, and internal registry tools stay private.
6. Production launch sequence
Go live in this order. A phase is complete only when its exit evidence is recorded, not when its UI exists.
| Phase | Required outcome | Exit evidence |
|---|---|---|
| 0. Scope one operational journey | Select one tenant, role, entity flow, and a small connector cohort; define measurable user outcome | Written journey, source-of-record map, risk classification, owner |
| 1. Shared environments and identity | Separate development, staging, and production configurations; Clerk tenant resolution; secret references kept outside Product | Environment matrix, tenant-isolation test, secrets-access audit |
| 2. Truth and evidence path | Neon Spine, R2 evidence, bounded D1/KV state, migrations, backup/recovery, retention, and provenance are ready | Promotion/read-path tests; restore exercise; no direct browser/connector writes |
| 3. Gateway and projections | Authenticated Gateway, versioned projection contract, freshness/partial-evidence behavior, and observability are operating | End-to-end scoped Workbench test; no demo-data substitution on live failure |
| 4. Configuration and integration control | Effective configuration resolution, connector catalog, tenant-owned connection lifecycle, schema mapping, health, and sync policy work | Connection lifecycle and health tests; existing-connection reuse test |
| 5. Initial connector cohort | Connect only sources needed for the chosen journey; map source authority and read/write permissions | Successful creamy load and delta sync; reconciliation and failure/retry evidence |
| 6. Capability and MCP control | Internal capability manifests resolve; public MCP exposes exactly 19 semantic tools with OAuth and tenant scope | Registry/authorization contract tests; public tool inventory verification |
| 7. Twin and governance | Four Buttons work contextually; Twin responses carry evidence/freshness; immutable plan, policy check, approval token, audit, and Hermes path work | Proof that Twin cannot write or execute directly; approved-action round trip |
| 8. Marketplace activation | Marketplace presents real catalog/connection state, reuses eligible connections, and routes activation through onboarding/configuration | Install, reuse, scope-denial, and uninstall/disable tests |
| 9. Production readiness | Monitoring, alerting, runbooks, rate limits, incident ownership, support, rollback, and release controls are ready | Launch review with named owners and exercised rollback |
| 10. Controlled pilot | Enable one bounded tenant/cohort; inspect data quality, sync health, approval behavior, and operational value before expansion | Pilot acceptance decision based on evidence, not feature count |
Gate before the integrated testing event
The integrated testing event may begin only after phases 0–6 are complete and phase 7 has a working non-production proof. Concretely, testers need: an isolated test tenant; sign-in and tenant resolution; a deployed Gateway and live projection path; the access matrix above; at least one connected source with a working initial and delta sync; the contract traceability map for the tested Workbench route; a public MCP authentication test; and a governed action that is safe to execute against a test provider account.
Production Customer Zero operation begins only after phases 7–10 are complete in its isolated operational partition.
7. First connector cohort selection
Choose connectors by the selected journey, not by marketplace breadth. A typical account-success or revenue-operations pilot needs one source from each required evidence class:
| Evidence needed | Example connector class | Launch rule |
|---|---|---|
| Customer/account truth | CRM | One authoritative CRM first |
| Human commitments and meetings | Email and calendar | One provider family matching the tenant |
| Customer friction | Support/ticketing | Add only if the pilot’s risk/status requires it |
| Delivery work | Project/issue tracker | Add when execution evidence is part of the journey |
| Operational communication | Team messaging | Read/context first; writes remain governed |
Each connector must declare source ownership, canonical field mapping, allowed capabilities, scopes, sync mode, health behavior, retry/circuit-breaker behavior, and its rollback/deactivation path before it appears as production-ready in the Marketplace.
8. Stop-ship checks
Do not launch if any statement below is true:
- A browser component or Twin can write to Neon or call a provider API directly.
- A Product-local database determines canonical work state, approval status, tenant configuration, credentials, or memory placement.
- A user-facing surface selects an infrastructure, AI, or connector provider.
- A new screen creates a duplicate connection instead of evaluating eligible existing connections.
- Connector failure silently falls back to demo data on a live tenant.
- The public MCP exposes more or fewer than the frozen 19 semantic tools.
- The Plugin cannot render its sandboxed control surface and fallback, claims
automatic access to host-app credentials, or shares Customer Zero state. - The MCP Marketplace package cannot operate through its browser Workbench
without ChatGPT. - An external write can happen without policy evaluation, explicit approval where required, an approval token, Hermes execution, audit, and reconciliation.
- The Workbench asks the user to restate context already available through permitted Spine context.
- Product UI exposes internal layer labels such as L1, L2, L4, or L7.
9. Decision log
| Decision | Rationale | Consequence |
|---|---|---|
| Platform controls truth and operational authority; Product controls experience | Preserves provider independence and governed execution | Product delivery is contract-first, not database-first |
| Configuration and Integration Managers are separate authorities | Runtime choice is distinct from external-system connection | UI must wire both; neither may be substituted for the other |
| Existing connections are reused by scoped capability | The Spine Network replaces point-to-point duplication | Marketplace activation must discover compatible tenant connections before OAuth |
| Launch one evidence-backed journey before broad catalog expansion | Validates the complete continuity loop and avoids shallow integrations | Connector roadmap follows pilot evidence rather than logo count |
| The Twin proposes; people approve; Hermes executes | Confidence is not authority | Any direct-action shortcut is a release blocker |
10. Source hierarchy
This document is a derived operating standard. Where it conflicts with a frozen document, the following order governs:
ARCHITECTURE_LOCK.mdIMPLEMENTATION_CONTRACT_v1.1.mdfor implementation details amended after the lockFOUR_BUTTONS.mdandTWIN_BEHAVIOR.mdfor user-control and Twin behaviorCANONICAL_PLATFORM_ARCHITECTURE.md,PLATFORM_ARCHITECTURE.md,CONNECTOR_CONSTITUTION.md, andCAPABILITY_CONSTITUTION.mdfor elaboration
Required clarification before implementation
ARCHITECTURE_LOCK.md records Cloudflare Access as MCP authentication, while IMPLEMENTATION_CONTRACT_v1.1.md defines the public MCP boundary as OAuth-protected. The implementation contract is the later authority for public-MCP implementation detail, so the public MCP launch plan uses OAuth. Cloudflare Access may remain an infrastructure protection layer, but it must not become a second, conflicting tenant-authentication path. Record the final deployment pattern in the MCP Connector runbook before testing.