Current

Host-Aware Continuity Runtime Specification

Product: IntegrateWise Customer Zero Workbench
Version: 1.0
Status: FROZEN architecture specification
Date: 2026-07-29
Canonical tenant: iw-customer-zero
Relationship: Normative source for INTEGRATEWISE_ARCHITECTURE.md §15.5–15.8. Subordinate to that document for kernel vocabulary and laws; authoritative here for routing, resolution, agent contracts and acceptance.

1. Executive decision

IntegrateWise applications are created once and deployed into multiple hosts. Each deployment host is both a rendering environment and an integration context with its own identity, permissions, tools, data and execution capabilities.

The deployed application MUST prefer authorized host-native capabilities when they are available and suitable. IntegrateWise Spine MUST complete the request with canonical context, historical continuity, relationships, memory, governance, and access to systems not available through the host.

Host-first access. Spine-complete context. Policy-governed execution. Canonical reconciliation.

"Direct Spine access" in this specification means governed logical access through the Spine Query API, Spine Cache, Gateway, or IntegrateWise MCP tools. It MUST NOT mean direct access to the Fortress database.

2. Objective

One canonical Workbench and continuity runtime, deployable through ChatGPT, IntegrateWise web, Slack, Microsoft surfaces, embedded customer applications, desktop shells, customer-hosted environments, and future marketplaces or agent hosts.

Each deployment MUST: inherit the capabilities exposed by its active host; use host-native integrations before duplicating them; use Spine to fill capability and context gaps; keep material actions inside IntegrateWise governance; reconcile host-native and IntegrateWise-native outcomes into the same canonical Spine; render the same domain semantics across hosts without forking business logic.

3. Scope

In scope. Host-aware capability routing · host capability declaration and runtime availability · Spine completion and Entity360 enrichment · ADK agent contracts · Hermes orchestration · MCP, HTTP and host-bridge transports · Loader and Normalizer Path · Fortress Spine and Spine Cache · evidence provenance and freshness · governed proposals, approvals, execution and reconciliation · create-once/deploy-anywhere packaging · read and write routing rules · failure handling, observability and acceptance criteria.

Out of scope. Replacing host authentication systems · exposing raw Fortress tables to hosts or agents · automatically duplicating every host connection inside IntegrateWise · assuming an IntegrateWise MCP app can introspect or invoke arbitrary unrelated host apps · allowing agents to execute material external writes outside governance · host-specific forks of domain logic, Projection Engine logic or canonical schemas.

4. Definitions

TermDefinition
HostRuntime in which the Workbench is deployed — ChatGPT, Slack, web, Microsoft
Host-native capabilityA read or action capability exposed by the active host under the current user and workspace permissions
SpineCanonical operational truth, entity graph, continuity history, policy references, reconciliation state
Fortress SpineAuthoritative persistence layer. Not directly exposed to hosts or agents
Spine CacheRead-optimised, policy-filtered, LLM-readable projection of Spine
Spine completionUse of canonical context or IntegrateWise-managed connectors to supply information or actions missing from the host
ADKAgent Development Kit defining Twin, Co-worker, Triage, governance and specialist agent contracts
HermesOrchestrator that plans, sequences, tracks, retries and reconciles multi-step work
LoaderProvider-aware ingestion component capturing raw observations and execution outputs
Normalizer PathPipeline converting provider-specific payloads into canonical Spine records and relationships
Capability FabricIntegrateWise execution plane for governed external capabilities
Connection BindingMapping between a host connection, canonical principal and optional IntegrateWise integration
Material writeAny action changing an external or canonical system, sending communication, creating obligations, changing permissions, or affecting business state

5. Frozen architecture principles

P1. Host is an integration context. A deployment MUST account for the host's authenticated user, workspace or tenant, enabled integrations, granted scopes, supported operations, confirmation model, surface limitations and runtime availability. The host is not merely a visual container.

P2. Host-native access is preferred, not blindly trusted. A host-native route MAY be selected when the capability is actually exposed to the current session, required scopes are present, policy allows the route, data authority and freshness are sufficient, and the operation can produce evidence and a receipt where required.

P3. Spine is the completion layer. Spine MUST provide canonical identity, entity resolution, cross-system relationships, historical continuity, organizational and conversational memory, commitments/signals/decisions/evidence, systems unavailable through the host, and policy and governance state.

P4. Context-aware Spine enrichment. Enrichment is mandatory when a request is entity-scoped, relationship-scoped, continuity-scoped, cross-system, policy-sensitive, approval-related, a material write, based on organizational memory, or expected to alter canonical state.

A strictly host-local read MAY be answered without full enrichment when all of the following are true: the user asks only about the active host; no canonical entity or cross-system context is needed; no material write is involved; policy permits local execution; provenance is retained; and the result does not claim to represent complete operational truth.

P5. All material writes are Spine-governed. Execution route and governance route are separate decisions. A write may execute through a host-native tool or an IntegrateWise connector, but MUST pass through canonical entity resolution → policy evaluation → proposal creation → approval or confirmation → route resolution → execution → receipt capture → reconciliation into Spine.

P6. Create once, deploy anywhere. Domain logic, canonical types, projections, capabilities, governance rules and core UI MUST be shared. Host-specific code MUST remain inside adapters.

P7. No raw Fortress exposure. Hosts, MCP clients, Workbench frontends and LLM agents MUST use governed APIs, MCP tools or Spine Cache projections. They MUST NOT query Fortress storage directly.

6. Platform boundary

┌──────────────────────────────────────────────────────────────┐
│ Deployment Host                                              │
│ ChatGPT | Web | Slack | Microsoft | Embedded | Customer Host  │
│ Host identity + host tools + host UI + host confirmation      │
└──────────────────────────────┬───────────────────────────────┘
                               │ Host Adapter
                               ▼
┌──────────────────────────────────────────────────────────────┐
│ Host-Aware Continuity Runtime                                │
│ Intent Classifier · Capability Resolver · ADK Agents          │
│ Hermes Orchestrator · Projection Engine · Governance          │
└───────────────┬──────────────────────────────┬───────────────┘
                │                              │
       Host-native execution          IntegrateWise execution
                │                              │
                ▼                              ▼
       Host-exposed apps/tools     MCP / Gateway / Capability Fabric
                │                              │
                └──────────────┬───────────────┘
                               ▼
                     Loader + Normalizer Path
                               ▼
                 Fortress Spine + Spine Cache
                               ▼
                  Reconciliation + rehydration

7. ChatGPT-specific constraint

In a ChatGPT deployment, ChatGPT is the host orchestrator for apps and tools it exposes to the conversation.

The IntegrateWise MCP server MUST NOT assume it can enumerate every app connected to the user's ChatGPT account, access another app's OAuth token, invoke unrelated apps directly, or bypass ChatGPT's permission, confirmation or workspace controls.

Host capabilities MUST enter the IntegrateWise runtime through one or more explicit mechanisms:

  1. Host-declared capability context supplied to the app invocation
  2. Tool-result handoff — ChatGPT invokes a host app and passes the resulting evidence to an IntegrateWise tool
  3. Workflow-level orchestration — ChatGPT selects both host apps and IntegrateWise MCP tools
  4. Explicit IntegrateWise connection when a capability is not available through the host
  5. Installation manifest or policy declaration indicating expected capabilities, which MUST still be validated at runtime

Expected availability MUST never be treated as proof of actual runtime access.

8. Request classification

Every request MUST be classified before routing.

type RequestScope =
  | "host-local"
  | "entity"
  | "continuity"
  | "cross-system"
  | "governance"
  | "write";

interface RequestClassification {
  scopes: RequestScope[];
  requestedEntities: EntityReference[];
  requestedOperations: RequestedOperation[];
  completenessExpectation: "local" | "best-available" | "canonical";
  requiresSpineEnrichment: boolean;
  requiresGovernance: boolean;
}
RequestClassificationSpine requirement
"Summarize unread Gmail messages."host-localLightweight provenance only, unless entity context is requested
"Prepare me for the Acme renewal."entity, continuity, cross-systemMandatory Entity360 enrichment
"What changed since the last QBR?"continuity, cross-systemMandatory
"Send the approved renewal email."write, governance, entityMandatory proposal, approval, execution, receipt, reconciliation
"Show everything requiring my attention."cross-system, continuityMandatory canonical aggregation

9. Capability resolution

9.1 Descriptors

type Operation = "read" | "search" | "create" | "update" | "delete" | "execute";

interface HostCapability {
  id: string;
  host: "chatgpt" | "web" | "slack" | "microsoft" | "embedded" | "customer";
  provider: string;
  capability: string;
  operations: Operation[];
  scopes: string[];
  principalId: string;
  workspaceId: string;
  availability: "confirmed" | "declared" | "unknown";
  confirmationRequired: boolean;
  observedAt: string;
}

interface SpineCapability {
  id: string;
  provider: string;
  capability: string;
  operations: Operation[];
  integrationId?: string;
  adapter?: "nango" | "mcp" | "native";
  freshness: "live" | "synced" | "historical";
  authority: "system-of-record" | "canonical" | "derived";
  observedAt: string;
}

9.2 Route result

type ExecutionRoute =
  | "host-native"
  | "spine-query"
  | "integratewise-connector"
  | "spine-cache"
  | "request-connection"
  | "unavailable";

interface ResolvedCapability {
  requestId: string;
  capability: string;
  provider: string;
  route: ExecutionRoute;
  reasonCode:
    | "HOST_CONFIRMED"
    | "SPINE_CANONICAL"
    | "IW_LIVE_CONNECTOR"
    | "SPINE_HISTORICAL"
    | "POLICY_OVERRIDE"
    | "HOST_UNAVAILABLE"
    | "MISSING_SCOPE"
    | "NO_CONNECTION";
  requiresApproval: boolean;
  requiresReconciliation: boolean;
  fallbackRoutes: ExecutionRoute[];
}

9.3 Read precedence

  1. Confirmed host-native live capability
  2. Spine canonical context
  3. IntegrateWise-managed live connector
  4. Spine Cache or historical Spine data
  5. Request connection
  6. Unavailable

This is not a simple sequential query plan. The resolver MAY combine routes — Gmail host-native while Salesforce and Slack are supplied through Spine.

9.4 Write precedence

  1. Resolve canonical target and policy
  2. Create proposal
  3. Determine allowed execution routes
  4. Prefer host-native execution when confirmed and policy-approved
  5. Otherwise use IntegrateWise Capability Fabric
  6. Capture execution receipt
  7. Normalize and reconcile
  8. Rehydrate Workbench and Spine Cache

10. Connection binding

interface ConnectionBinding {
  id: string;
  workspaceId: string;
  provider: string;
  canonicalPrincipalId: string;
  host?: {
    hostType: string;
    hostWorkspaceId?: string;
    hostConnectionRef?: string;
    scopes?: string[];
  };
  integratewise?: {
    integrationId: string;
    adapter: "nango" | "mcp" | "native";
    scopes: string[];
  };
  preference: "host-first" | "integratewise-first" | "policy-decides";
  duplicateCallsAllowed: boolean;
  reconciliationMode: "immediate" | "async" | "manual";
}

Rules. The same provider MUST NOT be called through host and IntegrateWise merely because both are connected · one primary route MUST be selected per operation · a secondary route MAY be used for fallback, verification or reconciliation when policy allows · principal matching MUST use canonical identity, not display name alone · connection tokens remain inside their owning trust boundary.

11. ADK responsibilities

ADK defines agents and their contracts. It MUST NOT own provider-specific transport logic.

AgentResponsibility
TwinReasoning, synthesis, recommendations, proposal drafting
Co-workerTask execution assistance and operational follow-through
TriageIntent, urgency, ownership and attention classification
Governance AgentPolicy interpretation, approval requirements, risk classification
Entity ResolverCanonical entity and identity matching
Evidence AgentEvidence selection, provenance checks, contradiction detection

Open conflict (D7). SOURCE_PACK_RECONCILIATION_2026-07-28.md corrects Twin and Co-worker as separate runtimes to a single contextual Twin behaviour. Both documents carry adjacent dates. Resolve before implementing ADK contracts.

Every agent invocation MUST receive a policy-filtered ActiveContextBundle, not arbitrary raw provider payloads unless the task is explicitly ingestion or normalization.

12. Hermes orchestrator

Hermes MUST convert classified intent into an execution plan; request capability resolution per step; coordinate host-native handoffs and IntegrateWise tools; sequence dependent steps; parallelize independent reads; enforce deadlines, retries and idempotency; persist plan state; wait for approvals without losing context; capture tool outputs as evidence; route observations through Loader and Normalizer; reconcile results into Spine; emit progress and completion events.

interface WorkPlan {
  id: string;
  workspaceId: string;
  actorId: string;
  classification: RequestClassification;
  steps: WorkStep[];
  status: "planned" | "running" | "awaiting-approval" | "completed" | "failed";
}

interface WorkStep {
  id: string;
  capability: string;
  route?: ExecutionRoute;
  dependencies: string[];
  idempotencyKey: string;
  status: "pending" | "running" | "blocked" | "completed" | "failed";
}

13. Loader and Normalizer Path

13.1 Loader

Captures raw observations from host-native tool results, IntegrateWise connectors, MCP calls, sync jobs, webhooks, execution receipts, imported files and manual user evidence.

interface RawObservation {
  id: string;
  workspaceId: string;
  sourcePlane: "host" | "integratewise" | "import";
  host?: string;
  provider: string;
  operation: string;
  externalObjectType?: string;
  externalObjectId?: string;
  principalId: string;
  payloadRef: string;
  contentHash: string;
  observedAt: string;
  receivedAt: string;
  policyTags: string[];
}

Raw payloads SHOULD be stored by reference in an appropriate raw/retention layer. They MUST NOT be passed wholesale into general agent context.

13.2 Normalizer Path

MUST validate source and schema; remove transport-specific envelopes; map provider fields to canonical concepts; resolve identities and entities; classify records as entities, relationships, events, signals, commitments, decisions, messages or evidence; apply tenant and policy boundaries; deduplicate; calculate freshness and authority; persist canonical updates; publish LLM-readable Spine Cache projections; emit reconciliation events.

interface NormalizationResult {
  observationId: string;
  canonicalEntities: CanonicalEntityRef[];
  relationships: CanonicalRelationshipRef[];
  events: CanonicalEventRef[];
  evidence: EvidenceRef[];
  conflicts: NormalizationConflict[];
  disposition: "created" | "updated" | "duplicate" | "quarantined";
}

13.3 LLM-readable representation

Spine Cache projections MUST remove provider noise; retain provenance; preserve canonical IDs; expose compact summaries; include freshness, authority and confidence; include policy-visible relationships only; distinguish fact, inference, proposal and memory; and support deterministic retrieval by entity and continuity thread.

14. Active Context Bundle

interface ActiveContextBundle {
  requestId: string;
  workspaceId: string;
  actor: { id: string; role: string; permissions: string[] };
  host: { type: string; sessionId: string; capabilitiesObservedAt: string };
  entities: CanonicalEntity[];
  relationships: CanonicalRelationship[];
  continuity: ContinuityItem[];
  commitments: Commitment[];
  signals: Signal[];
  decisions: Decision[];
  evidence: EvidenceItem[];
  availableActions: ResolvedCapability[];
  policy: EffectivePolicy;
  completeness: {
    level: "host-local" | "partial" | "canonical";
    missingSystems: string[];
  };
}

Every answer that claims cross-system completeness MUST report completeness.level = "canonical" or explicitly disclose missing systems.

15. Evidence and provenance

interface EvidenceItem {
  id: string;
  sourcePlane: "host-native" | "spine-canonical" | "integratewise-live" | "spine-cache";
  provider: string;
  canonicalEntityId?: string;
  externalObjectId?: string;
  observationId: string;
  authority: "system-of-record" | "canonical" | "derived" | "user-supplied";
  freshness: "live" | "recent" | "stale" | "historical";
  observedAt: string;
  normalizedAt?: string;
  confidence: number;
  policyTags: string[];
}

Host-native evidence MUST retain host and provider · canonical summaries MUST link back to underlying evidence · derived conclusions MUST NOT be stored as facts · conflicting evidence MUST be surfaced to the Evidence Agent and may trigger a reconciliation task · the Workbench MUST allow evidence inspection for governed decisions.

16. Read flows

Host-local. classify host-local → host invokes native capability → retain provenance → optional lightweight Loader ingestion → answer with host-local completeness.

Entity or continuity. classify scope → resolve canonical entity → obtain host-native live evidence where available → query Spine Cache / Spine Query API → invoke IntegrateWise connectors for missing live systems → Loader + Normalizer → construct Active Context Bundle → Twin synthesis → return answer with evidence and completeness.

Missing host capability. check Spine canonical data → check IntegrateWise live connector → use cached/historical data when policy permits → otherwise request connection.

17. Governed write flow

User intent → classify as write → resolve canonical entity and target
→ draft proposal → evaluate policy → request approval/confirmation
→ resolve execution route → execute through host-native tool or Capability Fabric
→ capture receipt → Loader + Normalizer → reconcile into Spine
→ update Spine Cache → rehydrate Workbench

interface GovernedProposal {
  id: string;
  workspaceId: string;
  actorId: string;
  targetEntityId: string;
  capability: string;
  intendedChange: unknown;
  evidenceIds: string[];
  policyDecision: "allow" | "approval-required" | "deny";
  selectedRoute?: ExecutionRoute;
  status: "draft" | "pending" | "approved" | "rejected" | "executed" | "failed";
}

interface ExecutionReceipt {
  id: string;
  proposalId: string;
  route: "host-native" | "integratewise-connector";
  provider: string;
  externalOperationId?: string;
  status: "succeeded" | "failed" | "partial" | "unknown";
  beforeRef?: string;
  afterRef?: string;
  executedAt: string;
  reconciledAt?: string;
}

A host confirmation prompt does not replace IntegrateWise policy evaluation. IntegrateWise approval and host confirmation may both be required.

18. MCP, HTTP and host-bridge contracts

The same application services MUST be exposed through thin adapters.

Canonical serviceHTTPMCP
Today projectionGET /v1/workbench/todayworkbench.get_today
Entity contextGET /v1/entities/:id/contextspine.get_entity_context
Capability resolutionPOST /v1/capabilities/resolvecapability.resolve
Evidence ingestionPOST /v1/observationsspine.ingest_observation
Proposal creationPOST /v1/proposalsgovernance.create_proposal
Approval decisionPOST /v1/proposals/:id/decisiongovernance.decide
ExecutionInternal only after governanceInternal governed tool
Reconciliation statusGET /v1/executions/:idexecution.get_status

Adapters MUST validate host identity, translate host payloads to canonical commands, enforce schemas, return structured results and evidence references, and contain no domain policy or provider-specific business rules.

19. Create-once / deploy-anywhere packaging

customer-zero/
├── apps/         web · chatgpt-app · mcp-server · preview
├── packages/     domain · application-services · api-contracts · adk
│                 projections · governance · workbench-ui · ui-kit · host-contracts
├── adapters/     chatgpt · http · mcp · cloudflare · vercel · slack · microsoft · embedded
└── deploy/       cloudflare · vercel · chatgpt · customer-hosted

packages/ contains canonical product behavior · adapters/ contains host and infrastructure translation · apps/ assembles deployable surfaces · deploy/ contains environment-specific configuration.

No adapter may redefine canonical entities, governance policy or projection semantics. Provider SDKs MUST remain behind Gateway, Integration Manager, Capability Fabric or connector adapters.

Open decision (D8). This structure differs materially from the current monorepo. It is a restructure to execute, sequenced after the Spine-writer decision (D4).

20. Runtime configuration

interface HostAwareRuntimeConfig {
  deploymentId: string;
  host: "chatgpt" | "web" | "slack" | "microsoft" | "embedded" | "customer";
  workspaceId: string;
  tenantId: string;
  transports: { http: boolean; mcp: boolean; hostBridge: boolean };
  routing: {
    defaultPreference: "host-first" | "integratewise-first" | "policy-decides";
    contextAwareSpineEnrichment: true;
    allowHostLocalReads: boolean;
    allowHistoricalFallback: boolean;
  };
  governance: {
    externalWrites: boolean;
    approvalMode: "always" | "policy";
    requireExecutionReceipts: true;
  };
  services: { gatewayUrl: string; mcpUrl?: string; spineQueryUrl: string };
}

21. Security and trust boundaries

Every request MUST resolve tenant, workspace, user, role and host session · host credentials MUST remain in the host boundary · IntegrateWise connector credentials MUST remain in Integration Manager or the configured secret system · no credential may be copied between host and IntegrateWise merely to unify routing · evidence and canonical data MUST carry workspace and policy tags · Spine Cache MUST be policy-filtered before agent access · MCP tools MUST enforce tenant and user authorization independently of model instructions · external writes MUST be deny-by-default unless policy and deployment configuration allow them · cross-tenant entity resolution is prohibited · raw observations MUST follow configured retention and redaction policies · every proposal, approval, execution and reconciliation event MUST be auditable.

22. Consistency and freshness

Live host evidence is authoritative only for the provider object it represents. Spine remains canonical for cross-system identity, relationships, continuity and reconciled state. A live provider observation may supersede stale canonical fields after normalization and conflict resolution.

Four timestamps MUST be distinguished: observedAt (when the source state existed) · receivedAt (when IntegrateWise received it) · normalizedAt (when canonical state was updated) · reconciledAt (when the operation was confirmed across boundaries).

Stale data MAY be used for context but MUST be labeled. Writes with unknown execution status MUST enter reconciliation rather than being retried blindly.

23. Failure handling

FailureRequired behavior
Host capability declared but unavailableFall back to Spine/IW connector or request connection
Host tool returns partial dataMark partial completeness; continue with Spine completion when relevant
Spine Cache unavailableQuery governed Spine API if permitted; otherwise degrade without claiming completeness
IntegrateWise connector unavailableUse recent canonical data where permitted and disclose staleness
Entity resolution ambiguousBlock material writes; request disambiguation or route to review
Approval expiresDo not execute; require a new decision
Host execution succeeds but receipt missingMark status unknown and reconcile; do not duplicate automatically
Normalization conflictQuarantine conflicting update and preserve both evidence records
Policy service unavailableDeny writes; reads may degrade according to cached policy
Loader/Normalizer unavailableReturn host-local response only where safe; queue ingestion if supported

24. Observability

Required telemetry: request classification · capability resolution decision · selected and fallback routes · host capability availability · policy decision · approval latency · execution status · reconciliation latency · normalization disposition · entity resolution confidence · Spine Cache freshness · completeness level · provider and host error rates · duplicate-call prevention · cross-tenant authorization failures.

Every plan and execution MUST carry a correlation ID spanning host adapter, Hermes, MCP/Gateway, Loader, Normalizer, Spine and reconciliation.

25. Acceptance criteria

Host-aware routing. A ChatGPT-hosted request uses a confirmed host Gmail capability when available and policy-approved · the same request obtains Salesforce context through IntegrateWise without Salesforce being connected to ChatGPT · the resolver does not call both host Gmail and IntegrateWise Gmail by default · missing host capabilities fall back deterministically.

Spine enrichment. Entity and continuity requests always produce an ActiveContextBundle · host-local requests bypass full enrichment only under the frozen rules · cross-system answers disclose missing systems and completeness · agents receive LLM-readable canonical projections rather than unrestricted raw payloads.

Governance. Every material write creates a proposal · no material write executes before required approval · host-native and IntegrateWise-native writes produce the same canonical receipt structure · successful, failed, partial and unknown outcomes are all reconciled.

Loader and Normalizer. Host tool results ingest as RawObservation · provider payloads map to canonical records with provenance · duplicate observations are idempotently ignored or merged · conflicts are quarantined without destroying evidence · Spine Cache reflects normalized updates within the configured freshness target.

Deployment portability. The same domain and application-service packages serve web and ChatGPT deployments · host adapters contain no duplicated policy or canonical schema · a deployment can switch between Cloudflare and Vercel without changing domain logic · external writes can be disabled by runtime configuration without rebuilding the UI.

Security. No raw Fortress access exposed to a host · no host credential stored by IntegrateWise unless the user separately creates an IntegrateWise connection · tenant isolation tests pass · write paths fail closed when policy is unavailable.

26. Implementation sequence

Phase 1 — Contracts and read routing. Freeze host, capability, route, evidence and context-bundle schemas · implement request classification · implement Capability Resolver · implement ChatGPT MCP and HTTP adapters over the same services · implement context-aware Spine enrichment · keep external writes disabled.

Phase 2 — Loader, Normalizer and Spine Cache. Ingest host evidence and connector results · normalize initial providers · publish canonical LLM-readable projections · add provenance, freshness, conflict handling and completeness reporting.

Phase 3 — Governed writes. Proposal and policy services · approval queue · host-native execution handoff · Capability Fabric execution · receipts and reconciliation.

Phase 4 — Deployment expansion. Slack, Microsoft, embedded and customer-hosted adapters · host capability manifests and runtime validation · confirm identical domain behavior across hosts.

27. Frozen decisions

  1. Context-aware enrichment is selected. Spine is mandatory for entity, continuity, cross-system, governance and write scopes; host-local reads may remain local under explicit rules.
  2. Host-first is a preference, not an entitlement. The host capability must be exposed and confirmed at runtime.
  3. ChatGPT orchestrates its own connected apps. IntegrateWise MCP does not assume direct access to unrelated ChatGPT app connections.
  4. Spine completes missing context and capabilities.
  5. Spine Cache is the default agent read surface.
  6. Fortress Spine is never directly exposed.
  7. All material writes are Spine-governed.
  8. Execution may occur through host-native or IntegrateWise-native routes.
  9. Every execution is canonically reconciled.
  10. Domain logic is built once; hosts are adapters.
  11. Loader and Normalizer Path are mandatory for converting tool-specific observations into canonical, LLM-readable continuity.
  12. Connection duplication is avoided unless policy or operational requirements explicitly require it.

28. Canonical architecture statement

IntegrateWise deploys one canonical Workbench into multiple hosts. The active host contributes its authorized identity, tools and interaction model. IntegrateWise uses those host-native capabilities first when they are confirmed and policy-appropriate, then uses Spine and Integration Manager to supply missing systems, canonical relationships, history, memory and governance. ADK agents reason over policy-filtered Spine Cache context; Hermes coordinates host and IntegrateWise execution; Loader and Normalizer convert every material observation and outcome into canonical Spine state. All material writes are proposed, approved, executed through the selected route, receipted and reconciled.

One product, created once, deployed anywhere — host-aware at the edge, continuity-governed at the core.