{"slug":"internal/architecture/INTEGRATEWISE_CANONICAL_SPEC_v1.0","title":"IntegrateWise Canonical Product and Platform Specification","section":"internal","sectionLabel":"Internal","status":"unclassified","type":"document","path":"internal/architecture/INTEGRATEWISE_CANONICAL_SPEC_v1.0.mdx","bytes":39915,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Status: SUPERSEDED v1.0 SOURCE.** This document is retained as product\n> genealogy and is not the current canonical specification. Descope authority,\n> D1/Postgres ambiguity, older UI-layer language and any conflicting execution\n> behavior are superseded by\n> [`../architecture/ARCHITECTURE_LOCK.md`](../architecture/ARCHITECTURE_LOCK.md),\n> [`../architecture/IMPLEMENTATION_CONTRACT_v1.1.md`](../architecture/IMPLEMENTATION_CONTRACT_v1.1.md)\n> and\n> [`../architecture/CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md`](../architecture/CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md).\n\n**Version:** 1.0  \n**Original Status:** CANONICAL\n**Primary Experience:** User Workbench  \n**AI Experience:** Your Twin  \n**Interaction Model:** See → Ask → Assign → Approve  \n**Internal Operating Model:** OODA — Observe, Orient, Decide, Act  \n**Brand Doctrine:** Truth you own. AI you rent. Approval in between.\n\n---\n\n## How to Use This Document\n\nThis specification is the single source of truth for IntegrateWise product behavior, platform architecture, runtime boundaries, state ownership, and canonical contracts.\n\nIt is divided into two parts:\n\n- **Part I — Product** defines what the user experiences, the Workbench surfaces, the four-button interaction grammar, Twin behavior, and end-to-end workflows.\n- **Part II — Platform** defines how the product is implemented: Configuration Manager, Integration Manager, Activation Bridge, data continuity, state substrate, Memory Fabric, retrieval, Context Contracts, Capability Fabric, Governance, Hermes, Sync, Promotion, and the runtime contract chain.\n\nWhen this document conflicts with earlier architecture notes, deck copy, or generated files, this document wins.\n\n---\n\n## PART I — PRODUCT\n\n### 1. The Problem\n\nPeople already know how to do their jobs.\n\nThe problem is everything they have to do around the job.\n\nEvery day starts with finding context.\n\nOpen the inbox.\n\nCheck messages.\n\nOpen the CRM.\n\nLook through tasks.\n\nFind the last meeting notes.\n\nCheck what changed.\n\nRemember what was promised.\n\nSearch for a document.\n\nCompare information across tools.\n\nUpdate one system after changing another.\n\nThen open an AI assistant and explain the situation again.\n\nThe real work is surrounded by repetitive preparation, context gathering, remembering, searching, copying, checking, and updating.\n\nAI was supposed to make this easier.\n\nInstead, most AI starts from a blank conversation.\n\nIt does not reliably know what the user is working on.\n\nIt forgets useful work context.\n\nIts memory can drift away from operational reality.\n\nIt often requires the user to gather the same information that the AI was supposed to help with.\n\nAnd when AI is allowed to act freely, the user loses visibility and control.\n\nIntegrateWise removes this daily cycle.\n\n---\n\n### 2. The Product\n\nIntegrateWise gives the user one place to work and an AI Twin that stays with the work.\n\nThe user's work is brought together from the tools they already use.\n\nThe Twin understands the work currently in front of the user.\n\nIt remembers useful context the user has allowed it to remember.\n\nIt knows what changed.\n\nIt can find the information the user would normally search for.\n\nIt prepares the summaries, drafts, comparisons, follow-ups, research, updates, and next steps that normally consume the user's time.\n\nThe user does not have to explain the same work again every day.\n\nThe Twin does the hard lifting around the job.\n\nThe user reviews the work.\n\nThe user makes the decision.\n\nThe user approves anything important before it happens.\n\nThe next day does not start from zero.\n\nThe work continues with context.\n\n---\n\n### 3. The Daily Experience\n\n#### See what matters\n\nOpen IntegrateWise.\n\nYour current work is already there.\n\nSee what needs attention.\n\nSee what changed.\n\nSee where you left off.\n\nSee what is waiting for you.\n\n#### Ask without starting again\n\nAsk your Twin about the work in front of you.\n\nYou do not need to copy the customer name.\n\nYou do not need to paste the previous meeting notes.\n\nYou do not need to explain which task you are working on.\n\nThe Twin already has the permitted context of the work.\n\n#### Give the hard lifting to your Twin\n\nAssign the preparation work.\n\nResearch this issue.\n\nCompare these options.\n\nPrepare me for this meeting.\n\nDraft the follow-up.\n\nFind what changed.\n\nSummarize the account.\n\nCheck the dependencies.\n\nPrepare the update.\n\nBuild the next-step plan.\n\nThe Twin prepares the work and brings it back for review.\n\n#### Stay in control\n\nThe Twin does not quietly send an email because it thinks the email is correct.\n\nIt does not update a customer record because its confidence score is high.\n\nIt does not make a business decision and execute it in the background.\n\nWhen something important should happen, the user sees what is proposed.\n\nThe user reviews it.\n\nThe user approves it.\n\nThen IntegrateWise helps get it done.\n\n#### Continue with context\n\nWhat happened becomes part of the continuing work.\n\nThe next task has the previous decision.\n\nThe next meeting has the previous commitments.\n\nThe next question has the relevant context.\n\nThe Twin does not begin every session as a stranger.\n\n---\n\n### 4. The Simple Product Promise\n\n**Your work is already in context.**\n\n**Your Twin remembers the work.**\n\n**AI does the hard lifting.**\n\n**You stay in control.**\n\nThat is IntegrateWise.\n\nEverything else in this specification exists to make those four promises reliable.\n\n---\n\n### 5. The User Interaction Model\n\nThe user should not need to understand OODA, capability contracts, execution runtimes, promotion policies, or continuity infrastructure.\n\nThe visible interaction model is simple:\n\n#### Store in Spine\n\nKeep this as part of my work.\n\n#### Ask Your Twin\n\nHelp me understand this.\n\n#### Assign Your Twin\n\nDo the hard preparation for me.\n\n#### Approve Twin's Action\n\nI reviewed this. Go ahead.\n\nInternally, these actions map to Observe, Orient, Decide, and Act.\n\nOODA is the internal operating model.\n\nThe four actions are the product language.\n\n---\n\n### 6. The User Workbench\n\nThe User Workbench is where the user does their daily job.\n\nIt is not another dashboard to monitor.\n\nIt is not a blank AI chat.\n\nIt is not a replacement for every specialist tool.\n\nIt brings together the parts of those tools that matter to the user's work.\n\nA Customer Success user may need customer details, support history, product usage, billing state, meetings, commitments, open work, and recent communication.\n\nA Finance user may need invoices, payments, vendors, approvals, exceptions, and cash-related work.\n\nAn Engineering user may need issues, incidents, code activity, documentation, dependencies, and current decisions.\n\nA founder may need customers, revenue, product, hiring, finance, commitments, and company decisions.\n\nEach person sees the work relevant to their role.\n\nTheir Twin works with that same context.\n\nThe Workbench and the Twin are two parts of the same daily experience.\n\n---\n\n### 7. What IntegrateWise Must Remove\n\nIntegrateWise succeeds when the user spends less time:\n\n- finding information;\n- switching between tools;\n- reconstructing context;\n- remembering previous commitments;\n- repeating information to AI;\n- preparing repetitive work;\n- manually comparing systems;\n- copying updates between tools;\n- checking whether work was completed;\n- rebuilding yesterday's context.\n\nThe product should not be measured by how many AI messages the user sends.\n\nA better product may result in fewer AI conversations because the Twin already understands the work and prepares useful output before another long explanation is required.\n\n---\n\n### 8. Product-to-Platform Translation\n\nThe user buys a simpler working day.\n\nThe platform exists to make that experience dependable.\n\n| What the user expects                | What IntegrateWise uses internally |\n| ------------------------------------ | ---------------------------------- |\n| My work is together                  | User Workbench                     |\n| I do not search five tools           | Common Connected Surface           |\n| It knows what I am working on        | Active Context                     |\n| It remembers useful context          | Memory                             |\n| It does not forget what happened     | Adaptive Spine                     |\n| AI does not drift away from the work | Context and memory boundaries      |\n| It finds the right information       | Knowledge and Retrieval            |\n| AI prepares the hard work            | Twin                               |\n| I can give AI preparation work       | Assign Your Twin                   |\n| It can use my connected tools        | Capability Fabric                  |\n| It does not act behind my back       | Governance                         |\n| I see exactly what will happen       | ExecutionPlan                      |\n| I decide whether it happens          | Approve Twin's Action              |\n| The approved work gets done          | Hermes and Runtime                 |\n| My tools remain updated              | Sync                               |\n| Tomorrow starts with context         | Continuity                         |\n\nFrom this point forward, the specification defines the product and platform mechanisms used to keep these promises.\n\n---\n\n## PART II — PLATFORM\n\n### 9. Primary Information Architecture\n\n#### 9.1 Global Navigation\n\nThe main navigation contains:\n\n1. Home\n2. My Work\n3. Contexts\n4. Meetings\n5. Knowledge\n6. Approvals\n7. Timeline\n\nSecondary items:\nConnections, Twin Activity, Settings, Help, Administration\n\n#### 9.2 Global App Shell\n\n**Left Rail**  \nLogo, workspace selector, primary navigation, pinned contexts, recent contexts, connection-health indicator, user profile/settings.\n\n**Top Bar**  \nUniversal search, current workspace, contextual breadcrumb, notifications, approval count, Twin status, connection/sync status, user menu.\n\n**Main Canvas**  \nActive product surface.\n\n**Right Contextual Panel**  \nCurrent-context summary, Twin observations, related evidence, prepared work, suggested next actions, quick connected-system actions. Collapsible, resizable on desktop, drawer on tablet, full-screen sheet on mobile.\n\n**Bottom Action Sheet**  \nUsed only for urgent Twin proposals, approval requests, action previews, execution progress, and recoverable failures. It must not permanently obstruct work.\n\n---\n\n### 10. Home\n\n#### 10.1 Purpose\n\nHome answers: **What should I know and do now?**\n\nIt is personalized by user role, assignments, active contexts, priorities, connected-system changes, due dates, recent activity, organizational policy, and validated work preferences.\n\n#### 10.2 Home Layout\n\n**A. Resume Work**  \nLast active context, active task, last viewed section, unresolved draft, pending approval, latest relevant change.\n\nPrimary action: Resume  \nSecondary actions: Open context, Review changes, Dismiss from Home\n\n**B. My Priorities**  \nRanked work requiring attention. Each item includes title, context or entity, priority, due date, source system, reason for ranking, current status, and available actions. Twin may add: Why this matters, What changed, or Prepared next step.\n\n**C. What Changed**  \nMeaningful operational changes rather than raw activity.\n\nExamples:\n\n- account health declined after unresolved tickets;\n- opportunity stage changed without forecast update;\n- project deadline moved;\n- payment failed;\n- meeting action item became overdue.\n\nEach card includes change summary, time, affected context, previous and current state, source, impact, evidence, and suggested response.\n\n**D. Prepared by Twin**  \nNon-executed preparation: meeting briefs, response drafts, account summaries, follow-up plans, report drafts, issue analyses, proposed record updates.\n\nEach item includes output type, context, creation reason, source count, freshness, confidence or uncertainty indicator, and review action.\n\n**E. Decisions and Approvals**  \nApprovals required, approving actor, action impact, affected systems, deadline, risk level, current execution-plan version.\n\n**F. Upcoming**  \nMeetings, commitments, deadlines, renewals, milestones, scheduled workflows.\n\n---\n\n### 11. My Work\n\n#### 11.1 Purpose\n\nMy Work is the user's unified operational queue across connected systems.\n\n#### 11.2 Views\n\nToday, Upcoming, Assigned to Me, Assigned to Twin, Waiting, Blocked, Completed, custom saved views.\n\n#### 11.3 Work Item Model\n\nEvery work item displays: title, work type, status, priority, owner, due date, associated context, source provider, related dependencies, last meaningful change, Twin preparation state, and available actions.\n\n#### 11.4 Work Item Details\n\nOverview, description, current state, context and relationships, evidence, activity, Twin preparation, provider actions, execution and sync status.\n\n#### 11.5 Unified Actions\n\nDepending on capability and authorization, the user may: update status, change owner, add a note, set a due date, send a message, create a related task, update a provider record, assign preparation to Twin, approve a proposed action, or mark resolved.\n\n---\n\n### 12. Contexts and Context360\n\n#### 12.1 Context Definition\n\nA context is a connected operational object around which work occurs.\n\nExamples: customer, account, opportunity, project, incident, ticket, product, campaign, employee, candidate, vendor, contract, invoice.\n\n#### 12.2 Contexts Index\n\nSearch, filtering, sorting, saved views, role-specific columns, recent contexts, pinned contexts, at-risk contexts, contexts with changes, contexts requiring decisions.\n\nOperational relevance is prioritized over static CRM-style listing.\n\n#### 12.3 Context360 Header\n\nContext name, context type, current status, owner, health or risk state, key identifiers, latest meaningful change, freshness, source systems, primary actions.\n\n#### 12.4 Context360 Tabs\n\nThe canonical tab set includes:\n\n1. Overview\n2. Work\n3. Relationships\n4. Timeline\n5. Meetings\n6. Knowledge\n7. Files\n8. Decisions\n9. Systems\n\n#### 12.5 Progressive Loading\n\nContext360 loads in order:\n\n1. identity and header\n2. key operational state\n3. current work\n4. primary relationships\n5. recent timeline\n6. knowledge and files\n7. Twin-generated interpretation\n\n| State           | Target Response Time                    |\n| --------------- | --------------------------------------- |\n| Prepped context | Immediate perceived display             |\n| Warm context    | 200 ms for cached projection            |\n| Cold context    | 2–4 seconds with progressive loading    |\n| AI enrichment   | Asynchronous; never blocks core context |\n\nEvery cached projection displays freshness metadata when relevant.\n\n---\n\n### 13. Meetings\n\n#### 13.1 Meeting List\n\nUpcoming, Today, Needs Preparation, Follow-up Required, Past Meetings.\n\n#### 13.2 Meeting Detail\n\nTitle, participants, linked contexts, calendar source, agenda, previous commitments, open work, recent changes, relevant documents, Twin-prepared brief, notes, decisions, follow-up actions.\n\n#### 13.3 Silent Preparation\n\nTwin prepares a meeting brief automatically when:\n\n- the meeting is approaching;\n- relevant context exists;\n- the user has access;\n- preparation is permitted;\n- source freshness is sufficient.\n\nThe brief includes purpose, relationship summary, changes since the previous interaction, unresolved commitments, risks, suggested questions, and relevant evidence.\n\nThe brief must be explicitly labeled as AI-prepared and remain fully editable.\n\n---\n\n### 14. Knowledge\n\n#### 14.1 Purpose\n\nKnowledge provides evidence-backed access to organizational information without requiring users to know where every artifact is stored.\n\n#### 14.2 Knowledge Views\n\nSearch, Recommended, Recent, Saved, Policies, Playbooks, Context-linked knowledge.\n\n#### 14.3 Search Results\n\nEach result displays title, source, content type, owner, last updated, access level, related contexts, matching excerpt, and freshness.\n\nAI-generated answers provide explicit citations to source artifacts.\n\n---\n\n### 15. Approvals\n\n#### 15.1 Purpose\n\nApprovals provide a single review surface for proposed consequential actions.\n\n#### 15.2 Approval Queue\n\nNeeds My Approval, Submitted by Me, In Execution, Completed, Rejected, Failed, Expired.\n\n#### 15.3 Approval Detail\n\nEvery approval must show:\n\n- proposed action;\n- business purpose;\n- initiating user or Twin assignment;\n- affected contexts;\n- affected systems;\n- exact fields or operations;\n- evidence;\n- execution-plan version;\n- risk classification;\n- approval policy;\n- expected outcome;\n- rollback or recovery availability.\n\nAvailable decisions:\nApprove, Reject, Request Changes, Edit and Approve, Delegate Approval, Cancel.\n\nIf a proposal changes after approval, the changed version must be approved again when its consequence boundary changes.\n\n---\n\n### 16. Timeline\n\n#### 16.1 Purpose\n\nTimeline is the normalized continuity record across user work, provider events, Twin preparation, decisions, and outcomes.\n\n#### 16.2 Event Types\n\nProvider change, user action, Twin observation, prepared output, proposed action, approval, execution, synchronization, promotion, rejection, failure, recovery, memory update.\n\n#### 16.3 Timeline Event Anatomy\n\nEach event includes: event type, actor, timestamp, affected context, source, description, evidence, before-and-after state when applicable, and execution or sync status.\n\nRaw technical events are grouped into understandable business changes by default.\n\n---\n\n### 17. Twin in L1\n\n#### 17.1 Twin States\n\n- Quiet\n- Observing\n- Prepared\n- Attention\n- Approval Required\n- Executing\n- Completed\n- Blocked\n\n**Observing** must not imply that private or unrestricted user activity is being recorded.\n\n#### 17.2 Twin Panel Sections\n\n- Current Context\n- What Twin Noticed\n- Prepared for You\n- Suggested Next Step\n- Evidence\n- Activity\n\n#### 17.3 Canonical Workbench Actions\n\nThe universal interaction grammar is:\n\n- Store in Spine\n- Ask Your Twin\n- Assign Your Twin\n- Approve Twin's Action\n\nSupporting actions:\nDismiss, Save for later, Show evidence, Correct, Reduce similar suggestions, Report incorrect context.\n\n---\n\n### 18. OODA Interaction Model\n\n#### 18.1 Observe — Store in Spine\n\nCapture operational truth.\n\nStore notes, facts, decisions, commitments, evidence, documents, and meeting outcomes.\n\nThe system also captures authorized operational events from connected systems.\n\nNot every single event becomes canonical truth.\n\n#### 18.2 Orient — Ask Your Twin\n\nRetrieve and interpret active continuity context.\n\nTwin answers using:\n\n- active Workbench context;\n- Spine state;\n- relationships;\n- recent changes;\n- permitted memory;\n- knowledge;\n- provider data;\n- relevant policies.\n\nQuestions automatically inherit the active context unless the user explicitly changes scope.\n\n#### 18.3 Decide — Assign Your Twin\n\nDelegate preparation:\n\n- investigate an issue;\n- compare alternatives;\n- prepare a meeting;\n- draft a response;\n- produce a report;\n- determine affected work;\n- create a proposed plan.\n\nAn assignment produces a reviewable output.\n\nIt does not automatically grant execution authority.\n\n#### 18.4 Act — Approve Twin's Action\n\nBefore approval, the UI displays:\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\nAfter approval, the UI displays:\n\n- execution progress;\n- provider responses;\n- partial completion;\n- failure and retry states;\n- synchronization results;\n- final outcome.\n\n**Twin never receives a direct Act button.**\n\nThe fourth button is **Approve Twin's Action**, not Run Twin, Execute, or Automate.\n\n---\n\n### 19. Silent Partner Behavior\n\n#### 19.1 Intervention Levels\n\n- Level 0 — No Surface\n- Level 1 — Passive Indication\n- Level 2 — Contextual Card\n- Level 3 — Attention Notification\n- Level 4 — Decision Required\n- Level 5 — Blocking Policy Event\n\n#### 19.2 Interruption Rules\n\nTwin interrupts only when at least one condition is met:\n\n- user impact is material;\n- the action is time-sensitive;\n- confidence and evidence are sufficient;\n- a policy decision is required;\n- the user requested notification;\n- execution is blocked or failed.\n\nRepeated low-value suggestions are automatically suppressed.\n\n---\n\n### 20. Context and Memory Model\n\n- **Working Context:** temporary context including current page, active entity, selected work item, active filter, current meeting, in-progress draft, and recent Workbench actions. Working context expires and is not automatically committed as permanent memory.\n- **Candidate Memory:** Twin may identify potential operational patterns. Candidate memories remain tentative.\n- **Promoted Memory:** a memory becomes durable through applicable validation, confidence thresholds, user confirmation, organizational policy, retention controls, and source provenance.\n- **Correction:** users can correct a Twin assumption, remove a memory, change a preference, identify an incorrect relationship, report stale context, or prevent similar suggestions.\n\nTwin Memory is durable AI/user continuity.\n\nSpine Memory is canonical operational truth.\n\nSession Logs are interaction history.\n\nAudit Logs are accountability and execution lineage.\n\nThese are separate substrates.\n\n---\n\n### 21. Connected-System Actions\n\n#### 21.1 Capability Rendering\n\nThe Workbench renders actions based on:\n\n- provider capabilities;\n- active context;\n- user authority;\n- organization policy;\n- connection health;\n- required fields;\n- current provider state.\n\nUnavailable actions must clearly explain why they are disabled.\n\n#### 21.2 Execution States\n\nDraft -> Validating -> Approval Required / Authorized -> Queued -> Executing -> Provider Confirmed -> Synchronizing -> Completed\n\nAlternative states:\nDenied, Cancelled, Partially Completed, Failed, Retry Available, Recovery Required, Sync Conflict\n\n#### 21.3 Provider Transparency\n\nUsers see exactly:\n\n- which provider is affected;\n- which account or connection is used;\n- what data will be sent;\n- whether the provider confirmed the operation;\n- whether the Spine has reconciled the result.\n\nTechnical adapter details remain hidden unless needed for deep troubleshooting.\n\n---\n\n### 22. Key End-to-End Workflows\n\n#### 22.1 Resume Daily Work\n\nUser opens Home -> Home restores previous active context -> Spine supplies current state and changes -> Twin silently compares new state with the previous session -> Home shows Resume Work and changes -> User resumes without manual briefing.\n\n**Do not use Observe Pipeline or Orient Pipeline as named service boundaries.**\n\n#### 22.2 Context Risk Detected\n\nConnected-system event enters the Data Pipeline -> Spine links it to the appropriate context -> Continuity Bridge assembles relevant operational context -> Twin trigger policy evaluates whether cognitive analysis is warranted -> Twin identifies a material risk -> A contextual card appears in Context360 -> User reviews evidence, and Twin prepares recommended next steps.\n\n#### 22.3 Draft and Send Follow-Up\n\nTwin detects an unresolved commitment -> Twin prepares a follow-up draft -> Workbench shows the draft non-intrusively -> User reviews and edits -> System displays recipients and provider -> User approves sending -> Hermes dispatches the authorized ExecutionPlan -> Outcome is logged in Timeline.\n\n#### 22.4 Meeting Preparation\n\nCalendar event is observed -> Participants are linked to Spine contexts -> Recent updates are assembled -> Twin prepares a brief -> User opens meeting and reviews brief -> Post-meeting decisions and follow-ups are proposed for validation.\n\nThe correct runtime chain is:\n\n1. User requests or initiates an operational change.\n2. Capability Fabric resolves the applicable CapabilityContract.\n3. Pre-Proposal Governance evaluates authority, scope, policy.\n4. Twin or the deterministic planning runtime prepares the proposed outcome.\n5. Plan Builder converts the proposal and capability contracts into an ExecutionPlan.\n6. Post-Proposal Governance evaluates risk, evidence, confidence, approval requirement.\n7. The Workbench previews the governed ExecutionPlan.\n8. The user approves when required.\n9. Hermes receives the authorized ExecutionPlan.\n10. Runtime adapters execute the plan steps.\n11. OutcomeEvents are emitted.\n12. Sync reconciles provider state.\n13. Promotion evaluates whether the resulting state becomes canonical Spine truth.\n14. Context360 rehydrates.\n15. Timeline records proposal -> approval -> execution -> sync -> promotion.\n\n**Approve Twin's Action approves an ExecutionPlan, not an AI message.**\n\n---\n\n## PART II — PLATFORM\n\n### 23. Configuration Manager\n\n#### 23.1 Purpose\n\nConfiguration Manager defines how the tenant operates.\n\nIt compiles the effective runtime configuration from platform defaults, deployment profile, environment profile, tenant configuration, tenant policy, and runtime feature policy.\n\n#### 23.2 Authority\n\nConfiguration Manager owns:\n\n- provider selection;\n- adapter selection;\n- binding references;\n- runtime policies;\n- consistency requirements;\n- isolation requirements;\n- retention policy;\n- residency requirements;\n- failover selection;\n- feature policy;\n- effective config compilation.\n\nConfiguration Manager never owns provider credentials.\n\n#### 23.3 Output\n\nCompiledTenantConfig\n\n#### 23.4 Effective Configuration Precedence\n\nPlatform Default -> Deployment Profile -> Environment Profile -> Tenant Config -> Tenant Policy -> Runtime Feature Policy -> Effective Config\n\nNot every layer may override every field.\n\nSome fields are platform-only:\n\n- mandatory audit;\n- governance bypass prevention;\n- tenant isolation;\n- encryption floor;\n- platform safety policy.\n\n---\n\n### 24. Integration Manager and Four Connection Paths\n\nIntegrateWise preserves four distinct connection and capability paths.\n\n**Authorization authority:** Descope is the canonical external authorization authority for supported outbound connections (where supported). IntegrateWise owns connector semantics, connection bindings, tenant/workspace ownership, configuration, wiring, activation, capability definitions, governance, routing, and continuity. Descope owns external authorization, outbound connection authorization state, credential/token lifecycle, and external authorization resource identity. Nango is classified as legacy/dormant compatibility until provider-specific runtime evidence proves it is still required; it is not the default architecture.\n\nSpine does not eliminate future authorization requirements. Descope owns the authorization lifecycle; Spine retains canonical operational continuity so future work does not start with empty context.\n\n**Canonical runtime law:** Connectors provide reach. Connections provide authorized access. Capabilities provide bounded actions. Governance provides permission. Hermes coordinates execution. Spine remembers.\n\nRouting selects. Governance authorizes. Hermes coordinates. The activated execution adapter executes. Pipeline promotes the result. Spine retains canonical continuity.\n\n**MCP surface boundary:** IW-Continuity-Bridge is the public semantic MCP surface (fixed IntegrateWise semantic contract). External AI clients (ChatGPT, Claude, Perplexity, Hermes) connect through the Bridge. The Descope MCP Adapter (established at commit `5c15413e`) is an internal execution adapter that resolves Descope-managed outbound authorization and executes an already selected, governed, activated provider route. External AI clients must not connect directly to the Descope MCP execution surface.\n\n#### 24.1 MCP\n\nConnects tool and resource protocols.\n\nDiscovers tools, resources, prompts, schemas, and server capabilities.\n\nGoverns tool/resource invocation.\n\nMCP connects tools.\n\n#### 24.2 AI Connector\n\nConnects intelligence providers and AI runtimes.\n\nModels, embeddings, reasoning, multimodal intelligence, specialized AI services.\n\nAI Connector connects intelligence.\n\nNo model owns canonical operational truth.\n\n#### 24.3 API Connector\n\nConnects operational systems.\n\nProvider authentication, OAuth lifecycle, schemas, objects, fields, events, reads, writes, webhooks, cursors, checkpoints, incremental hydration, synchronization.\n\nAPI Connector connects systems.\n\n#### 24.4 API Wrapper\n\nConverts an API, function, workflow, or service into an IntegrateWise capability.\n\nDefines intent, inputs, outputs, authority, evidence requirements, execution mode, risk, governance policy.\n\nAPI Wrapper creates capabilities.\n\n**The Four-Path Law**: API Connectors connect systems. MCP connects tools. AI Connectors connect intelligence. API Wrappers create capabilities.\n\nAll four paths enter the Capability Registry under distinct contracts.\n\nThey do not share one generic integration contract.\n\n---\n\n### 25. Activation Bridge and Continuity Bridge\n\n#### 25.1 Activation Bridge\n\nCompiles:\n\n- compiled tenant configuration;\n- connected ecosystem;\n- organization structure;\n- user identity;\n- department;\n- role;\n- available data;\n- available capabilities;\n- governance policy.\n\nProduces the Active Workspace Definition.\n\nHydration phases:\n\n- Instant Hydration\n- Operational Hydration\n- Historical Hydration\n\n#### 25.2 Continuity Bridge\n\nDelivers the active context bundle to the active runtime.\n\nResolves:\n\n- user memory;\n- work memory;\n- organization memory;\n- Twin memory;\n- active entities;\n- relevant relationships;\n- recent decisions;\n- current work state;\n- available evidence;\n- relevant knowledge;\n- capability context.\n\nProduces the Active Context Bundle.\n\nActivation Bridge and Continuity Bridge are separate contracts.\n\nDo not merge them.\n\n---\n\n### 26. Data Continuity\n\n#### 26.1 Common Connected Surface\n\nOne logical operational surface across independent systems.\n\nConnected tools retain provider boundaries.\n\nIntegrateWise creates a shared operational layer.\n\nThe Common Connected Surface understands provider identity, tool category, objects, fields, schemas, entities, relationships, capabilities, events, authority, sync behavior, and data ownership.\n\n#### 26.2 Creamy Load\n\nDeep initial continuity formation.\n\nDiscover -> Select -> Extract -> Parse -> Normalize -> Synthesize -> Relate -> Govern -> Promote -> Hydrate\n\nGoal: create enough normalized and related operational state for the organization to begin working from IntegrateWise.\n\n#### 26.3 Delta Load\n\nContinuously absorb changes.\n\nDetect -> Capture Delta -> Resolve Source and Entity -> Parse -> Normalize -> Synthesize -> Compare with Spine State -> Govern -> Promote or Queue -> Invalidate or Refresh Cache -> Rehydrate Active Context\n\n#### 26.4 Streaming Load\n\nContinuous event-driven hydration for high-volume or real-time sources.\n\n#### 26.5 Spine Networking\n\nThe Spine is the canonical context and continuity network.\n\nIt is not an ESB.\n\nTools connect once to IntegrateWise.\n\nCanonical entities and governed context become reusable across every authorized Workbench, Twin, agent, and capability.\n\nSpine Networking understands:\n\n- source ownership;\n- canonical state;\n- consumer scope;\n- write authority;\n- sync policy.\n\n---\n\n### 27. State Substrate\n\n#### 27.1 Semantic planes\n\n| Semantic Plane | Responsibility                             | Physical Customer Zero Binding      |\n| -------------- | ------------------------------------------ | ----------------------------------- |\n| Adaptive Spine | canonical operational truth                | D1 / Postgres                       |\n| Spine Cache    | hot projections and hydration acceleration | KV                                  |\n| Memory Fabric  | Memory metadata and lifecycle              | D1 + KV + Vectorize                 |\n| Knowledge      | semantic retrieval representations         | D1 metadata + R2 source + Vectorize |\n| Twin Runtime   | session coordination and active runtime    | Durable Object                      |\n| Blobs          | large immutable or versioned artifacts     | R2                                  |\n| Sync State     | convergence progress                       | D1 + queues                         |\n\n#### 27.2 Laws\n\n1. Every byte has an owner.\n2. Every store has a purpose.\n3. D1 owns structured state and metadata for v0.\n4. KV owns reconstructable hot projections and caches.\n5. R2 owns bytes, raw artifacts, large payloads, and evidence objects.\n6. Vectorize owns semantic retrieval vectors, not source truth.\n7. Embeddings are versioned derived representations and may always be rebuilt.\n8. D1 owns the meaning and references of blobs and vectors; R2 and Vectorize own their physical representations.\n9. Product logic talks to stable repository contracts, never directly to D1, KV, R2, or Vectorize.\n10. No product plane depends on a provider primitive.\n\n#### 27.3 Swappable Provider Architecture\n\nIntegrateWise defines capability contracts.\n\nThe Configuration Manager resolves configured implementations.\n\nProviders execute through adapters.\n\nNo external provider owns an IntegrateWise architectural boundary.\n\nDeployment configuration selects infrastructure.\n\nApplication architecture does not.\n\nProduct code must never import a provider SDK directly.\n\n---\n\n### 28. Memory Fabric\n\n#### 28.1 Memory Scopes\n\n- User Memory\n- Work Memory\n- Organization Memory\n- Twin Memory\n\nTwin Memory is a memory scope, not the entire Twin runtime.\n\nTwin Memory, Session Logs, Audit Logs, and Spine state remain separate.\n\n#### 28.2 Memory Record\n\nEach memory record contains:\n\n- memoryId\n- tenantId\n- scope\n- ownerRef\n- subjectRefs\n- memoryType\n- content\n- provenance\n- evidenceRefs\n- embeddingRef\n- blobRefs\n- confidence\n- createdAt\n- updatedAt\n- expiresAt\n\n#### 28.3 Physical substrate\n\n- D1 owns memory metadata and lifecycle.\n- KV owns hot memory projections.\n- Vectorize owns semantic memory retrieval indexes.\n\n---\n\n### 29. Embeddings and Retrieval Fabric\n\nEmbeddings are derived representations.\n\nIf an embedding model changes, re-embed from source truth.\n\nVectorize is a retrieval primitive.\n\nLogical index families:\n\n- memory retrieval\n- knowledge retrieval\n- Spine semantic retrieval\n- session semantic retrieval\n\nDo not dump everything into one vector index.\n\nSimilarity score semantics differ by domain.\n\n---\n\n### 30. Unified Governance\n\n#### 30.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- AUTO_APPROVE\n- REQUIRE_HUMAN_APPROVAL\n- DENY\n\nGovernance is a cross-phase authority boundary.\n\nIt is not an Act-phase service.\n\n#### 30.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---\n\n### 31. Execution Model\n\n#### 31.1 ExecutionPlan\n\n**Approve Twin's Action approves an ExecutionPlan, not an AI message.**\n\nExecutionPlan describes:\n\n- planId\n- tenantId\n- proposalId\n- planVersion\n- summary\n- impactSummary\n- steps\n- affectedEntities\n- affectedSystems\n- authority\n- evidence\n- executionMode\n- syncMode\n- rollbackStrategy\n- compensationPlan\n- status\n- createdAt\n- createdBy\n- expiresAt\n\nThe user sees the execution plan before approval.\n\n#### 31.2 Execution 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\nExecution mode and synchronization mode are independent.\n\n#### 31.3 Hermes Scope\n\nHermes is the execution coordinator.\n\nHermes:\n\n1. RECEIVE the ExecutionPlan\n2. RESOLVE runtime binding\n3. VALIDATE schema and permissions\n4. ROUTE to runtime adapter\n5. DISPATCH execution\n6. TRACK correlation, state, and timeouts\n7. REPORT telemetry and outcome events\n\nHermes does not:\n\n- assemble continuity context;\n- make governance decisions;\n- write to Spine;\n- reconcile provider systems;\n- select AI models.\n\nCapability Fabric resolves intent.\n\nGovernance authorizes.\n\nPlan Builder plans.\n\nHermes coordinates.\n\nRuntime adapter executes.\n\nSync reconciles.\n\nPipeline promotes.\n\n---\n\n### 32. Sync Engine\n\n#### 32.1 Convergence Modes\n\n- Immediate\n- Deferred\n- Scheduled\n- Batch\n- Event-Driven\n- Reconciliation\n\n#### 32.2 State\n\nCursors, checkpoints, pending mutations, retries, dead-letter state, conflict state, reconciliation state.\n\n#### 32.3 Canonical law\n\nWork now. Converge by policy.\n\n---\n\n### 33. Continuity Pipeline\n\nEvery governed execution produces an OutcomeEvent.\n\nThe pipeline evaluates:\n\n- intent,\n- action,\n- evidence,\n- authority,\n- outcome,\n- state,\n- memory.\n\nApproved operational truth is promoted back into the Adaptive Spine.\n\nTwin Memory is updated according to memory policy.\n\nSession history remains in Session Logs.\n\nAI accountability remains in Audit Logs.\n\nFiles and evidence remain in Blob storage.\n\nSemantic representations are updated in Knowledge.\n\nCaches are invalidated or refreshed.\n\nSync state is advanced.\n\n---\n\n### 34. Canonical Contract Chain\n\n```\nCompiledTenantConfig\n        ↓\nConnectionContract\n        ↓\nActivationManifest\n        ↓\nLoadPlan\n        ↓\nCanonicalEntity / CanonicalField\n        ↓\nSpineContext\n        ↓\nWorkbenchComposition\n        ↓\nContinuityBundle\n        ↓\nTwinProposal\n        ↓\nCapabilityInvocation\n        ↓\nPreProposalDecision\n        ↓\nExecutionPlan\n        ↓\nPostProposalDecision\n        ↓\nApprovalRecord\n        ↓\nOutcomeEvent\n        ↓\nSyncMutation\n        ↓\nPromotionDecision\n        ↓\nCanonical Spine State\n```\n\nEach arrow is a transformation with ownership.\n\nContext proliferation is avoided.\n\n**Three canonical context contracts**:\n\n- SpineContext\n- WorkbenchComposition\n- ContinuityBundle\n\nEntity360 is a projection inside SpineContext.\n\nAssembledContext is replaced by ContinuityBundle.\n\nActive Context Bundle is the product-language name for ContinuityBundle.\n\n---\n\n### 35. State Ownership Canonical Law\n\nAdaptive Spine owns canonical operational truth.\n\nNo model owns canonical truth.\n\nNo agent writes directly to the Spine.\n\nChanges reach canonical state through governed promotion.\n\nTwin Memory owns durable AI/user continuity.\n\nSession Logs own interaction history.\n\nAudit Logs own accountability and execution lineage.\n\nBlobs own binary and raw artifacts.\n\nSpine Cache owns disposable derived acceleration state.\n\nKnowledge owns retrievable semantic representations.\n\nSync State owns convergence progress.\n\nConfig State owns tenant runtime choices.\n\nEphemeral Runtime owns temporary coordination state.\n\n---\n\n### 36. Canonical Acceptance Criteria\n\nA proposed architecture, service, data model, or UI interaction is canonical only if it satisfies all of the following:\n\n- It preserves Workbench-first composition.\n- It preserves the four-button interaction grammar.\n- It preserves four distinct connection paths.\n- It separates Activation Bridge from Continuity Bridge.\n- It defines Creamy, Delta, and Streaming Load correctly.\n- It preserves Spine Networking as governed context topology, not an ESB.\n- It preserves state ownership boundaries.\n- It preserves two-gate Governance.\n- It preserves ExecutionPlan as the approval target.\n- It preserves Hermes as execution coordinator only.\n- It preserves promotion as capability-aware and governance-aware.\n- It preserves swappable provider architecture.\n- It does not conflate OODA with deployment topology.\n- It does not collapse API Connector, MCP, AI Connector, or API Wrapper into one generic integration path.\n- It does not claim the Twin operates autonomously without context or approval.\n\n---\n\n### 37. Final Canonical Statement\n\nIntegrateWise gives every department one connected operational Workbench.\n\nEvery user works with a persistent Twin that understands operational continuity.\n\nAI can propose and coordinate work, but enterprise truth and execution authority remain governed.\n\n**Truth you own. AI you rent. Approval in between.**\n"}