Unclassified

Customer Zero Hosted Plugin Code Brief

Status: Implementation briefing
Date: 2026-07-29
Audience: Customer Zero/hosted-application engineers, Platform engineers,
frontend engineers and marketplace-release owners
Governing profile specification:
CUSTOMER_ZERO_TO_EXTERNAL_PRODUCT_AND_MARKETPLACE_SPEC.md

1. Product to build

Build the Customer Zero implementation of IW-Spine-Network Plugin first.
The same versioned Plugin code is then published for external users with an
external audience profile.

The Plugin runs as a focused application inside a compatible AI host such as
ChatGPT, Claude or Perplexity when that host supports the required Plugin/MCP
App contracts.

AI host
  ├── host conversation, model, native agents and schedules
  ├── applications/capabilities explicitly exposed by the host
  └── IW-Spine-Network Plugin UI
          ↓
     public IW Spine Tools
          ↓
     IntegrateWise Platform

The host is the primary conversational controller. The Plugin does not deploy
or require another general chat agent merely to render and operate the
workspace.

IntegrateWise still supplies Platform intelligence:

Triage organizes incoming activity;
Search and Context assemble relevant records;
Twin reasons at THINK;
Capability Fabric resolves tools and agents;
Governance requires human approval;
Hermes coordinates execution;
Pipeline, Sync and Governed Spine Writers reconcile outcomes.

2. No deployment during onboarding

The Platform, remote MCP server and Plugin UI assets are already deployed before
the user clicks Install.

Ordinary onboarding performs logical provisioning only:

Install Plugin
→ verify host installation
→ authenticate user
→ obtain consent
→ resolve/create logical tenant account
→ resolve/create tenant + workspace + membership
→ allocate stable Spine Network ID
→ apply versioned activation profile
→ initialize bounded operational state
→ run capability/connection discovery
→ render the Plugin UI

Onboarding must not:

deploy a new Worker;
create a separate database;
create a new queue, bucket or cache namespace;
deploy a new copy of the frontend;
clone Customer Zero;
copy Customer Zero data or credentials.

3. Meaning of “inside our tenant”

Initial users are hosted inside the IntegrateWise-managed shared SaaS
environment.

They are not all placed in the same logical business tenant.

IntegrateWise-managed Platform account/environment
├── iw-customer-zero                         # IntegrateWise operations
├── tenant-customer-a                        # logically isolated customer
├── tenant-customer-b                        # logically isolated customer
└── tenant-personal-c                        # logical personal account, if offered

Every external account receives:

tenant_account_id;
tenant_id;
workspace_id;
membership_id;
spine_network_id;
policy and entitlement bindings;
tenant-scoped connection bindings;
tenant-scoped operational and audit scope.

These identifiers are resolved by Gateway. They are not trusted when supplied
directly by the Plugin or browser.

4. Customer Zero versus external mode

The codebase has one trunk and two server-selected audience profiles:

Concern	Customer Zero	External
Profile	`customer_zero`	`external`
Tenant	Expected `iw-customer-zero` after membership proof	Dynamically resolved logical tenant
Data	IntegrateWise production operations	Customer-isolated data
Connections	IntegrateWise-owned	Customer-consented
Operator modules	RBAC-gated	Not exposed
Internal MCP Pool	Platform operator access only	Never exposed
Public Plugin tools	Exact 19 IW Spine Tools	Exact 19 IW Spine Tools
Approval	Mandatory	Mandatory

Do not use separate long-lived Customer Zero and external branches. Promote the
same artifact after Customer Zero verification.

5. Host-controlled application experience

The Plugin UI is a focused host surface, not a second complete browser
Workbench.

It should provide:

current work and active context;
search across permitted Spine entities, documents and memory;
connected/delegated application status;
grouped network capabilities;
action and capability selection;
proposal, evidence and affected-system review;
explicit human approval;
execution and reconciliation progress;
Open Workbench for full tables, pages and canvases.

The UI communicates only through the host’s declared MCP App/resource bridge.
It cannot inspect the host DOM, cookies, storage, private app registry or raw
credentials.

6. Host-connected applications

The target experience is one UI over applications already available to the
host, but the implementation must distinguish availability from credential
ownership.

6.1 Three application origins

Origin	Behavior
`host_composed`	Host can use another enabled application in the current conversation/session
`host_delegated`	Host and user/admin explicitly delegate a supported persistent capability to IW
`iw_direct`	User connects the provider through IntegrateWise Connector Marketplace

If ChatGPT, Claude or Perplexity exposes ten connected applications through a
supported composition/discovery contract, the Plugin may project those
available capabilities in one UI.

The Plugin does not automatically inherit their OAuth credentials.

If the host does not expose a reliable app-inventory or delegation API:

the host may still compose another app within its own conversation;
IW must not claim a persistent connection;
the Plugin displays the capability as session/host-scoped;
persistent data access requires an IW direct connector or explicit
delegation.

6.2 Missing application

When required data is not available:

Twin/host identifies missing context
→ Discovery searches tenant bindings and host-delegated capabilities
→ if available, request the permitted capability
→ otherwise present Connect Application
→ user chooses provider from Connector Marketplace
→ consent and binding complete
→ hydration/sync runs through Platform
→ projection refreshes

The system must not silently force a provider or create a hidden connection.

7. Cross-host and agent-to-agent communication

Spine Network is the governed continuity and capability broker. It does not log
into ChatGPT, Claude or Perplexity as a user.

Cross-host communication occurs only through registered, authenticated
capability adapters:

origin host/agent
→ public IW capability request
→ Gateway identity + tenant policy
→ Capability Fabric resolver
→ MCP / A2A / ADK / registered execution adapter
→ Governance and approval when action is proposed
→ Hermes execution/coordination
→ outcome receipt
→ Triage and reconciliation

ADKs and stateful execution runtimes are implementation providers behind
Capability Fabric. They do not become new sources of truth or bypass tenant,
memory and approval rules.

8. What the Customer Zero code owns

The hosted Product runtime may own bounded, tenant-scoped operational
implementation state:

Plugin session state;
UI selections and drafts;
active-context snapshots;
short-lived projection cache;
idempotency records;
event outbox/inbox;
execution display state;
host capability handles;
agent scratchpad and working memory;
temporary conversation/task context;
pending memory and promotion candidates.

Appropriate stores may include D1, KV, Durable Objects or R2 where defined by
the deployment profile. These stores remain bounded, reconstructable and
tenant-scoped.

The codebase must include:

apps/
  plugin-surface/
  plugin-runtime/
packages/
  plugin-manifest/
  plugin-resources/
  plugin-skills/
  host-adapters/
  platform-client/
  operational-state/
  agent-working-memory/
profiles/
  customer-zero/
  external/
tests/
  clean-install/
  host-composition/
  tenant-isolation/
  promotion/
  approval/

9. What remains Platform-owned

The Platform repository owns:

identity and membership authority;
logical tenant provisioning;
Activation, Configuration and Integration;
connector credentials and provider adapters;
Pipeline and deterministic Normalizer;
Operational Spine ledger and global lifecycle policy;
Triage classification and memory-promotion policy;
Canonical Spine/Fortress;
canonical person/entity/relationship/event truth;
Projection Engine contracts;
Twin runtime and model policy;
Capability registry/resolver;
Governance and approval-token minting;
Hermes;
Sync, reconciliation, audit and retention;
public 19-tool MCP server;
internal MCP Pool.

The Customer Zero code may cache or stage Platform projections; it cannot
replace these authorities.

10. Memory ownership

Memory is divided by authority and retention:

Memory class	Initial owner/store	Promotion behavior
Host-native conversation context	AI host	Available only through host-supported context/delegation
Agent scratchpad	Customer Zero Product runtime	Short-lived; never canonical
Agent working memory	Customer Zero Product operational store	Bounded; may emit a memory candidate
User working context	Product operational store / Operational Spine projection	Reconstructable and expiry-governed
Memory candidate	Operational Spine promotion queue	Triage classifies; human/policy review applies
Promoted user/organisational memory	Platform Canonical Spine	Governed institutional continuity

Chat transcripts, brainstorming, agent outcomes and tool results must not become
institutional memory merely because they exist. They enter through a memory
candidate and promotion lifecycle.

11. Operational-to-canonical synchronization

There is no database-to-database write from the Customer Zero repository into
the Fortress.

Product operational event/draft/agent outcome
→ durable local outbox
→ Gateway command or event contract
→ idempotency + tenant binding
→ Pipeline
→ Normalizer
→ Triage
→ Operational Spine
→ promotion candidate
→ required human/policy approval
→ Governed Spine Writer
→ Canonical Spine
→ canonical receipt/version
→ projection invalidation
→ Product operational cache refresh

The return path is contract-driven:

canonical/outcome event
→ tenant-scoped projection
→ cache invalidation or refresh token
→ Plugin UI update
→ host context update where permitted

Every event requires:

tenant/account/workspace/Spine Network scope;
event and contract version;
idempotency key;
correlation and causation identifiers;
actor and authority;
source connection/host origin;
provenance/evidence reference;
retry and ambiguous-outcome classification;
resulting receipt or rejection.

12. Later movement to dedicated infrastructure

The initial shared-SaaS model does not prevent later isolation.

Migration triggers may include:

sustained workload or storage volume;
connector/event throughput;
latency or noisy-neighbour risk;
data residency;
compliance requirements;
enterprise contractual isolation.

Migration preserves stable logical identity:

tenant_id + spine_network_id remain unchanged
→ dedicated target provisioned
→ tenant-scoped canonical/evidence state copied and verified
→ operational deltas replayed
→ credential references rebound
→ server-side tenant route switched
→ Product continues on the same Plugin/MCP/frontend contracts

No new Plugin installation or customer code fork is required.

13. Required code contracts

13.1 Provisioning

installation create/resume/revoke;
logical tenant/account/workspace/membership allocation;
activation-profile application;
idempotent retries;
no infrastructure deployment call.

13.2 Discovery

first-read discovery envelope;
application origin and persistence classification;
connection health and duplicate grouping;
partial/degraded states;
explicit Connect Application intent.

13.3 Context and work

active context;
entity/document/signal search;
work projection;
linked records;
Twin invocation at THINK;
draft and candidate creation.

13.4 Action

prepare proposal;
show evidence and affected systems;
capture explicit human approval;
approval-token reference;
execution status;
outcome receipt and reconciliation.

13.5 Memory

scratchpad/working-memory lifecycle;
candidate creation;
promotion state;
expiry and deletion;
canonical memory reference after promotion.

14. Customer Zero implementation sequence

Implement shared-SaaS logical provisioning with no deployment side effects.
Implement Customer Zero profile and verify iw-customer-zero membership.
Implement bounded operational state and agent working memory.
Implement public MCP/host bridge and focused Plugin UI.
Implement host capability origins and direct connector fallback.
Implement outbox, idempotency, retry and reconciliation.
Implement memory and truth promotion candidates.
Prove explicit human approval and Hermes execution.
Run Customer Zero daily operations through the Plugin.
Install the same artifact into a clean logical external tenant.
Verify isolation and remove every fixed C0 assumption.
Freeze and submit the external Plugin package.

15. Stop-ship rules

Stop release if:

onboarding deploys infrastructure for an ordinary user;
an external user is allocated inside iw-customer-zero;
tenant identity comes from an untrusted UI/header;
the Plugin claims credentials for all host-connected applications;
agent working memory writes directly to canonical truth;
Product operational state becomes an unbounded second Spine;
Product code calls providers or the Fortress directly;
cross-host communication bypasses registered authenticated capabilities;
an action can execute without human approval;
Customer Zero-only code is required by the external profile.

16. Definition of done

The Customer Zero code briefing is satisfied when:

Plugin installation creates only logical Platform records and operational
state;
the focused UI runs inside a supported host;
supported host capabilities and IW direct connections appear in one
provenance-aware view;
missing applications follow explicit connection/delegation;
operational and agent memory remain bounded and tenant-scoped;
promotion to Canonical Spine occurs only through Platform Pipeline and
governed writers;
Customer Zero runs real work through the implementation;
the same artifact activates for an external logical tenant without a new
deployment or code change.