{"slug":"canonical/adr/ADR-2026-09-04-09-host-first-capability-routing","title":"ADR-2026-09-04-09 — Host-first capability routing","section":"canonical","sectionLabel":"Canon","status":"canon","type":"adr","path":"canonical/adr/ADR-2026-09-04-09-host-first-capability-routing.md","bytes":2569,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** ACCEPTED — 2026-09-04 (host-aware continuity runtime spec, frozen decisions; Auth-Ecosystem entry model)\n\n## Context\n\nOne canonical Workbench deploys into many hosts (ChatGPT, web, Slack, Microsoft, embedded,\ndesktop, customer-hosted, marketplaces, agent hosts). Each host exposes its own identity,\npermissions, tools and data. Naive designs either ignore host capabilities (rebuilding every\nintegration) or trust host declarations without verification (broken at runtime).\n\n## Decision\n\n- **Create once, deploy anywhere.** Domain logic, Projection Engine logic and canonical schemas\n  are built once; hosts are adapters. No host-specific forks.\n- **Host-first access. Spine-complete context. Policy-governed execution. Canonical\n  reconciliation.**\n- Every request is classified before routing (`host-local | entity | continuity | cross-system |\n  governance | write`, with completeness expectation and governance flag).\n- Capabilities are modeled as **HostCapability** (availability `confirmed | declared | unknown`;\n  declared is never proof of runtime access) and **SpineCapability** (`freshness: live/synced/\n  historical`; `authority: system-of-record/canonical/derived`).\n- **Read precedence:** confirmed host-native live → Spine canonical → IW-managed live connector →\n  Spine Cache/historical → request-connection → unavailable. The resolver may combine routes per\n  provider within one request.\n- **Write precedence:** resolve canonical target + policy → proposal → allowed routes → prefer\n  confirmed host-native when policy-approved → else Capability Fabric → receipt → normalize →\n  reconcile → rehydrate.\n- A **ConnectionBinding** maps host connection ↔ canonical principal ↔ optional IW integration.\n  ChatGPT (or any host) orchestrates its own connected apps; the IntegrateWise MCP never assumes\n  access to unrelated host-app connections.\n\n## Alternatives considered\n\n- Spine-only routing (always go through IntegrateWise connectors) — rejected: duplicates host\n  capabilities, slows first value, recreates the integration estate.\n- Host-only routing (no canonical layer) — rejected: no continuity, no cross-system context, no\n  governance; the isolated-desert outcome.\n\n## Consequences\n\nThe capability resolver must maintain confirmed-vs-declared availability with observed-at\ntimestamps; host capability discovery is part of the Discovery Engine's bootstrap contract;\nhost-native outcomes enter the same Loader/Normalizer path for reconciliation.\n"}