{"slug":"business/04-distribution-access-doctrine","title":"Distribution and access doctrine: IW-Continuity-Bridge","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/04-distribution-access-doctrine.mdx","bytes":3354,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nIW-Continuity-Bridge is the access and distribution layer for continuity capabilities. It is **not** the IntegrateWise product and it is not a second generic assistant. It gives approved entry points a semantic, policy-bound way to use the platform.\n\n## What the Bridge exposes\n\nThe Bridge should present user-meaningful operations, not raw internal topology. Its vocabulary includes:\n\n- orienting to active context, changes, history, decisions, commitments, knowledge, and prepared work;\n- asking for a grounded explanation or preparation;\n- retrieving available actions and plans;\n- requesting a governed proposal, approval, or persistence operation; and\n- creating a scoped context projection, state relay, agent handoff, or action delegation.\n\nThe Bridge is a facade over platform contracts. It must not expose internal databases, unrestricted memory, raw connector credentials, hidden prompts, or a bypass around policy and governance.\n\n## Approved access shapes\n\nDistribution may package the Bridge for an IntegrateWise application, an authenticated MCP client, a supported skill, or a starter integration. Each package must carry the same semantics, boundary checks, and auditability. Packaging is not authority: installation does not grant tenant access.\n\nAn access request must resolve the caller’s tenant membership and role server-side, establish a `ContextBoundary`, and return only the permitted projection. High-impact operations retain their existing approval and execution controls.\n\nInternal browser calls are forwarded through the Gateway only. The Gateway strips caller-supplied service identity headers and attaches a private `GATEWAY_CONNECTOR_AUTH_SECRET` assertion; the Bridge accepts forwarded identity only when that assertion matches its own configured secret. Deployments must configure the same secret on both services. Missing or mismatched assertions fail closed.\n\n## External availability status\n\n**Status: private alpha.** IW-Continuity-Bridge must not be advertised as public or marketplace-ready until tenant-membership authorization is verified for external OAuth/MCP clients.\n\nThe current release gate is explicit: a client must not be able to select or assert a tenant through free-form request data. Before public distribution, the authorization service must bind the authenticated principal to a verified tenant membership, enforce that binding on every Bridge call, and prove isolation with negative tests. Until then, Bridge packages are for controlled internal/private-alpha use only.\n\n## Release gate\n\nPublic distribution requires all of the following:\n\n1. verified tenant membership and role resolution for every external caller;\n2. target registration and policy enforcement for tool and agent exchanges;\n3. expiry, revocation, audit, and redaction tests for each exchange mode;\n4. no ability to retrieve private reasoning, credentials, or unscoped state; and\n5. product review confirming the package reinforces the Workbench experience rather than becoming a competing AI surface.\n\nPrepared exchanges are auditable boundary projections, not a recipient-delivery protocol. Before a tool or agent can claim one, the platform also needs recipient-authenticated delivery, one-time or leased retrieval, acknowledgement, and failure-state audit records.\n"}