{"slug":"strategy/business-strategy/DEVELOPER_AND_PARTNER","title":"IntegrateWise Developer and Partner Documentation","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/business-strategy/DEVELOPER_AND_PARTNER.mdx","bytes":16250,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Source of truth:** `docs/spec/INTEGRATEWISE_CANONICAL_SPEC_v1.0.md`  \n**Audience:** Developers, partners, integrators, and technical buyers  \n**Purpose:** Onboard quickly, understand the integration model, and implement against stable contracts\n\n---\n\n## How to Use This Docs Set\n\nStart with the conceptual model, then move to the integration model, then to implementation. If you are a partner, focus on the Integration Manager section and the four connection paths. If you are a developer extending the platform, focus on the Workbench and Capability Fabric sections.\n\nAll links in this docs set point to documents that should be created or expanded under this directory.\n\n---\n\n## 1. Conceptual Model\n\n### 1.1 What IntegrateWise Is\n\nIntegrateWise is not an automation tool, an integration platform, or an AI chat wrapper.\n\nIntegrateWise is an operational continuity platform.\n\nIt connects the tools a team already uses, preserves operational memory across those tools, and exposes that continuity through one composed Workbench.\n\nThe AI layer is a silent partner, not a replacement for user judgment.\n\n### 1.2 The Daily Loop From a Technical Perspective\n\nFrom the user's perspective:\n\n1. The Workbench opens with current context already assembled.\n2. The Twin understands the active work.\n3. The user asks, assigns, stores, or approves.\n4. The system executes, syncs, and remembers.\n\nFrom the runtime perspective:\n\n1. Configuration Manager compiles the effective tenant configuration.\n2. Integration Manager manages connections and capability sources.\n3. Activation Bridge compiles the active workspace.\n4. Data Pipeline ingests, normalizes, relates, and governs operational state.\n5. Adaptive Spine owns canonical truth.\n6. Continuity Bridge delivers active context.\n7. Workbench Composition renders the user's surface.\n8. Twin prepares, proposes, and waits.\n9. Governance evaluates authority and consequence.\n10. Hermes coordinates authorized execution.\n11. Sync reconciles connected systems.\n12. Promotion evaluates and promotes approved outcomes.\n\nThe user experience is simple.\n\nThe platform is precise.\n\n### 1.3 Where You Fit\n\nDevelopers and partners interact with IntegrateWise at three levels:\n\n- Connection: connect tools, systems, intelligence, and capabilities\n- Composition: extend Workbench behavior and context projection\n- Execution: implement runtime adapters, capability contracts, and governance hooks\n\nYou do not need to understand the full platform to contribute.\n\n---\n\n## 2. Integration Model\n\n### 2.1 The Four Paths\n\nIntegrateWise preserves four distinct connection and capability paths.\n\n| Path          | Purpose                                            | Typical Integrator                                      |\n| ------------- | -------------------------------------------------- | ------------------------------------------------------- |\n| API Connector | Connect operational systems                        | SaaS integrations, CRM/ERP/Support APIs                 |\n| MCP           | Connect tools and resource protocols               | MCP servers, tool providers                             |\n| AI Connector  | Connect intelligence providers                     | Model providers, embedding providers, reasoning systems |\n| API Wrapper   | Turn an API or function into a governed capability | Internal APIs, serverless functions, legacy services    |\n\n### 2.2 Connection vs Capability\n\nNot every connection should become a capability.\n\nA connection makes a system reachable.\n\nA capability defines how IntegrateWise uses that reachability: intent, inputs, outputs, authority, evidence requirements, execution mode, risk, governance policy, sync policy, and promotion policy.\n\n### 2.3 Integration Manager Ownership\n\nIntegration Manager owns:\n\n- connector lifecycle;\n- provider authentication binding;\n- capability discovery;\n- provider metadata;\n- webhook registration;\n- schema discovery;\n- sync configuration;\n- connection health.\n\nIntegration Manager does not own tenant runtime configuration.\n\nThat belongs to Configuration Manager.\n\n### 2.4 Partner Entry Points\n\n| Partner type         | Recommended path                     |\n| -------------------- | ------------------------------------ |\n| SaaS vendor          | API Connector or API Wrapper         |\n| Tool developer       | MCP                                  |\n| AI provider          | AI Connector                         |\n| Internal engineering | API Wrapper + custom runtime adapter |\n\n---\n\n## 3. Capability Fabric\n\n### 3.1 What a Capability Contract Defines\n\nA capability contract describes:\n\n- intent;\n- input schema;\n- output schema;\n- authority and required scopes;\n- evidence requirements;\n- execution mode;\n- sync mode;\n- promotion policy;\n- risk;\n- governance policy hints;\n- provider dependency;\n- runtime binding.\n\n### 3.2 Execution Resolution\n\nCapability Fabric answers: How can this intent be performed?\n\nThe valid execution paths are:\n\n- Local Execution\n- API Connector Action\n- API Wrapper Capability\n- MCP Invocation\n- AI Execution\n- Agent-to-Agent\n- Tool-to-Tool\n\n### 3.3 Runtime Adapter Contract\n\nA runtime adapter:\n\n- receives an authorized ExecutionPlan or capability invocation;\n- binds active context;\n- executes the capability;\n- emits an OutcomeEvent;\n- does not make governance decisions;\n- does not write to Spine directly;\n- does not assemble continuity context.\n\nHermes coordinates the runtime adapter.\n\nHermes does not replace the adapter.\n\n---\n\n## 4. Context Contracts\n\n### 4.1 The Three Canonical Contexts\n\n| Context              | Responsibility                                                                      |\n| -------------------- | ----------------------------------------------------------------------------------- |\n| SpineContext         | Canonical operational context retrieved from continuity state                       |\n| WorkbenchComposition | Role-aware UI, data, and capability composition                                     |\n| ContinuityBundle     | Portable active runtime context delivered to Twin, agent, capability, or AI runtime |\n\n### 4.2 Continuity Bundle Contents\n\nA continuity bundle contains:\n\n- spineContext;\n- optional workbench composition;\n- memory context;\n- knowledge context;\n- capability references;\n- evidence references;\n- authority context;\n- generatedAt;\n- expiresAt.\n\n### 4.3 Important Distinctions\n\n- Entity360 is a projection inside SpineContext.\n- AssembledContext is replaced by ContinuityBundle.\n- Active Context Bundle is the product-language name for ContinuityBundle.\n- Do not introduce additional context types without updating this specification.\n\n---\n\n## 5. Workbench Extension Model\n\n### 5.1 Composition Rules\n\nThe Workbench is configuration-driven.\n\nConfiguration Manager resolves the effective platform and tenant configuration before Workbench composition.\n\nCompiledTenantConfig determines:\n\n- enabled departments;\n- enabled domains;\n- role definitions;\n- Workbench composition rules;\n- available Context types;\n- visible fields;\n- field precedence;\n- enabled capabilities;\n- provider bindings;\n- Twin policy;\n- memory policy;\n- governance policy references;\n- approval requirements;\n- notification policy;\n- retention policy;\n- feature policy.\n\n### 5.2 Department Hubs\n\nThe Workbench is not a fixed dashboard.\n\nIt is the compositional operating hub for every department.\n\nEach department sees the fields, data, memory, knowledge, and capabilities relevant to its work.\n\nExamples:\n\n- Customer Success Hub\n- Revenue Hub\n- Engineering Hub\n- Operations Hub\n- Finance Hub\n\n### 5.3 Extension Points\n\n| Extension area         | Contract boundary                               |\n| ---------------------- | ----------------------------------------------- |\n| New domain             | Domain definition + Workbench composition rules |\n| New capability         | Capability contract + runtime binding           |\n| New connectivity path  | Integration Manager connection contract         |\n| New governance rule    | Governance policy reference                     |\n| New storage substrate  | Repository contract + adapter implementation    |\n| New experience surface | Gateway-projection API                          |\n\n---\n\n## 6. Governance and Approval Model\n\n### 6.1 Two Gates\n\n**Pre-Proposal Gate**\n\n- Authority\n- Scope\n- Policy\n\nResult:\n\n- ALLOW_PROCEED\n- REQUIRE_PRE_APPROVAL\n- DENY\n\n**Post-Proposal Gate**\n\n- Risk\n- Evidence\n- Confidence\n- Approval Requirement\n\nResult:\n\n- AWAITING_HUMAN_APPROVAL\n- HUMAN_APPROVED\n- DENY\n\n### 6.2 Invariant\n\nConfidence can increase trust in a proposal.\n\nConfidence never grants authority.\n\nA 0.99 confidence proposal with missing authority is DENY.\n\nA 0.99 confidence proposal for a consequential action can still require human approval.\n\n### 6.3 Approval Target\n\nApprove Twin's Action approves an ExecutionPlan, not an AI message.\n\nThe plan must describe:\n\n- what will happen;\n- where it will happen;\n- which records will change;\n- who will be contacted;\n- expected impact;\n- supporting evidence;\n- required authority;\n- execution-plan version.\n\n---\n\n## 7. Execution and Sync Model\n\n### 7.1 Modes\n\nExecution mode and synchronization mode are independent.\n\nExecution modes:\n\n- Local Execution\n- API Connector Action\n- MCP Invocation\n- API Wrapper Capability\n- AI Execution\n- Agent-to-Agent\n- Tool-to-Tool\n\nSync modes:\n\n- Immediate\n- Deferred\n- Scheduled\n- Batch\n- Event-Driven\n- Reconciliation\n\n### 7.2 Promotable Outcomes\n\nNot every execution outcome promotes to the Spine.\n\nPromotion is capability-aware and governance-aware.\n\nThe promotion decision may result in:\n\n- PROMOTE\n- HOLD\n- REJECT\n- NO_OP\n\n---\n\n## 8. State Substrate\n\n### 8.1 Semantic Planes\n\n| Semantic Plane | Responsibility                             |\n| -------------- | ------------------------------------------ |\n| Adaptive Spine | canonical operational truth                |\n| Spine Cache    | hot projections and hydration acceleration |\n| Memory Fabric  | memory metadata and lifecycle              |\n| Knowledge      | semantic retrieval representations         |\n| Twin Runtime   | session coordination and active runtime    |\n| Blobs          | large immutable or versioned artifacts     |\n| Sync State     | convergence progress                       |\n\n### 8.2 Swappable Provider Contract\n\nProduct code talks to stable repository contracts.\n\nThe Configuration Manager selects physical providers and adapters.\n\nNo product logic imports D1, KV, R2, Vectorize, OpenAI, Supabase, or Redis SDKs directly.\n\n### 8.3 Customer Zero Physical Bindings\n\n| Semantic Plane | Customer Zero Binding               |\n| -------------- | ----------------------------------- |\n| Adaptive Spine | D1 / Postgres                       |\n| Spine Cache    | KV                                  |\n| Memory Fabric  | D1 + KV + Vectorize                 |\n| Knowledge      | D1 metadata + R2 source + Vectorize |\n| Twin Runtime   | Durable Object                      |\n| Blobs          | R2                                  |\n| Sync State     | D1 + queues                         |\n\n---\n\n## 9. Developer Onboarding\n\n### 9.1 Repository Orientation\n\nThe repository is organized around platform services and packages.\n\nKey areas:\n\n- packages: shared contracts, types, SDKs, utilities\n- services: runtime services, workers, APIs\n- apps: user-facing experiences and surfaces\n- docs: product, platform, marketing, sales, and technical documentation\n\n### 9.2 Canonical Document Map\n\n| Document                                               | Purpose                                      |\n| ------------------------------------------------------ | -------------------------------------------- |\n| `docs/spec/INTEGRATEWISE_CANONICAL_SPEC_v1.0.md`       | Top-level product and platform specification |\n| `docs/architecture/CANONICAL_PLATFORM_ARCHITECTURE.md` | Platform architecture reference              |\n| `docs/product/L1_WORKBENCH.md`                         | L1 Workbench surface specification           |\n| `docs/architecture/WORKBENCH_DOCTRINE.md`              | Workbench composition doctrine               |\n| `docs/architecture/SPINE_MODEL.md`                     | Spine data model                             |\n| `docs/architecture/UNIFIED_GOVERNANCE_SPEC.md`         | Unified governance specification             |\n\n### 9.3 Contribution Rules\n\n- Follow the canonical contract chain.\n- Do not bypass repository abstractions.\n- Do not expose provider SDKs to product code.\n- Preserve state ownership boundaries.\n- Do not collapse the four connection paths.\n- Do not bypass governance.\n- Do not merge Activation Bridge and Continuity Bridge.\n\n---\n\n## 10. Partner Quick Reference\n\n### 10.1 What Partners Build\n\n| Partner archetype  | Typical contribution                                     |\n| ------------------ | -------------------------------------------------------- |\n| SaaS vendor        | API Connector or API Wrapper                             |\n| Tool vendor        | MCP server or MCP-compatible tool interface              |\n| AI provider        | AI Connector adapter                                     |\n| Systems integrator | API Wrapper capabilities and Workbench composition rules |\n| Embedded partner   | Experience surface using Gateway Projection APIs         |\n\n### 10.2 What Partners Should Not Build\n\n- Direct Spine writes outside governed promotion\n- Bypass governance hooks\n- Hard-code provider SDKs into shared contracts\n- Collapse distinct connection paths into one generic connector\n- Autonomously execute on behalf of users without approval\n\n### 10.3 Partner Success Criteria\n\nA partner integration is complete when:\n\n- The connection is discoverable and healthy;\n- The capability has a valid contract;\n- The capability respects authority and scope;\n- The capability emits observable OutcomeEvents;\n- The partner does not require platform code changes to enable the connection for new tenants.\n\n---\n\n## 11. Troubleshooting\n\n### 11.1 Integration Issues\n\nCheck:\n\n- connection health in Integration Manager;\n- provider authentication and credential status;\n- schema discovery logs;\n- webhook registration and delivery;\n- sync cursors and checkpoint state.\n\n### 11.2 Capability Issues\n\nCheck:\n\n- capability registry entry and contract validity;\n- required authority and scopes;\n- execution mode binding;\n- governance decision history;\n- OutcomeEvent and error state.\n\n### 11.3 Governance Issues\n\nCheck:\n\n- Pre-Proposal and Post-Proposal decision history;\n- approval policy assignment;\n- affected systems and entity scope;\n- evidence attachment;\n- execution plan version state.\n\n---\n\n## 12. Glossary\n\n| Term                  | Meaning                                                                |\n| --------------------- | ---------------------------------------------------------------------- |\n| User Workbench        | The compositional operating hub for every department                   |\n| Twin                  | A persistent AI assistant that reasons over active context             |\n| Continuity            | Operational memory that persists across tools, sessions, and providers |\n| Adaptive Spine        | The canonical truth layer                                              |\n| Capability Fabric     | The runtime resolver for how work can be performed                     |\n| ExecutionPlan         | The governed, versioned plan approved by the user                      |\n| Hermes                | The execution coordinator                                              |\n| Sync Engine           | The convergence controller for connected systems                       |\n| Continuity Pipeline   | The transformation and promotion path for outcomes                     |\n| Governance            | The authority boundary evaluated in two gates                          |\n| Store in Spine        | Observe action                                                         |\n| Ask Your Twin         | Orient action                                                          |\n| Assign Your Twin      | Decide action                                                          |\n| Approve Twin's Action | Act action                                                             |\n"}