{"slug":"platform/_doctrine-and-sales-narrative","title":" Doctrine And Sales Narrative","section":"platform","sectionLabel":"Platform","status":"unclassified","type":"document","path":"platform/_doctrine-and-sales-narrative.mdx","bytes":93407,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"> **EXTRACTED / NOT CANONICAL.** This narrative is preserved as source material.\n> Its old product naming, Descope authority, storage and UI-layer claims must not\n> override [`../architecture/ARCHITECTURE_LOCK.md`](../architecture/ARCHITECTURE_LOCK.md).\n\nIntegrateWise\nThe Operational Continuity Platform\nCanonical Doctrine, Architecture, and Sales Narrative — Final v2\n⁠\nThe One Immutable Rule\nEverything outside the Business Platforms is replaceable.\n​Everything inside the Business Platforms is versioned and contract-driven.\nThis sentence governs the entire system. It governs the product, the architecture, the company, and every decision that follows. If a new idea violates this rule, the idea is wrong. If a new tool violates this rule, the tool is replaced. If a new document violates this rule, the document is superseded.\nEverything below this line is an expression of this rule.\n⁠\nPart I — The World That Broke\n⁠\nThe promise that was never kept\nSoftware was supposed to make work easier. Instead it made work fragmented.\nEvery tool you connect to — your CRM, your chat, your project tracker, your AI assistant — starts from zero. None of them know what the others know. Your context dies the moment you switch tabs. Your memory resets every time you open a new AI conversation. Your data is locked inside someone else’s schema, someone else’s platform, someone else’s business model.\nSo you do what every knowledge worker does today. You become the integration. You copy context from Salesforce into Slack. You re-brief your AI assistant from scratch every morning. You build the same understanding in three different tools because none of them share it. You spend your day not doing your job — you spend it being the human API between systems that should already know each other.\nThis is not a tooling problem. It is an architecture problem. And IntegrateWise solves it.\n⁠\nThree frustrations, one root cause\n“I say the same thing to every AI again.”\nNo shared memory exists. Each AI starts blank. You spend your time re-briefing instead of building on what was already established. Every morning is Groundhog Day for your context.\n“My context gets lost when I switch tools.”\nContext is trapped inside each tool. Your CRM knows one thing. Your project tracker knows another. Your support desk knows a third. Nothing connects them. The understanding you need lives in the gaps between your tools, not in any one of them.\n“I can’t move my data — I’m locked in.”\nThe data lives inside the platform, not with you. The moment you leave, your context vanishes. Every tool you adopt makes it harder to leave, not because the tool is good, but because your context is trapped inside it.\nThe root cause is the same every time: there is no shared memory layer. Tools connect to each other through point-to-point integrations or through you — the human doing the work of a bridge by hand.\n⁠\nWhat the industry is doing wrong\nThe current market solves the wrong problem at every level.\nAutomation players (Zapier, Make, n8n) connect apps. They move data from one place to another through triggers and automations. That is plumbing. It is useful, but it does not preserve context across time. A Zap passes a record; it does not remember why the record matters, what happened before it arrived, or what should happen next.\nEnterprise integration players (Workato, Tray, MuleSoft, Boomi) go deeper. They orchestrate workflows across enterprise systems. But the intelligence is still in the workflow definition, not in the data. Change the workflow, lose the reasoning.\nAI search players (Glean, Dashworks) index everything and let you ask questions. But they are readers, not actors. They can tell you what happened; they cannot propose what to do about it and wait for your approval.\nWorkspace players (Notion, Coda, Linear) give you a surface to work on. But the surface is disconnected from your operational tools. You still have to bring the context in by hand.\nAI chat players (ChatGPT, Claude, Copilot) give you intelligence. But each conversation starts from zero. There is no persistent memory, no organizational context, no governance layer between the AI and your operations.\nConnector platforms (Replit, Vercel) give you infrastructure to build and deploy. But they connect tools to code, not context to decisions. The developer is still the integration layer.\nEvery category solves a piece. None of them owns the layer between. The layer that carries context across tools, across time, across people, across AI providers. The layer that makes work continuous instead of fragmented.\nThat layer is IntegrateWise.\n⁠\nPart II — The Shift\n⁠\nThe category that did not exist\nThe category is not automation. It is not AI search. It is not workspace. It is not integration. It is not a platform you build on.\nThe category is operational continuity — the infrastructure that preserves identity, context, memory, governance, and execution across every consumer in your organization.\nIntegrateWise does not replace your tools. It does not replace your AI. It sits beneath all of them and makes them share the same truth.\nThey connect apps. IntegrateWise connects context.\n⁠\nThe human shift\n⁠\n⁠\nPart III — The Doctrine\n⁠\nThree sentences that govern everything\nTruth you own.\nThe data in your workspace — your entities, your relationships, your history — belongs to your organization. It lives in the Spine. You can see it, manage it, export it. No tool locks it away. No provider owns it. The context stays with you forever.\nAI you rent.\nThe reasoning layer — the model that reads your context and proposes actions — is replaceable by design. Today it might be GPT. Tomorrow it might be Claude, Gemini, Grok, or a model that does not exist yet. You swap models by configuration, not by migration. The AI serves your context; your context never serves the AI.\nApproval in between.\nEvery action the AI proposes passes through a governance gate before it touches anything real. High-confidence actions auto-execute with a full audit trail. Medium-confidence actions surface on your desk for review. Low-confidence actions are discarded. You are always in control. The AI does not drift. It does not hallucinate into execution. It proposes within your boundaries and waits.\nTruth you own. AI you rent. Approval in between.\n⁠\nThe architecture doctrine\nBuild capabilities once. Experience them anywhere. Deploy them anywhere.\nCapabilities are the reusable business contract. Experiences are the user-facing projections. Deployment Profiles are the runtime implementations. Everything else — models, clouds, databases, frameworks — is just an implementation choice behind those contracts.\n⁠\nThe product doctrine\nIntegrateWise has two user journeys — one to establish continuity, and one to operate with continuity. The first optimizes time-to-first-value. The second optimizes continuous operational value. They share one Continuity Platform that compounds every day.\n⁠\nThe capability doctrine\nCapabilities are resolved inside the Orient phase of the OODA loop. Users never select capabilities manually. The Twin resolves the right Platform Capability based on context. The user sees proposals, not menus.\n⁠\nThe three scopes of doctrine\n⁠\nThe single sentence that unifies all three:\nYou own the truth (Spine) over which any AI you rent (Twin) reasons — and every execution must pass through an approval token before it touches the outside world (Governance Gate).\n⁠\nPart IV — The Product\n⁠\nIntegrateWise\nIntegrateWise is the Operational Continuity Platform — the infrastructure layer that preserves context, memory, and governance across every tool, every person, and every AI in your organization.\nIt is one platform. Not a connector marketplace. Not an automation engine. Not another AI chatbot with a plugin directory. It is the governed middle that sits beneath all your tools and all your AI providers, carrying context forward so nothing is forgotten and nothing executes without your approval.\nThe product promise: nothing important is forgotten.\nYou brief it once. It remembers everything. Every platform you use — every AI, every tool, every assistant — gets the same truth without you having to repeat yourself.\n⁠\nWhat customers buy — five promises\nOne Human Worksurface\nYour workbench. One place where you see everything that matters — your customers, your deals, your tasks, your signals, your metrics — without switching tabs or re-querying tools. The workbench adapts to you: your role, your department, your industry, your connected tools. No two workbenches look the same, because no two people have the same context.\nAI Home — Your Digital Twin\nThe Twin is not a chatbot you open when you have a question. It is a persistent reasoning engine that is always working, always grounded in your Spine, always governed by your approval rules. It observes. It proposes. It waits for your signal. It learns from every outcome. It lives in its own home within the platform — reasoning over your context, surfacing insights, proposing actions — while you work uninterrupted.\nShared Continuity\nOne Spine. One memory. Every tool reads from it, writes to it, and benefits from what the others contributed. The context compounds. Each day your workspace knows more than the day before. Memory does not reset when you switch tools, switch AI providers, or switch devices. It stays.\nConnected Ecosystem\nConnect once. Your Spine hydrates. Memory starts flowing. Adding a third tool is an enable toggle, not a project. The platform supports every major connector through MCP-first ingestion with **Descope as the canonical authorization authority** for outbound connections; Nango remains only as dormant compatibility for providers Descope outbound does not yet support. Your tools talk to each other through the platform — you never become the bridge between them.\nGoverned Intelligence\nEvery AI action passes through a governance gate. Confidence-scored proposals. Human-in-the-loop approval for medium-risk actions. Auto-execute for high-confidence actions with full audit trail. Discard for low-confidence noise. The governance layer never opens. Even the platform operator cannot bypass it.\n⁠\nSolutions — what customers actually use\nEach solution is a projection of the same underlying Spine. The data does not change; the perspective does.\n⁠\n⁠\nThe Human Worksurface — without context switching\nThe workbench is not another dashboard. It is the surface where your work actually happens.\nView. Obtain. Execute. Not just a list of data. A place where you can see your leads, qualify them, move them through stages, and convert them — with context and knowledge flowing from every connected tool and from the Twin’s reasoning.\nNo context switching. Your CRM data, your support signals, your communication history, your task status, your AI proposals — all on one surface. You never leave to go find something in another tool. It comes to you.\nYour surface, shaped by you. Identity, role, department, industry, connected tools — all shape the projection. The surface adapts to how you work, not the other way around.\nHuman stops being the API. The old pattern: open Salesforce, copy the context, paste it into Slack, re-explain it to the AI, check the project tracker, update the spreadsheet. The new pattern: everything is already on your surface. The tools talk to each other through the Spine. You do the work, not the integration.\n⁠\nPart V — The Architecture\n⁠\nThe final hierarchy\nVISION\nOperational Continuity\n│\n▼\nPRODUCT\nIntegrateWise\n│\n▼\nSOLUTIONS\nSales · CS · Ops · Executive · Knowledge\n│\n▼\nEXPERIENCES\nWeb · Desktop · Mobile · CLI · Slack · Teams · Partner · Embedded\n│\n▼\nBUSINESS PLATFORMS\nIdentity · Connectivity · Integration Manager · Continuity · Capability Fabric · Governance\n│\n▼\nEXECUTION PLATFORMS\nIntelligence · Runtime · Storage · Search · Messaging · Deployment · Observability\n│\n▼\nDEPLOYMENT PROFILES\nCloudflare Native · Vercel Native · Replit Native · Docker Native · Kubernetes Native · AWS Native · Azure Native\n│\n▼\nTECHNOLOGY\nWorkers · D1 · Postgres · Redis · S3 · Queues · Vector DBs · etc.\nSeven layers. Each independent. Each replaceable below the Business Platforms. The layers above change slowly (vision, product, solutions). The layers below change freely (execution, deployment, technology). The Business Platforms are the stable contract in the middle — versioned, backward-compatible, and never bypassed.\n⁠\nThree kinds of platforms\nThe architecture recognizes three distinct kinds of platforms. They serve different audiences and change at different speeds.\nBusiness Platforms — your IP\nThese are what customers buy. They are stable, versioned, and contract-driven. They do not change.\n⁠\nExecution Platforms — replaceable\nThese are how the system runs. They can change freely without changing the product.\n⁠\nExperience Platforms — unlimited\nThese are where people work. Any surface that can call Projection APIs over a Gateway JWT is a valid experience.\n⁠\nEach experience consumes only the capabilities it needs. A Slack app needs approvals and signals, not the full workbench. A desktop app needs the complete experience. Both call the same Projection APIs. Both see the same Spine.\n⁠\nCapability Fabric — the center of everything\nEverything orbits capabilities.\nExperiences\n│\n▼\nCapability Fabric\n┌──────────┼──────────┐\n▼ ▼ ▼\nContinuity Intelligence Governance\n│ │ │\n└─── Integration Manager ───┘\n│\nConnectivity\n│\nIdentity\nCapabilities are the language of the platform.\nFrontends consume capabilities.\nAI reasons over capabilities.\nGovernance protects capabilities.\nContinuity stores capability state.\nIntegration Manager hydrates capabilities.\nNo surface ever talks to raw tools.\nNo AI ever holds raw credentials.\nNo connector ever writes directly to the Spine.\nThree capability types\n⁠\nThe critical distinction: Provider Capabilities are resolved at activation. Platform Capabilities are resolved at runtime by the Twin during the Orient phase of OODA. Experience Capabilities are resolved by the surface based on device and context. The user never manually selects any of them.\n⁠\nDeployment Profiles\nDeployment is not infrastructure. Deployment is a product choice.\nEach Deployment Profile implements the same platform contracts:\n⁠\nThe profiles\nCloudflare Native — Workers · D1 · KV · R2 · Durable Objects · Queues · Vectorize · Workers AI\nVercel Native — Functions · Edge Functions · Postgres · Blob · KV · AI SDK\nReplit Native — Replit Deployments · PostgreSQL · Object Storage · Secrets · Always On\nDocker / Kubernetes Native — Containers · PostgreSQL · Redis · MinIO · NATS\nAWS Native — Lambda · RDS · S3 · SQS · Bedrock · CloudWatch\nAzure Native — Functions · Cosmos DB · Blob · Service Bus · Azure AI\nOn-Prem Native — Customer Infrastructure · PostgreSQL · Redis · MinIO · NATS\nEach is a first-class deployment profile, not a port or secondary target. They all implement the same platform contracts, so the customer chooses the deployment environment without changing the product.\nIntegrateWise is not built on Cloudflare, Vercel, or Replit. It runs natively on any of them.\nDeployment Profile → Infrastructure Provider → Technology\nDeployment Profile Infrastructure Provider Technology\n───────────────── ─────────────────────── ──────────\nReplit Native Replit Platform Postgres · Object Storage · Secrets\nCloudflare Native Cloudflare Platform Workers · D1 · KV · R2 · DOs · Queues\nVercel Native Vercel Platform Functions · Postgres · Blob · AI SDK\nDocker Native Container Runtime PostgreSQL · Redis · MinIO · NATS\n⁠\nTwo doors, one Spine\nThe architecture has exactly two external boundaries, with the Spine between them.\nNorth Plane — The API Gateway. Every consumer enters here. AI assistants over inbound MCP. Experiences over capability calls. External agents over the public API. The Gateway authenticates, resolves the tenant, routes to the right capability, and enforces rate limits.\nSouth Plane — The Integration Router. Every outbound action exits here. The Router picks the right adapter, injects context, manages credentials, and monitors health.\nNeither plane talks to the other except through the Spine. That is the invariant that makes everything else work: tenant isolation, governance enforcement, audit completeness, and storage swappability all depend on it.\n⁠\nPart VI — The Three Planes\n⁠\nThe principle\nIntegrateWise is not one experience. It is three planes that a user moves through at different speeds, with different levels of visibility into the platform’s internals.\nEXPERIENCE PLANE CONTINUITY PLANE EXECUTION PLANE\n(What users see) (What we build) (How work happens)\n\nMarketplace Capability Discovery Human Worksurface\nDiscovery Identity Binding Digital Twin\nInstall Initial Hydration Governance\nConnect Once Memory Formation OODA Loop\nHuman Worksurface Relationship Binding Continuous Learning\nContext Assembly\nSpine\n\nGTM surface. The moat. Daily work.\nUsers enter here. Nobody sees this. Users live here.\n⁠\nExperience Plane — what users see\nThe user is not yet a customer. They are browsing, evaluating, clicking. This is the GTM surface.\nThe journey:\nAI Marketplace (ChatGPT, Claude, Perplexity, Gemini)\n↓\nInstall\n↓\nAuthenticate Workspace\n↓\nConnect Once\n↓\nHuman Worksurface Opens\nThe user’s psychology: “What is this? Does it do what I need? Is it worth trying?”\nThe success metric: Install and authenticate. That is the only conversion that matters at this plane.\nWhat the user sees: One listing. One promise. One click. The listing explains the value in outcomes, not architecture.\nWhat the user does NOT see: Connectors. Capabilities. MCP. Normalization. Spine. Any architectural concept.\n⁠\nContinuity Plane — what IntegrateWise builds\nThis is the moat. Nobody sees it. But this is what differentiates IntegrateWise from every other product in the market.\nThe journey — “Continuity Activation”:\nConnect Once\n↓\nCapability Discovery\n(What can Salesforce do? What can Slack do?\nNot data selection. Capability surfacing.)\n↓\nIdentity Binding\n(Who is this user? What tenant? What role?\nWhat department? What industry?)\n↓\nBootstrap Hydration\n(Latest 30 days. Selected entities.\nEnough to prove value. Minutes, not hours.)\n↓\nContinuity Ready\n(Spine has enough context to be useful.\nWorkbench opens.)\n↓\nBackground Enrichment\n(Full historical sync.\nEntity resolution across tools.\nMemory extraction.\nKnowledge graph building.\nRelationship mapping.\nSignal generation.\nRuns quietly while the user works.)\n↓\nContinuous OODA\n(Never stops.\nEvery observation enriches the Spine.\nEvery action writes back.\nEvery cycle makes the next richer.)\nThe three hydration phases:\n⁠\nKey principle: The workbench opens before everything is synchronized. The user gets value from partial hydration. Background enrichment runs while they work. The user never waits.\nThe Integration Manager owns activation. Not Connectivity. The Integration Manager handles the full activation flow and then, after activation, becomes mostly invisible — streaming changes forever through the Connectivity Platform.\n⁠\nExecution Plane — how work happens\nThis is daily work. This is OODA. This is where the user lives 95% of the time.\nThe user’s daily loop:\nOpen workbench\n↓\nSee what matters\n(Signals, insights, risks, opportunities — surfaced by the Twin)\n↓\nReview Twin proposals\n(On My Desk. Confidence-scored. With evidence.)\n↓\nApprove or modify\n(One click. The governance gate.)\n↓\nContinue working\n(The approved action executes through the Integration Router.)\n↓\nContext updates\n(Writeback to Spine. Next observation is richer.)\n↓\nClose workbench\n(Twin continues working in the background.)\nThe user’s psychology: “I have work to do. Show me what matters. Let me act on it.”\nThe success metric: The user completes their core workflow without switching to another tool. Time-to-answer for key questions decreases over time as memory compounds.\nWhat the user does NOT experience: Capability selection. Connector management. MCP protocol. Normalization pipeline. Entity resolution. Memory classification. Any architectural concept.\nThe user thinks about their work — their customers, their deals, their signals, their decisions. The platform thinks about everything else.\n⁠\nPart VII — The Two Products\n⁠\nTwo products, one Continuity Platform\n┌─────────────────────────────────────────────────────────┐\n│ │\n│ ONE CONTINUITY PLATFORM │\n│ │\n│ Spine · Memory · Entity Resolution · Governance │\n│ │\n├────────────────────────┬────────────────────────────────┤\n│ │ │\n│ ACTIVATION PRODUCT │ OPERATIONAL PRODUCT │\n│ │ │\n│ KPI: │ KPI: │\n│ Time-to-first-value │ Daily active value │\n│ │ │\n│ Marketplace │ Human Worksurface │\n│ Discovery │ Digital Twin │\n│ Connect Once │ Governance │\n│ Capability Disc. │ OODA Loop │\n│ Bootstrap Hydration │ Continuous Learning │\n│ │ │\n│ Minutes │ Forever │\n│ Disposable │ Permanent │\n│ Fast, simple, clear │ Deep, compounding, growing │\n│ │ │\n└────────────────────────┴────────────────────────────────┘\nThe Activation Product is designed to be consumed and discarded. Its job is to get the user from “what is this?” to “my workspace is ready” as fast as possible. Once the Continuity Platform is activated, the Activation Product’s job is done. The user transitions to the Operational Product and never sees the Activation flow again — unless they add a new connector.\nThe Operational Product is designed to be the permanent surface. Its job is to deliver daily value through the OODA loop while the Continuity Platform compounds in the background. The longer the user works, the richer the platform becomes. It gets better every day, not because the code changes, but because the context deepens.\nThey share one Continuity Platform. The Spine, Memory, Entity Resolution, and Governance serve both products. The Activation Product writes the first entities into the Spine. The Operational Product reads from and writes back to the same Spine. Context accumulated during activation enriches daily work. Context accumulated during daily work makes future activations faster and richer.\n⁠\nPart VIII — OODA as Architectural Law\n⁠\nThe original OODA loop\nColonel John Boyd developed the OODA loop to explain why some pilots consistently won dogfights. It was not about faster aircraft. It was about faster decisions.\nOBSERVE → ORIENT → DECIDE → ACT\n↑ │\n└───────────────────┘\nObserve — Gather data from the environment.\nOrient — Analyze and synthesize against prior knowledge. Boyd called this the schwerpunkt — the center of gravity of the entire loop. Everything flows through Orientation.\nDecide — Select a course of action.\nAct — Execute. Then observe the result. The loop tightens.\nBoyd’s core thesis: the side that cycles through OODA faster — and orients more accurately — wins. Not the side with more data. Not the side with more firepower. The side that understands faster and acts on that understanding before the opponent can react.\n⁠\nWhy Orientation is everything\nBoyd placed disproportionate weight on Orientation. Two pilots can observe the same radar blip. One sees a threat. The other sees a decoy. The difference is not in the observation. It is in the orientation — the accumulated context, pattern recognition, and prior experience that shapes interpretation.\n⁠\nThe Spine IS the Orientation engine. Without the Spine, every observation is raw data. With the Spine, every observation is understood in context. This is why IntegrateWise exists — the platform does not automate decisions; it makes orientation so fast and so rich that the decision becomes obvious.\n⁠\nIntegrateWise as the extended OODA loop\n┌─────────────────────────────────────────────────────────────────┐\n│ │\n│ INTEGRATEWISE │\n│ Extended OODA Loop │\n│ │\n│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │\n│ │ OBSERVE │───▶│ ORIENT │───▶│ PROPOSE │───▶│ GOVERN │ │\n│ │ │ │ │ │ │ │ │ │\n│ │Connectors│ │ Spine │ │ Twin │ │ L7 Gate │ │\n│ │MCP Inbound│ │Entity360 │ │Confidence│ │ Approval │ │\n│ │Webhooks │ │ Memory │ │ Evidence │ │ Token │ │\n│ │Signals │ │ Context │ │ Action │ │ Audit │ │\n│ └──────────┘ │Assembly │ └──────────┘ └────┬─────┘ │\n│ ▲ └──────────┘ │ │\n│ │ ▼ │\n│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │\n│ │ │ LEARN │◀───│ ORGANIZE │◀───│ EXECUTE │ │\n│ │ │ │ │ │ │ │ │\n│ │ │ Continuity│ │ Scoping │ │Integration│ │\n│ │ │ Engine │ │ Classify │ │ Router │ │\n│ │ │ Decay │ │ Relate │ │ Outbound │ │\n│ └──────────│ Compound │ └──────────┘ │ Writeback│ │\n│ └──────────┘ └──────────┘ │\n│ │\n│ Orientation is the center. The Spine makes it rich. │\n│ Governance is the gate. No action without approval. │\n│ Memory compounds. Each cycle makes the next faster. │\n│ │\n└─────────────────────────────────────────────────────────────────┘\nObserve — Connectors and Signals\n⁠\nThe Connectivity Platform receives data through the Integration Manager. Every signal is stamped with provenance. The connector does not reason — it only observes.\nOrient — The Spine and Context Assembly\n⁠\nThe Normalizer transforms raw data into canonical entities. The Spine binds them to stable IDs. Context Assembly builds the full picture. Capabilities are resolved here — the Twin determines which Platform Capabilities are needed based on the oriented context. The user never sees this resolution.\nThis is the step that matters most. Two platforms can observe the same Salesforce webhook. Only IntegrateWise can orient it against the full context of every prior interaction, every relationship, every learned pattern, every governance rule.\nPropose — The Twin\nThe Twin reads the oriented context — Entity360, timeline, memory, signals — and proposes an action. Not a raw output. A structured proposal with evidence, confidence, and a recommended course.\nGovern — The Gate\n≥ 0.85 confidence: Auto-approve. Execute. Audit.\n0.70–0.85: Surface on My Desk. Human reviews.\n< 0.70: Discard. Log for learning.\nThis is IntegrateWise’s extension to OODA. Boyd assumed the decision-maker was also the actor. IntegrateWise assumes the AI proposes and the human governs. The gate is non-negotiable.\nExecute — The Integration Router\nAn approved action routes through the South Plane to the target tool. Entity360 context is injected before the call. No action touches the outside world without an approval token.\nWriteback, Remember, Organize, Learn — The Extensions\nThese steps do not exist in Boyd’s original OODA. They are IntegrateWise’s critical addition.\nEvery outcome writes back to the Spine. The Continuity Engine extracts knowledge with confidence scores. Memory is classified into scopes (Personal, Work, Organization, AI). Relationships are updated. The next Orientation is richer. The loop tightens. The platform gets smarter the longer you use it — not because the model changes, but because the orientation improves.\n⁠\nOODA depth over time\nACTIVATION OPERATIONAL\n(first session) (every session)\n\nObserve: First connector data Observe: Continuous stream from all connectors\nOrient: Bootstrap context Orient: Full Spine + Memory + Relationships\nDecide: First Twin insight Decide: Deep proposals with evidence chains\nGovern: User reviews first proposal Govern: Confidence-gated approval at scale\nAct: First action executes Act: Thousands of actions over time\nLearn: First writeback Learn: Memory compounds indefinitely\n\nCONTEXT DEPTH:\n█░░░░░░░░░░░░░░░░░░░░ → ████████████████████████\n(30 days, one tool) (years, every tool, every user)\n⁠\nCompetitive frame through OODA\n⁠\nIntegrateWise is the only platform that runs the complete extended OODA loop across every tool, every AI, and every person in the organization.\n⁠\nPart IX — Go to Market\n⁠\nDistribution — AI-assistant-first\nIntegrateWise ships as an MCP app listed in the marketplaces of the AI assistants people already use. ChatGPT’s app store. Claude’s connector directory. Perplexity. Users discover and add it from inside the assistant they already work with.\nThe primary ingress channel is the primary distribution channel. List once as an MCP app. That listing is both how users find IntegrateWise and how their assistant reaches the Spine.\n⁠\nThe user lifecycle\nDISCOVER → ACTIVATE → CONTINUE → GROW\n⁠\n⁠\nThree sales motions\nDirect — Individuals and small teams\nLand on the native web experience. Establish your workspace. Connect your tools. Start working. The Twin begins reasoning from day one.\nEmbedded — Enterprise with existing portals\nYou already have an internal dashboard. IntegrateWise deploys into your environment. Your users authenticate through your existing identity provider. The Business Platforms run invisibly under your brand. Their surface, our brain.\nPlatform — Channel and white-label\nYou are a dev platform, an IDE, or a low-code environment. IntegrateWise becomes the intelligence and memory layer inside your product. Your users get governed AI and persistent context without knowing IntegrateWise exists.\n⁠\nCustomer Zero — the proof\nThe first real deployment runs on two connectors: Salesforce + Slack. Read-only. Approval-required. 90-day retention.\nOne workspace authentication. The CS experience shows cross-system account context in under 60 seconds. The Twin proposes at least one insight per day. The VP of Customer Success answers “what is our risk?” without opening Salesforce or Slack.\nAdding a third tool is an enable toggle, not a project.\n⁠\nPart X — What Makes This Defensible\n⁠\nThe moat is memory gravity\nThe defensibility is not in connector breadth. That is commoditized. The defensibility is not in the AI model. That is rented and replaceable. The defensibility is not in the experience layer. That is replaceable by design.\nThe moat is memory gravity.\nThe more context you store in the Spine, the more valuable the platform becomes to you, and the higher the cost of leaving. Every entity, every relationship, every timeline entry, every learned pattern — all of it makes every future decision better. That compounds. It does not transfer.\nWhen you connect your first tool, the Spine starts building context. When you connect your fifth tool, the context from the first four makes the fifth more valuable. When the Twin has 90 days of reasoning history, switching to a different system means starting from zero. Not because you are locked in by contract — but because your context lives here.\nTruth you own, that compounds in place, that makes every tool and every AI better — that is the moat.\n⁠\nThe seven agnostic dimensions\n⁠\nCompetitors lock you into their runtime, their model, their experience. IntegrateWise locks you into nothing — except the context you have built. And that context is yours.\n⁠\nWhat is replaceable and what is not\n⁠\nEverything outside the Business Platforms is replaceable. Everything inside the Business Platforms is versioned and contract-driven.\n⁠\nPart XI — The Positioning\n⁠\nTagline hierarchy\n⁠\n⁠\nCompetitive frame\n⁠\nThey connect apps. IntegrateWise connects context.\n⁠\nAnti-positioning\nIntegrateWise is not:\n“AI-powered platform” — AI is rented, not the product\n“No-code automation” — the platform is capability-driven, not workflow-driven\n“Replace your tools” — tools stay; the platform connects them\n“Chat with your data” — the Twin proposes and governs; it does not just answer\nThe correct frame: Human workbench. Assistive AI. Governed context.\n⁠\nPart XII — How the Company Runs\n⁠\nThe principle\nIntegrateWise preaches no lock-in, swappable implementations, and context that stays with you. The company’s own operational stack follows the same philosophy.\nEvery tool the company uses is a replaceable implementation behind a stable business function. The company runs on the same principle as the product.\n⁠\nThe company stack by function\nProduct and infrastructure\n⁠\nBuild and ship\n⁠\nUnderstand and learn\n⁠\nCommunicate and sell\n⁠\nCompany operations\n⁠\n⁠\nThe operational replacement table\n⁠\n⁠\nPart XIII — The Close\n⁠\nWhat exists today\nThe Spine architecture and normalization pipeline\nThe Twin reasoning engine with confidence-gated governance\nThe MCP surface for AI-assistant-first ingress\nDescope as the canonical authorization authority for outbound connections (Nango retained as dormant compatibility)\nThe multi-experience architecture (web, embedded, platform)\nThe identity projection system (12 departments, 6+ industries, 4 role buckets)\nThe Discovery contract and capability registry\nNative deployment on Cloudflare, with Vercel and Replit as first-class deployment profiles\nCustomer Zero proof framework (Salesforce + Slack, CS experience)\n\nLaunch narrative (frozen)\n\nCampaign thesis: **Your Last Auth. Total Continuity.**\nProduct mechanism: **One Click to Total Ecosystem.**\nCategory: **Operational Continuity Infrastructure** (not \"Operating System for Enterprise Context\").\nCore enemy: **Starting from zero** — AUTH AGAIN · CONNECT AGAIN · EXPLAIN AGAIN · SEARCH AGAIN · RECONSTRUCT AGAIN · START AGAIN. Not Salesforce, not Slack, not integrations, not stateless AI.\nCore problem: **The Empty Context Tax.**\nProduct promise: **The next piece of work starts where the last one ended.**\nAI difference: **Your AI starts in context.**\nGovernance law: **Twin prepares. Human approves.**\nOwnership doctrine: **Truth you own. AI you rent. Approval in between.**\nPrimary CTA: **Connect Your Ecosystem.**\nIntegrateWise is the continuity layer between your tools, your people, and the AI working with them.\nLaunch film spine: \"The Last Auth\" → AUTHORIZE → CONNECT → RETAIN → CONTINUE → ACT → REMEMBER ↺.\n⁠\nWhat is coming\nMCP marketplace listings (ChatGPT, Claude, Perplexity)\nNative Deployment Profiles for Vercel and Replit\nSchema AI for arbitrary payload mapping\nAgent-to-agent orchestration through the Spine\nPlatform partner SDK for white-label deployment\nAdditional solution verticals beyond Customer Zero\n⁠\nThe one-sentence story\nIntegrateWise is the memory and context layer that sits beneath all your tools and all your AI providers — so you brief it once, it remembers everything, and every platform you use gets the same truth without you having to repeat yourself.\n⁠\nThe thirty-second pitch\nEvery knowledge worker spends their day copying context between tools, re-briefing AI assistants, and doing the work that software should be doing for them. IntegrateWise is the Operational Continuity Platform that sits beneath all your tools and all your AI providers, carrying context forward so nothing is forgotten. You own the data. You rent the AI. Every action passes through your approval. One workbench. Full continuity. Zero context loss.\n⁠\nThe founder’s conviction\nThe battle is not Human vs. AI. It is not about which provider wins or which model is best. It is about building the right relationship between humans and AI — one where the human has a surface for their work, the AI has a home where it lives as a governed digital twin, and both share one memory layer controlled by the human.\nEverything must be grounded in human behaviour and goals, not pulled to AI’s ways. If there is a battle for Human over AI, that can never be Human alone or AI alone. It must be Human and AI over one shared memory and intelligence layer — where Humans have their own surface for their work and AI has its own home where it lives the life of a digital twin, governed by human.\n⁠\nThe ask\nIntegrateWise is building the missing layer between tools and AI. The category is operational continuity. The product is real. The architecture is proven. The doctrine is locked.\nEverything outside the Business Platforms is replaceable. Everything inside the Business Platforms is versioned and contract-driven.\nOODA wins dogfights. IntegrateWise runs OODA for your entire business — with the Spine as orientation, the Twin as proposal, the Gate as governance, and memory that makes every cycle faster than the last.\nTruth you own. AI you rent. Approval in between.\nBuild capabilities once. Experience them anywhere. Deploy them anywhere.\nOne workbench. Full continuity. Zero context loss.\nThat is IntegrateWise.\n⁠\nIntegrateWise — The Operational Continuity Platform\nBuild capabilities once. Experience them anywhere. Deploy them anywhere.\nNothing important is forgotten.\n\nThis fills a gap that has been implicit since the first version of the architecture but never given a name. Every platform needs one place where routing, configuration, and provider selection live. Without it, those decisions scatter across services, get hardcoded in environment variables, or live in someone’s head. None of those survive scale.\n⁠\nThe Integration Hub\nWhat it is\nThe Integration Hub is the Business Platform that owns all routing decisions, configuration state, and provider selection across IntegrateWise. It is the single place where the platform’s behaviour is defined — not through code, but through configuration.\nExperiences\n│\n▼\nCapability Fabric\n┌──────────┼──────────┐\n▼ ▼ ▼\nContinuity Intelligence Governance\n│ │ │\n└─── Integration Manager ───┘\n│\nConnectivity\n│\nIdentity\n│\nIntegration Hub ← THE ROUTING & CONFIG BRAIN\nThe Integration Hub sits beneath all other Business Platforms. It does not own data (that is the Continuity Platform). It does not own identity (that is the Identity Platform). It does not own capabilities (that is the Capability Fabric). It owns how the platform routes, which providers it uses, and what configuration governs each decision.\n⁠\nWhy it is needed\nWithout the Integration Hub, configuration lives in fragments:\n⁠\nEvery one of these decisions should be made once, in one place, and observed by every service that needs them. That place is the Integration Hub.\n⁠\nWhat it governs\nThe Integration Hub owns five categories of configuration:\n\n1. Provider Routing\n   ⁠\n   Example: A low-cost tenant routes triage through Workers AI (cheap, fast) and proposals through GPT-5-mini via OpenRouter (accurate, moderate cost). A premium tenant routes everything through Claude (highest quality). The Hub defines these rules. The services execute them.\n2. Connector Configuration\n   ⁠\n3. Feature Flags and Tiers\n   ⁠\n4. Credential Vault Interface\n   ⁠\n5. Routing Rules and Policies\n   ⁠\n   ⁠\n   Where it sits in the architecture\n   The Integration Hub is a Business Platform — stable, versioned, contract-driven. It does not change freely. Its routing rules and configuration schemas are part of the platform contract.\n   But it also touches the Execution Platforms — because it selects which execution platform handles which task. That is its purpose: it is the bridge between the stable business layer and the replaceable execution layer.\n   BUSINESS PLATFORMS INTEGRATION HUB EXECUTION PLATFORMS\n   ─────────────────── ──────────────── ────────────────────\n\nIdentity Routes identity Intelligence (which model?)\nConnectivity Routes connectors Runtime (which compute?)\nIntegration Manager Routes integrations Storage (which store?)\nContinuity Routes memory Search (which engine?)\nCapability Fabric Routes capabilities Messaging (which queue?)\nGovernance Routes approvals Deployment (which profile?)\nObservability (which tool?)\nThe Integration Hub is the routing brain that connects the stable business layer to the replaceable execution layer. Every Business Platform reads its routing decisions from the Hub. Every Execution Platform is selected by the Hub.\n⁠\nThe Hub as a dashboard\nThe Integration Hub is also the operator’s configuration surface — the place where platform administrators manage the platform’s behaviour without changing code.\n┌─────────────────────────────────────────────────────────────┐\n│ │\n│ INTEGRATION HUB │\n│ Configuration Dashboard │\n│ │\n├─────────────────────────────────────────────────────────────┤\n│ │\n│ PROVIDER ROUTING │\n│ ├─ AI Models gpt-5-mini (default) · Claude · Grok │\n│ ├─ Storage D1 (primary) · Postgres (enterprise) │\n│ ├─ Search Vectorize (default) · Pinecone │\n│ └─ Queues CF Queues (default) · Redis Streams │\n│ │\n│ CONNECTOR CONFIGURATION │\n│ ├─ Salesforce Active · Full Sync · 30min frequency │\n│ ├─ Slack Active · Real-time · Webhook │\n│ ├─ HubSpot Inactive · Not connected │\n│ └─ GitHub Active · Incremental · 15min │\n│ │\n│ FEATURE FLAGS │\n│ ├─ Schema AI Enabled (beta) │\n│ ├─ A2A Orchestration Disabled (Month 6) │\n│ ├─ Twin Voice Enabled │\n│ └─ Auto-approve ≥ 0.85 confidence │\n│ │\n│ CREDENTIALS │\n│ ├─ Nango Wall 4 active connections │\n│ ├─ MCP Keys 2 active keys │\n│ └─ API Keys 3 active (1 expiring soon) │\n│ │\n│ ROUTING RULES │\n│ ├─ Fallback chain OpenRouter → Workers AI → local │\n│ ├─ Cost limit $50/tenant/month (default) │\n│ ├─ Priority Governance > Twin > Triage > Bulk │\n│ └─ Surface access Web: Full · Slack: Approve+Notify │\n│ │\n│ DEPLOYMENT PROFILE │\n│ ├─ Current Cloudflare Native │\n│ ├─ Available Vercel · Replit · Docker │\n│ └─ Override None │\n│ │\n└─────────────────────────────────────────────────────────────┘\nThis dashboard is the operator’s view. It is not the user’s view. The user sees the Human Worksurface and the Governance Gate. The operator sees the Integration Hub — the control plane for the platform itself.\n⁠\nHow it differs from Integration Manager\nThis is a naming question that must be answered cleanly, because “Integration Hub” and “Integration Manager” sound similar.\n⁠\nThe Integration Manager is the hands — it touches external tools.\nThe Integration Hub is the brain — it decides how everything routes.\nThey are complementary. The Integration Manager reads routing decisions from the Integration Hub. The Integration Hub does not touch external tools itself.\n⁠\nUpdated Business Platforms table\n⁠\nSeven Business Platforms. The Integration Hub is the seventh. It does not replace any of the other six. It governs how they route to the Execution Platforms beneath them.\n⁠\nThe updated hierarchy\nVISION\nOperational Continuity\n│\n▼\nPRODUCT\nIntegrateWise\n│\n▼\nSOLUTIONS\nSales · CS · Ops · Executive · Knowledge\n│\n▼\nEXPERIENCES\nWeb · Desktop · Mobile · CLI · Slack · Teams · Partner · Embedded\n│\n▼\nBUSINESS PLATFORMS (7)\nIdentity · Connectivity · Integration Manager · Integration Hub\nContinuity · Capability Fabric · Governance\n│\n▼\nEXECUTION PLATFORMS\nIntelligence · Runtime · Storage · Search · Messaging · Deployment · Observability\n│\n▼\nDEPLOYMENT PROFILES\nCloudflare Native · Vercel Native · Replit Native · Docker Native\nKubernetes Native · AWS Native · Azure Native\n│\n▼\nTECHNOLOGY\nWorkers · D1 · Postgres · Redis · S3 · Queues · Vector DBs · etc.\n⁠\nHow the Hub enables the agnostic doctrine\nThe Integration Hub is the mechanism that makes every agnosticism claim real.\n⁠\nWithout the Hub, “agnostic” is a philosophy. With the Hub, “agnostic” is a configuration.\n⁠\nOne line\nThe Integration Hub is the platform’s control tower — it routes every decision, configures every provider, manages every credential, and governs every feature flag. Without it, agnosticism is a claim. With it, agnosticism is a setting.\n⁠\nWhere this goes in the v2 doctrine\nAdd the Integration Hub to the Business Platforms list in Part V of the final writeup. Add a new section between the current Deployment Profiles section and the Two Doors, One Spine section: “The Integration Hub — Routing and Configuration Backbone.” Include the Hub dashboard, the five configuration categories, and the table distinguishing it from Integration Manager. Update the hierarchy diagram to show seven Business Platforms instead of six.\nThis completes the Business Platform layer. Seven platforms, each with a distinct responsibility, none overlapping:\n⁠\nSeven words. Seven platforms. The full Business Platform layer.\n\nThe Complete System Definition\n⁠\nThe Product in One Line\nOne click to make tools and AI work for humans.\nThat is it. Everything behind that click is architecture. The user never sees the architecture. They see a workspace where their tools are connected, their data is unified, and their AI already knows what to do.\n⁠\nThe Flow — In Plain Language\nSTEP 1: CONNECT\n→ User gives one Auth\n→ Tools connect (API, Connector, MCP, LLM Call)\n→ Integration Manager handles everything\n\nSTEP 2: HYDRATE\n→ Data flows into the Spine\n→ Entities resolved\n→ SSOT built\n→ Workbench ready\n\nSTEP 3: WORK\n→ User works on unified data\n→ One workbench. All tools. One truth.\n→ No tab switching. No context loss.\n\nSTEP 4: AI BECOMES PROACTIVE\n→ Twin watches the same SSOT\n→ Knows context always\n→ Proposes actions before the user asks\n→ Helps with daily tasks\n\nSTEP 5: MEMORY\n→ Human needs knowledge to work\n→ AI needs knowledge to operate\n→ Both live on the Spine\n→ Memory compounds every day\n\nSTEP 6: REPEAT\n→ Every day the system is smarter\n→ Every day the AI knows more\n→ Every day the user works faster\n⁠\nThe Spine — What It Actually Contains\nThe Spine is not just a database. It is the living memory of the organization. It holds three fundamentally different types of data.\nTHE SPINE\n\n┌─────────────────────────────────────────────────────┐\n│ │\n│ LAYER 1: SIMPLE DATA (Structured) │\n│ ───────────────────────────────── │\n│ Fields. Numbers. Dates. Statuses. │\n│ │\n│ Account name: \"Acme Corp\" │\n│ ARR: $1.2M │\n│ Health Score: 62 │\n│ Deal Stage: Negotiation │\n│ Task Status: In Progress │\n│ Contact Email: sarah@acme.com │\n│ Sprint Velocity: 23 points │\n│ │\n│ This is the data that tools already produce. │\n│ It flows in through Integration Manager. │\n│ It lives in structured schemas. │\n│ Postgres. KV. Standard storage. │\n│ │\n├─────────────────────────────────────────────────────┤\n│ │\n│ LAYER 2: RICH DATA (Unstructured) │\n│ ───────────────────────────────── │\n│ Files. Images. Documents. Attachments. │\n│ Conversations. Emails. Meeting recordings. │\n│ │\n│ Contract PDF for Acme Corp │\n│ Slack thread with 47 messages │\n│ Design file for product launch │\n│ Meeting recording from QBR │\n│ Email chain with legal team │\n│ Invoice document │\n│ Screenshot from customer │\n│ │\n│ This is large. This is unstructured. │\n│ It lives in R2 (object storage). │\n│ It is indexed for search. │\n│ It is referenced by entities. │\n│ │\n├─────────────────────────────────────────────────────┤\n│ │\n│ LAYER 3: KNOWLEDGE (Human + AI) │\n│ ───────────────────────────────── │\n│ This is where it gets critical. │\n│ │\n│ HUMAN KNOWLEDGE: │\n│ → Notes the user writes │\n│ → Decisions they document │\n│ → Playbooks they follow │\n│ → Runbooks for incidents │\n│ → Meeting notes │\n│ → Strategic documents │\n│ → Tribal knowledge (\"Acme's CEO hates emails, │\n│ always call\") │\n│ │\n│ AI KNOWLEDGE: │\n│ → Patterns the AI has learned │\n│ → Behavioral models of users │\n│ → Organizational patterns │\n│ → Predictions and their outcomes │\n│ → What worked and what didn't │\n│ → Confidence scores for its own models │\n│ → \"David approves escalations 90% of the time\" │\n│ │\n│ MEMORY TRIAGE: │\n│ → Not all knowledge is permanent │\n│ → The Spine must decide what lives, what ages, │\n│ and what is discarded │\n│ │\n└─────────────────────────────────────────────────────┘\n⁠\nMemory Triage — The Critical Intelligence\nThis is the piece that determines organizational continuity. Without triage, the Spine becomes a dump. With triage, it becomes wisdom.\nMEMORY TRIAGE\n\nEvery piece of knowledge enters the Spine with a LIFECYCLE.\n\nSTAGE 1: HOT MEMORY (0-7 days)\n→ Recent events, active context\n→ Lives in fast storage (Postgres / KV)\n→ Available instantly to every workbench and Twin\n→ Example: \"Sarah reviewed Acme Corp today at 9:14 AM\"\n→ Example: \"Bug #8821 resolved 2 hours ago\"\n\nSTAGE 2: WARM MEMORY (7-30 days)\n→ Still relevant, accessed occasionally\n→ Migrated to indexed storage\n→ Available on query, not pre-loaded\n→ Example: \"Acme Corp health has dropped 3 times this month\"\n→ Example: \"David approved 14 of 16 proposals in the last 2 weeks\"\n\nSTAGE 3: COLD MEMORY (30-90 days)\n→ Historical reference\n→ Lives in R2 (object storage)\n→ Indexed for search and pattern analysis\n→ Example: \"Q1 churn pattern: accounts with health < 60\nat renewal had 73% churn rate\"\n→ Example: \"Sarah's Q1 close rate was 34%\"\n\nSTAGE 4: PERMANENT MEMORY (90+ days → forever)\n→ Crystallized organizational knowledge\n→ Patterns that have proven true over time\n→ Behavioral models that are stable\n→ Decisions that define how the org operates\n→ Example: \"Enterprise accounts always get auto-escalation\"\n→ Example: \"Customer health correlates with bug resolution time\"\n→ Example: \"Executive QBRs happen quarterly, always with\nhealth and pipeline data\"\n\nSTAGE 5: DISCARDED\n→ Temporary noise\n→ One-off events that don't repeat\n→ Outdated information superseded by new data\n→ Example: \"Slack message 'lunch at noon?' — no business value\"\n→ Example: \"Draft email never sent — superseded by final version\"\n\nTHE TRIAGE RULES:\n→ Repeated patterns STRENGTHEN (move toward permanent)\n→ One-off events DECAY (move toward discarded)\n→ User-confirmed knowledge ELEVATES (instantly becomes trusted)\n→ AI-observed patterns must PROVE themselves over time\n→ Organizational decisions are PERMANENT by default\n→ Personal preferences decay when the person changes roles\n\nTHE TRIAGE PIPELINE:\nNew knowledge enters\n│\n▼\nIs this a user-created decision or document?\n│\n├── Yes → Permanent Memory (organizational record)\n│\n▼\nIs this an AI-observed pattern?\n│\n├── Yes → Hot Memory (needs to prove itself)\n│ After 7 repetitions → Warm\n│ After 30 repetitions → Cold/Indexed\n│ After 90 repetitions with accuracy → Permanent\n│\n▼\nIs this a one-off event?\n│\n├── Yes → Hot Memory (7 days)\n│ No repetition → Decay → Discard\n│ Repeated → Escalate to Warm\n│\n▼\nIs this external data (from tools)?\n│\n├── Yes → Follow retention policy\n│ 90 days Slack → Archive to R2\n│ Indefinite CRM → Keep in Spine\n│ Per governance settings\n│\n▼\nMemory Triage Worker runs every night\nDecides what stays. What moves. What dies.\n⁠\nThe Agnostic Layers\nThe system must be agnostic at every level. No dependency on any specific tool, model, frontend, or deployment.\nAGNOSTIC LAYERS\n\n┌─────────────────────────────────────────────────────┐\n│ INTEGRATION AGNOSTIC │\n│ ───────────────────── │\n│ The system does not care what tools connect. │\n│ │\n│ Salesforce? → Nango Adapter │\n│ HubSpot? → Nango Adapter │\n│ Jira? → Native Adapter │\n│ Custom API? → MCP Adapter │\n│ Database? → Direct Connector │\n│ LLM API? → LLM Call Adapter │\n│ │\n│ The Spine doesn't know the source. │\n│ It only knows canonical data. │\n│ │\n├─────────────────────────────────────────────────────┤\n│ AI MODEL AGNOSTIC │\n│ ───────────────────── │\n│ The system does not care which AI model runs. │\n│ │\n│ Claude? → Works │\n│ GPT? → Works │\n│ Gemini? → Works │\n│ Kimi? → Works │\n│ DeepSeek? → Works │\n│ Local model? → Works │\n│ Future model? → Works │\n│ │\n│ Context stays in the Spine. │\n│ Model swaps underneath. │\n│ The Twin's intelligence is model-independent. │\n│ │\n├─────────────────────────────────────────────────────┤\n│ FRONTEND AGNOSTIC │\n│ ───────────────────── │\n│ The system does not care what renders it. │\n│ │\n│ Web browser? → Works │\n│ Mobile app? → Works │\n│ CLI? → Works │\n│ Slack? → Works │\n│ Teams? → Works │\n│ VS Code? → Works │\n│ ChatGPT? → Works │\n│ Embedded widget? → Works │\n│ Partner portal? → Works │\n│ │\n│ All are projections of the same Spine. │\n│ │\n├─────────────────────────────────────────────────────┤\n│ DEPLOYMENT AGNOSTIC │\n│ ───────────────────── │\n│ The system does not care where it runs. │\n│ │\n│ Vercel? → Works │\n│ Cloudflare Workers? → Works │\n│ Docker? → Works │\n│ Kubernetes? → Works │\n│ On-premise? → Works │\n│ Replit? → Works │\n│ │\n│ The application doesn't know where it runs. │\n│ The platform doesn't know where it runs. │\n│ Only the deployment adapter knows. │\n│ │\n├─────────────────────────────────────────────────────┤\n│ STORAGE AGNOSTIC │\n│ ───────────────────── │\n│ The system does not depend on one storage type. │\n│ │\n│ Postgres? → Structured data │\n│ KV (Redis/Workers KV)? → Hot cache, sessions │\n│ R2? → Files, documents, cold memory │\n│ Vector DB? → Semantic search, embeddings │\n│ Queues? → Event processing, pipeline stages │\n│ Logs? → Audit, observability │\n│ │\n│ The Spine orchestrates across all of them. │\n│ │\n└─────────────────────────────────────────────────────┘\n⁠\nIntegration Manager — Full Detail\nINTEGRATION MANAGER\n\nWhat it IS:\n→ The stateless plumbing between external tools and the Spine\n→ It does not store business logic\n→ It does not make decisions\n→ It connects apps to truth\n\nWhat it OWNS:\n→ Discovery: What tools exist in the marketplace\n→ Connection: OAuth, API keys, tokens\n→ Consent: What data the user allows access to\n→ Capability Discovery: What can this tool do?\n→ Provider Registry: What adapters are available?\n→ Sync: Pulling and pushing data\n→ Webhooks: Real-time event streams\n→ MCP: Model Context Protocol for AI-native tools\n→ Health: Is the connection alive?\n→ Lifecycle: Connect, sync, pause, disconnect\n\nADAPTER TYPES:\n┌─────────────────────────────────────────────┐\n│ Nango Adapter │\n│ → For tools with OAuth (Salesforce, HubSpot,│\n│ Slack, Google, Microsoft) │\n│ → Managed OAuth flows │\n│ → Token refresh │\n│ → Standard API polling │\n├─────────────────────────────────────────────┤\n│ Native Adapter │\n│ → For tools we built custom integrations for│\n│ → Jira, GitHub, Linear, Notion │\n│ → Deep schema mapping │\n│ → Webhook-native │\n├─────────────────────────────────────────────┤\n│ MCP Adapter │\n│ → For AI-native tool connections │\n│ → Model Context Protocol │\n│ → Tool exposes capabilities to AI directly │\n│ → Used when AI needs to call tool functions │\n├─────────────────────────────────────────────┤\n│ Direct API Connector │\n│ → For custom / internal APIs │\n│ → User provides endpoint + auth │\n│ → Schema mapping configured manually │\n├─────────────────────────────────────────────┤\n│ LLM Call Adapter │\n│ → For AI-to-AI communication │\n│ → One AI system calling another │\n│ → Example: IntegrateWise Twin calling │\n│ a specialized coding agent │\n│ → Structured prompt + response pipeline │\n└─────────────────────────────────────────────┘\n\nTHE CONNECTION FLOW:\nUser clicks \"Connect Salesforce\"\n│\n▼\nIntegration Manager receives request\n│\n▼\nSelects adapter: Nango Adapter for Salesforce\n│\n▼\nInitiates OAuth flow\n│\n▼\nUser authorizes in Salesforce\n│\n▼\nToken received and stored securely\n│\n▼\nCapability Discovery runs:\n→ \"Salesforce exposes: Accounts, Contacts,\nCases, Opportunities, Tasks, Custom Objects\"\n→ Schema introspection\n→ Field mapping to canonical models\n│\n▼\nCapability Registry updated:\n→ \"This workspace now has Salesforce capabilities\"\n→ Available to Spine, Workbench, and Twin\n│\n▼\nInitial sync begins:\n→ Bulk pull of historical data\n→ Pushed to Spine ingestion queue\n│\n▼\nWebhook subscription:\n→ Real-time events now stream\n→ Salesforce → Integration Manager → Spine\n│\n▼\nConnection live.\nHealth monitoring begins.\n⁠\nCapability Fabric\nThis is the layer that sits between connected tools and the rest of the system. It answers the question: “What can this workspace do right now?”\nCAPABILITY FABRIC\n\nThe Capability Fabric is a living registry of everything\nthe workspace can do, based on what tools are connected,\nwhat domain packs are active, and what permissions exist.\n\n┌─────────────────────────────────────────────────────┐\n│ CAPABILITY SOURCES │\n│ │\n│ From Connected Tools: │\n│ Salesforce → Account CRUD, Contact CRUD, │\n│ Case Management, Pipeline Tracking │\n│ Slack → Channel Read, Message Read, Send Message, │\n│ Thread Read │\n│ Jira → Issue CRUD, Sprint Management, Board View │\n│ HubSpot → Deal CRUD, Contact Sync, Workflow Trigger│\n│ Calendar → Event Read, Create Event, Attendee Mgmt │\n│ │\n│ From Domain Packs: │\n│ Customer Success → Health Scoring, Renewal Tracking,│\n│ Escalation Routing │\n│ Sales → Pipeline Management, Forecast, Lead Scoring│\n│ Engineering → Sprint Board, PR Tracking, Standup │\n│ Finance → Invoice Tracking, Revenue Recognition │\n│ Executive → KPI Dashboard, Portfolio View, Risk Map │\n│ │\n│ From Shared Features: │\n│ Timeline, Search, Entity360, Notifications, │\n│ Approvals, Knowledge, Activity Feed │\n│ │\n│ From Platform: │\n│ Identity, Governance, Memory, Twin Intelligence │\n│ │\n└─────────────────────────────────────────────────────┘\n\nHOW IT WORKS:\n\n1. Admin connects Salesforce\n   → Capability Discovery runs\n   → \"Salesforce Account CRUD\" registered\n2. Admin enables Customer Success domain pack\n   → \"Health Scoring\" capability registered\n   → \"Renewal Tracking\" capability registered\n3. The Fabric now knows:\n   → This workspace CAN create/update accounts (from Salesforce)\n   → This workspace CAN score account health (from CS pack)\n   → This workspace CAN track renewals (from CS pack + Salesforce)\n4. Any workbench or Twin can query the Fabric:\n   → \"What capabilities do I have for Acme Corp?\"\n   → Fabric returns: Account CRUD, Health Scoring,\n   Case Management, Slack Messaging, Calendar Scheduling\n5. The Twin uses the Fabric to know what actions it CAN propose:\n   → \"I can escalate a case (Jira + Governance)\"\n   → \"I can send a Slack message (Slack adapter)\"\n   → \"I can create a calendar event (Calendar adapter)\"\n   → \"I CANNOT update the billing system (not connected)\"\n   ⁠\n   GTM Motion — The Full Journey\n   THE USER'S GTM JOURNEY\n\nSTAGE 1: DISCOVERY\n│\n│ User finds IntegrateWise through:\n│ → Connector Marketplace (searching for a Slack integration)\n│ → Google search (\"unified workspace for sales teams\")\n│ → AI Marketplace (browsing AI-powered tools)\n│ → Referral from another user\n│ → Content / blog / social\n│\n▼\nSTAGE 2: SIGNUP\n│\n│ User signs up:\n│ → From Marketplace: \"Install\" → Redirected to signup\n│ → From website: \"Start Free\" → Email + password\n│ → From AI app: \"Connect to IntegrateWise\" → OAuth\n│\n│ Identity created.\n│ Workspace provisioned.\n│\n▼\nSTAGE 3: IDENTITY + AUTH\n│\n│ Single EcosystemConnection established (L0)\n│ One trust boundary for the entire workspace\n│  \n │ Auth methods:\n│ → Direct OAuth (user authorizes tools)\n│ → API Key (for developer connections)\n│ → MCP (for AI-native tool connections)\n│ → LLM Call (for AI-to-AI communication)\n│ → Direct connector (for custom integrations)\n│\n▼\nSTAGE 4: CONNECT\n│\n│ Connector Marketplace opens\n│ User selects tools:\n│ → \"Connect Salesforce\" → OAuth flow → Connected\n│ → \"Connect Slack\" → OAuth flow → Connected\n│ → \"Connect Jira\" → OAuth flow → Connected\n│  \n │ Or via MCP:\n│ → \"Connect to this AI coding assistant\" → MCP handshake\n│  \n │ Or via LLM Call:\n│ → \"Use GPT-4 for document analysis\" → API key → Active\n│\n▼\nSTAGE 5: SPINE HYDRATION\n│\n│ Instant Hydration (60 seconds):\n│ → Basic entity count\n│ → \"847 accounts, 12,000 contacts found\"\n│ → Enough to show value immediately\n│\n│ Operational Hydration (5-15 minutes):\n│ → Full entity resolution\n│ → Relationship mapping\n│ → Timeline population\n│ → Search indexing\n│ → Workbench ready for daily use\n│\n│ Continuous Hydration (ongoing):\n│ → Real-time sync\n│ → Memory building\n│ → Pattern detection\n│ → AI learning begins\n│\n▼\nSTAGE 6: TWIN ACTIVATION\n│\n│ The Twin wakes up for the first time:\n│ → Reviews the hydrated Spine\n│ → Identifies: \"Here are the key items for today\"\n│ → Surfaces in the workbench:\n│\n│ \"Welcome to your workspace. Here's what I found:\n│ → 3 accounts need attention (health declining)\n│ → 2 deals at risk (stalled for 20+ days)\n│ → 5 tasks overdue across your team\n│ → 1 renewal this week\n│  \n │ [View Details] [Configure Notifications]\"\n│\n▼\nSTAGE 7: DAILY USE\n│\n│ User works. System works. AI learns.\n│ Every day the same lifecycle.\n│ Every day the system is smarter.\n│\n▼\nSTAGE 8: EXPANSION\n│\n│ User adds more tools\n│ User invites more team members\n│ User enables more domain packs\n│ User upgrades tier\n│ The platform grows with them\n⁠\nOODA for Connected Tools\nThe AI does not just learn from user behavior and organizational data. It also learns from the tools themselves.\nOODA FOR CONNECTED TOOLS\n\nThe system doesn't just connect tools and forget.\nThe AI must understand each tool deeply.\n\nOBSERVE:\n→ What tools are connected?\n→ What data does each tool produce?\n→ What actions does each tool support?\n→ How frequently does data change?\n→ What is the tool's data quality?\n→ What patterns exist in the tool's data?\n\nORIENT:\n→ \"Salesforce updates accounts 47 times/day on average\"\n→ \"Slack produces 340 messages/day across 12 channels\"\n→ \"Jira has 23 active issues, 4 blocked\"\n→ \"HubSpot deal stages change every 3.2 days on average\"\n→ \"Calendar has 14 meetings/week for this team\"\n→ \"The tool has a memory: Salesforce knows 3 years\nof customer history\"\n\nDECIDE:\n→ \"This tool's data is high-signal for health scoring\"\n→ \"This tool's data is noise for executive reporting\"\n→ \"This tool needs real-time sync (Slack) vs\ndaily batch (Calendar)\"\n→ \"This tool's historical data should be fully\nextracted for memory building\"\n\nACT:\n→ Adjust sync frequency per tool\n→ Prioritize extraction of high-value data\n→ Build tool-specific knowledge models\n→ Recommend tool-specific workbench views\n\nLEARN:\n→ \"Over 30 days, Salesforce data predicts churn\nbetter than HubSpot data for this workspace\"\n→ \"Slack escalation messages have 89% correlation\nwith health drops\"\n→ \"Jira bug resolution time directly predicts\ncustomer satisfaction\"\n→ \"The memory of each tool is different.\nRespect each tool's history.\"\n⁠\nContinuity Pipelines and Workers\nThis is the processing engine that runs underneath everything. These are the actual compute units that do the work.\nCONTINUITY PIPELINES\n\nA pipeline is a sequence of processing stages.\nEach stage does one job.\nData flows from stage to stage.\nWorkers execute each stage.\n\nTHE MAIN PIPELINES:\n\n┌─────────────────────────────────────────────────────┐\n│ PIPELINE 1: INGESTION PIPELINE │\n│ ────────────────────────────── │\n│ │\n│ Worker: Ingestion Worker │\n│ Trigger: Webhook received / Poll timer fired │\n│ │\n│ Stage 1: RECEIVE │\n│ → Worker receives raw payload from Integration Mgr │\n│ → Validates payload format │\n│ → Assigns event ID │\n│ │\n│ Stage 2: QUEUE │\n│ → Pushes to processing queue │\n│ → Ensures ordering per entity │\n│ → Handles backpressure │\n│ │\n│ Worker runs on Cloudflare Queues or equivalent │\n│ Scales automatically based on event volume │\n│ │\n├─────────────────────────────────────────────────────┤\n│ PIPELINE 2: NORMALIZATION PIPELINE │\n│ ────────────────────────────────── │\n│ │\n│ Worker: Normalization Worker │\n│ Trigger: Event in processing queue │\n│ │\n│ Stage 1: PARSE │\n│ → Read raw payload │\n│ → Identify source system (Salesforce, Slack, etc) │\n│ → Map to canonical schema │\n│ │\n│ Stage 2: TRANSFORM │\n│ → Salesforce Account → Canonical Organization │\n│ → Slack Message → Canonical Conversation │\n│ → Jira Issue → Canonical Task │\n│ → Field mapping, type conversion, validation │\n│ │\n│ Stage 3: VALIDATE │\n│ → Schema validation │\n│ → Data quality check │\n│ → Reject malformed events │\n│ │\n│ Output: Canonical event ready for resolution │\n│ │\n├─────────────────────────────────────────────────────┤\n│ PIPELINE 3: RESOLUTION PIPELINE │\n│ ────────────────────────────── │\n│ │\n│ Worker: Resolution Worker │\n│ Trigger: Canonical event from normalization │\n│ │\n│ Stage 1: ENTITY RESOLUTION │\n│ → \"Acme Corp\" (Salesforce) = \"Acme Corporation\" │\n│ (HubSpot) = \"#acme-cs\" (Slack) │\n│ → Match, merge, or create entities │\n│ → Confidence scoring on matches │\n│ │\n│ Stage 2: RELATIONSHIP RESOLUTION │\n│ → Entity → has → contacts │\n│ → Entity → has → deals │\n│ → Entity → has → cases │\n│ → Entity → related_to → other entities │\n│ → Bidirectional relationship graph maintained │\n│ │\n│ Stage 3: SPINE WRITE │\n│ → Write resolved entity to Spine │\n│ → Update Entity360 │\n│ → Update relationship graph │\n│ → Update search index │\n│ │\n│ Output: Updated Spine with resolved entities │\n│ │\n├─────────────────────────────────────────────────────┤\n│ PIPELINE 4: TIMELINE PIPELINE │\n│ ────────────────────────────── │\n│ │\n│ Worker: Timeline Worker │\n│ Trigger: Entity update in Spine │\n│ │\n│ Stage 1: EVENT RECORD │\n│ → Create timeline entry │\n│ → Timestamp, entity, action, source │\n│ → Link to source event │\n│ │\n│ Stage 2: SEQUENCE │\n│ → Place in chronological order │\n│ → Link related events (same entity, same session) │\n│ → Detect event clusters │\n│ │\n│ Stage 3: INDEX │\n│ → Add to search index │\n│ → Add to entity timeline │\n│ → Add to user activity feed │\n│ │\n│ Output: Searchable, chronological event history │\n│ │\n├─────────────────────────────────────────────────────┤\n│ PIPELINE 5: KNOWLEDGE PIPELINE │\n│ ────────────────────────────── │\n│ │\n│ Worker: Knowledge Worker │\n│ Trigger: Unstructured data ingested │\n│ │\n│ Stage 1: CLASSIFY │\n│ → Is this a document? Conversation? Email? │\n│ → What entities does it reference? │\n│ → What domain does it belong to? │\n│ │\n│ Stage 2: EXTRACT │\n│ → Pull key information │\n│ → Named entities, dates, amounts, decisions │\n│ → Attachments, links, references │\n│ │\n│ Stage 3: EMBED │\n│ → Generate vector embeddings │\n│ → Store in vector DB for semantic search │\n│ → Link to source entity │\n│ │\n│ Stage 4: CLASSIFY FOR TRIAGE │\n│ → Hot memory? (recent, frequently accessed) │\n│ → Warm memory? (older, occasionally accessed) │\n│ → Cold memory? (historical, rarely accessed) │\n│ → Permanent? (organizational decision / playbook) │\n│ → Discard? (noise, no business value) │\n│ │\n│ Output: Classified, searchable, triaged knowledge │\n│ │\n├─────────────────────────────────────────────────────┤\n│ PIPELINE 6: R2 TRIAGE PIPELINE │\n│ ────────────────────────────── │\n│ │\n│ Worker: Triage Worker │\n│ Trigger: Nightly batch / Memory age threshold │\n│ │\n│ Stage 1: SCAN │\n│ → Review all Hot memory items │\n│ → Check age, access frequency, relevance score │\n│ │\n│ Stage 2: DECIDE │\n│ → Age > 7 days, accessed < 3 times → Move to Warm │\n│ → Age > 30 days, accessed < 1 time → Move to Cold │\n│ → Age > 90 days, no access → Archive or Discard │\n│ → User-marked \"important\" → Permanent │\n│ → AI pattern with > 90% accuracy → Permanent │\n│ │\n│ Stage 3: MOVE │\n│ → Hot → Warm: Move from Postgres to indexed KV │\n│ → Warm → Cold: Move from KV to R2 object storage │\n│ → Cold → Archive: Compress and store in R2 │\n│ → Discard: Remove from active storage │\n│ → Permanent: Copy to permanent memory store │\n│ │\n│ Stage 4: UPDATE INDEX │\n│ → Search index updated │\n│ → Entity references updated │\n│ → Memory graph updated │\n│ │\n│ Output: Optimized storage with clear memory tiers │\n│ │\n├─────────────────────────────────────────────────────┤\n│ PIPELINE 7: PROJECTION PIPELINE │\n│ ────────────────────────────── │\n│ │\n│ Worker: Projection Worker │\n│ Trigger: User opens workbench / Spine update │\n│ │\n│ Stage 1: IDENTIFY │\n│ → Who is the user? │\n│ → What workbench are they opening? │\n│ → What projection rules apply? │\n│ │\n│ Stage 2: QUERY │\n│ → Pull relevant entities from Spine │\n│ → Pull relevant timeline events │\n│ → Pull relevant knowledge │\n│ → Apply access control (Governance) │\n│ │\n│ Stage 3: ASSEMBLE │\n│ → Apply projection rules │\n│ → Arrange data into workbench format │\n│ → Include shared features │\n│ → Include domain-specific features │\n│ → Include private features │\n│ │\n│ Stage 4: DELIVER │\n│ → Send to frontend │\n│ → Cache for performance │\n│ → Subscribe for real-time updates │\n│ │\n│ Output: Ready-to-render workbench │\n│ │\n├─────────────────────────────────────────────────────┤\n│ PIPELINE 8: CONTINUITY PIPELINE │\n│ ────────────────────────────── │\n│ │\n│ Worker: Continuity Worker │\n│ Trigger: Always running (streaming) │\n│ │\n│ This is the master orchestrator. │\n│ It does not process data itself. │\n│ It ensures all other pipelines are connected. │\n│ │\n│ Stage 1: MONITOR │\n│ → Is Ingestion healthy? │\n│ → Is Normalization keeping up? │\n│ → Is Resolution running? │\n│ → Is Timeline current? │\n│ → Is Knowledge indexed? │\n│ → Is Triage scheduled? │\n│ → Is Projection responsive? │\n│ │\n│ Stage 2: ORCHESTRATE │\n│ → Route events to the right pipeline │\n│ → Handle pipeline failures │\n│ → Retry on errors │\n│ → Scale workers based on load │\n│ │\n│ Stage 3: GUARANTEE │\n│ → No event is lost │\n│ → No entity is unresolved │\n│ → No timeline gap exists │\n│ → Continuity is maintained │\n│ │\n│ Output: All pipelines running. Continuity intact. │\n│ │\n└─────────────────────────────────────────────────────┘\n⁠\nHow Workers Carry User Work Every Day\nWorkers are not abstract. They are the daily labor force of the system. Every piece of work the user sees completed was done by a worker.\nWHAT WORKERS DO EVERY DAY\n\nMORNING (Before user arrives):\nSync Worker\n→ Pulled 12,000 events overnight from all tools\n→ Normalization Worker processed all 12,000\n→ Resolution Worker resolved 847 entity updates\n→ Timeline Worker recorded 4,200 timeline events\n→ Knowledge Worker indexed 340 new documents/threads\n→ Triage Worker archived 1,200 old memory items\n→ Projection Worker pre-loaded all workbench contexts\n\nDURING WORK (While user works):\nReal-time Sync Worker\n→ Processing 47 webhooks per minute\n→ Every Slack message → Spine within 2 seconds\n→ Every Salesforce update → Spine within 5 seconds\n→ Every Jira transition → Spine within 3 seconds\n\nProjection Worker\n→ User clicks on \"Acme Corp\"\n→ Worker queries Spine, assembles Entity360\n→ Returns unified view in < 200ms\n→ Subscribes user to real-time updates for Acme\n\nNotification Worker\n→ \"Acme health dropped below 65\" → notification fired\n→ \"Meeting in 15 minutes\" → notification fired\n→ \"PR #431 approved\" → notification fired\n→ All deterministic. All pipeline-driven.\n\nSearch Worker\n→ Every new event indexed immediately\n→ User searches \"Acme escalation\" → instant results\n→ Semantic search powered by vector embeddings\n\nEVENING (After user leaves):\nConsolidation Worker\n→ Compressed today's 847 events into memory\n→ Updated organizational knowledge base\n→ Refreshed prediction models\n\nTriage Worker\n→ Aged out 340 hot memory items to warm\n→ Archived 89 warm items to cold storage\n→ Discarded 23 items with no business value\n→ Elevated 3 AI patterns to permanent status\n\nPreparation Worker\n→ Pre-loaded tomorrow's workbench contexts\n→ Queued tomorrow's notifications\n→ Pre-generated standup summaries\n→ Drafted tomorrow's Twin proposals\n\nWORKERS ARE THE SYSTEM'S DAILY WORKFORCE.\nThey do the labor. The user sees the results.\n⁠\nTwin Capabilities — How It Connects, Acts, and Communicates\nHow the Twin Connects to Tools\nTWIN → TOOL CONNECTION\n\nThe Twin NEVER connects to tools directly.\nNever.\n\nThe Twin reads from the Spine.\nThe Twin writes proposals to the Spine.\nThe Integration Manager handles all tool communication.\n\nFLOW:\nTwin needs to know Acme's Salesforce data\n→ Twin reads Entity360 from Spine\n→ Spine already has the data (via Integration Manager)\n→ Twin never touches Salesforce\n\nTwin wants to send a Slack message\n→ Twin writes proposal to Spine: \"Send message to #acme-cs\"\n→ Governance checks the proposal\n→ If approved: Spine → Integration Manager → Slack\n→ Twin never touches Slack\n\nTwin wants to create a Jira ticket\n→ Twin writes proposal to Spine: \"Create P1 for Dataway\"\n→ Governance checks the proposal\n→ If approved: Spine → Integration Manager → Jira\n→ Twin never touches Jira\n\nTHE RULE:\n→ Twin reads truth from Spine\n→ Twin proposes actions to Spine\n→ Integration Manager executes approved actions\n→ Spine records everything\nHow the Twin Gets Work Done via Agents\nTWIN → AGENT COMMUNICATION\n\nSometimes the Twin needs specialized help.\nIt calls other agents.\n\nAGENT-TO-AGENT COMMUNICATION (via Capability Fabric):\n\nTwin needs to analyze a contract PDF\n→ Twin calls: Document Analysis Agent (LLM Call)\n→ Agent reads the PDF from R2\n→ Agent returns structured analysis\n→ Twin incorporates into its reasoning\n\nTwin needs to draft a customer email\n→ Twin calls: Writing Agent (LLM Call)\n→ Agent receives context from Spine\n→ Agent drafts email\n→ Twin reviews and proposes to user\n\nTwin needs to analyze code for a bug\n→ Twin calls: Code Analysis Agent (MCP)\n→ Agent reads the codebase\n→ Agent returns findings\n→ Twin proposes fix to engineer\n\nTwin needs to generate a forecast\n→ Twin calls: Forecasting Agent (LLM Call)\n→ Agent receives pipeline data from Spine\n→ Agent generates forecast\n→ Twin presents in Executive workbench\n\nCAPABILITY FABRIC DECIDES:\n→ What agents are available?\n→ What tools can be called?\n→ What permissions exist?\n→ What governance applies?\n\nThe Twin doesn't hardcode agent connections.\nIt queries the Capability Fabric:\n\"What can I do with the data I have?\"\nThe Fabric returns available capabilities.\nThe Twin selects the best one.\nHow Updates Are Posted to the User\nTWIN → USER COMMUNICATION\n\nThe Twin communicates through FIVE channels:\n\n1. PROPOSALS (In Approvals Workbench)\n   ─────────────────────────────────────\n   The Twin's primary communication method.\n\n   \"Acme Corp health dropped to 62.\n   Recovery plan drafted.\n   [Approve] [Modify] [Dismiss]\"\n\n   Context: Full Entity360 available on expand\n   Confidence: Shown as percentage\n   Priority: Ordered by impact and urgency\n\n2. NOTIFICATIONS (Push to User)\n   ─────────────────────────────────────\n   Real-time alerts when something needs attention.\n\n   \"Acme Corp health alert: dropped below 65\"\n   \"Deal velocity warning: Meridian stalled 22 days\"\n   \"Meeting prep ready: Northwind renewal at 2 PM\"\n\n   Delivered via:\n   → Workbench notification badge\n   → Email (if configured)\n   → Slack (if connected)\n   → Mobile push (if installed)\n   → Browser notification (if permitted)\n\n3. MORNING BRIEFING (Daily Summary)\n   ─────────────────────────────────────\n   The Twin's daily briefing to each user.\n\n   \"Good morning, Sarah. Here's your day:\n   → 3 meetings today\n   → 2 deals need attention (Acme, Meridian)\n   → 1 proposal pending your review\n   → Northwind renewal is Thursday\n   → Top priority: Acme health recovery\"\n\n4. WORKBENCH ENRICHMENT (Inline Intelligence)\n   ─────────────────────────────────────\n   The Twin enriches workbench views with insights.\n\n   User opens Acme Corp Entity360.\n   At the top, a Twin insight bar:\n\n   \"Acme's health trajectory suggests risk.\n   Correlated with unresolved bug #8821.\n   Similar pattern seen in Q1 for Northwind.\n   [View Pattern] [Take Action]\"\n\n   The user didn't ask for this.\n   The Twin saw the pattern and surfaced it.\n\n5. DIRECT MESSAGING (When Enabled)\n   ─────────────────────────────────────\n   The Twin can message the user directly\n   through connected channels.\n\n   Via Slack DM:\n   \"Hi Sarah, I noticed Acme Corp's health dropped\n   to 62. I've drafted a recovery plan.\n   Review it here: [link]\"\n\n   Via Email:\n   Subject: \"Action needed: Acme Corp health alert\"\n   Body: Brief summary + link to workbench\n\n   Via In-App Chat:\n   Conversational interface\n   User can ask: \"What's going on with Acme?\"\n   Twin responds with context from Spine\n\nMESSAGING BETWEEN TWIN AND USER:\n\nTwin → User:\nProposals. Notifications. Briefings. Insights. Direct messages.\n\nUser → Twin:\nApprove / Modify / Dismiss proposals\nAsk questions: \"Why did Acme health drop?\"\nGive commands: \"Schedule a meeting with Acme VP\"\nProvide feedback: \"Don't propose emails for Acme.\nThey prefer calls.\"\nThe Twin LEARNS from every user response.\n⁠\nEssential User Work in the Workbench\nThe workbench is not just a display. The user does real work here. This is L1 — the core product.\nWHAT THE USER DOES IN THE WORKBENCH\n\nThis is NOT agentic. This is NOT AI.\nThis is the user doing their job. On the platform.\n\nSALES REP:\n→ Reviews pipeline\n→ Updates deal stages\n→ Logs call notes\n→ Sends emails\n→ Creates tasks\n→ Schedules meetings\n→ Views customer history\n→ Prepares for meetings\n→ Updates forecasts\n\nAll of this writes to the Spine.\nAll of this syncs back to connected tools.\nAll of this is deterministic. Pipeline-driven.\n\nCS MANAGER:\n→ Reviews health dashboard\n→ Checks open cases\n→ Responds to escalations\n→ Prepares renewal presentations\n→ Logs customer interactions\n→ Updates account notes\n→ Creates QBR documents\n\nENGINEER:\n→ Reviews sprint board\n→ Updates issue status\n→ Submits PRs\n→ Writes code review comments\n→ Updates blockers\n→ Logs time\n→ Documents decisions\n\nEXECUTIVE:\n→ Reviews KPIs\n→ Approves budgets\n→ Reviews portfolio\n→ Checks forecasts\n→ Reads risk reports\n\nALL OF THIS IS USER WORK.\nALL OF THIS IS L1.\nALL OF THIS WRITES TO THE SPINE.\nNONE OF THIS REQUIRES AI.\n\nThe Twin watches this work.\nThe Twin learns from this work.\nThe Twin proposes improvements to this work.\nBut the Twin does NOT do this work.\n\nThe user does the work.\nThe AI helps the user do it better.\n⁠\nData Access Levels — Spine via LLM\nWhat can the LLM see? This is a critical boundary.\nSPINE → LLM DATA ACCESS\n\nThe LLM (Twin's reasoning engine) accesses the Spine\nthrough a structured ACCESS CONTRACT.\n\nLEVEL 1: ENTITY SUMMARY\n→ The LLM receives a structured summary of an entity\n→ Not raw data. Not full database records.\n→ A canonical, pre-processed summary.\n\nExample: Entity360 for Acme Corp\n{\n\"entity\": \"acme-corp\",\n\"type\": \"customer\",\n\"arr\": 1200000,\n\"health_score\": 62,\n\"health_trend\": \"declining\",\n\"open_cases\": 3,\n\"active_deals\": 2,\n\"last_touchpoint\": \"2026-07-02\",\n\"renewal_date\": \"2026-08-15\",\n\"risk_level\": \"moderate\",\n\"champion\": \"John Smith\",\n\"recent_events_count\": 12\n}\n\nLEVEL 2: CONTEXT WINDOW\n→ The LLM receives relevant timeline events\n→ Limited to a configurable window (last 30 days default)\n→ Filtered by relevance score\n→ Summarized if too long\n\nExample: Last 30 days for Acme Corp\n[\n{ \"date\": \"2026-07-02\", \"event\": \"Health dropped to 62\", \"source\": \"Spine\" },\n{ \"date\": \"2026-07-01\", \"event\": \"Slack escalation in #acme-cs\", \"source\": \"Slack\" },\n{ \"date\": \"2026-06-28\", \"event\": \"Bug #8821 reported\", \"source\": \"Jira\" },\n...\n]\n\nLEVEL 3: KNOWLEDGE CONTEXT\n→ The LLM receives relevant knowledge items\n→ Organizational patterns\n→ Historical decisions\n→ User preferences\n\nExample:\n[\n{ \"knowledge\": \"Acme prefers phone calls over email\", \"confidence\": 0.95, \"source\": \"user_input\" },\n{ \"knowledge\": \"Health drops for Acme correlate with bugs\", \"confidence\": 0.89, \"source\": \"ai_pattern\" },\n...\n]\n\nLEVEL 4: CAPABILITY CONTEXT\n→ The LLM receives available capabilities\n→ What actions it CAN propose\n\nExample:\n[\n{ \"capability\": \"create_jira_issue\", \"source\": \"Jira\" },\n{ \"capability\": \"send_slack_message\", \"source\": \"Slack\" },\n{ \"capability\": \"schedule_meeting\", \"source\": \"Calendar\" },\n{ \"capability\": \"draft_email\", \"source\": \"Email\" },\n]\n\nWHAT THE LLM CANNOT ACCESS:\n❌ Raw database queries\n❌ Other users' private data (without governance approval)\n❌ Unredacted PII (governed by policy)\n❌ System credentials or tokens\n❌ Data from entities outside its access scope\n❌ Full historical dumps (limited to context window)\n❌ Direct write access to any system\n\nTHE LLM RECEIVES CONTEXT.\nTHE LLM DOES NOT RECEIVE RAW DATA.\nTHE SPINE GOVERNS WHAT THE LLM CAN SEE.\n⁠\nAgentic Work vs Just Prompts\nThis is the critical classification.\nCLASSIFYING AGENTIC WORK VS PROMPTS\n\nPROMPT (Not Agentic):\n→ User asks a question\n→ LLM answers\n→ No action taken\n→ No tool called\n→ No write to Spine\n→ No governance needed\n→ No approval needed\n\nExamples:\n\"What is Acme Corp's health score?\"\n→ LLM reads Spine context, returns answer\n\n    \"Summarize last week's Slack activity\"\n    → LLM reads timeline, returns summary\n\n    \"What are my tasks for today?\"\n    → LLM reads Spine, returns task list\n\nThis is a PROMPT. Not an agent.\nThe LLM is a reader. Not a doer.\nNo side effects. No writes. No governance.\n\nAGENTIC WORK (Truly Agentic):\n→ The LLM takes an ACTION\n→ A tool is called\n→ A write occurs\n→ Data changes\n→ Governance applies\n→ Approval may be required\n\nExamples:\n\"Escalate Acme's bug to P1\"\n→ LLM proposes → Governance checks →\nUser approves → Jira updated via Integration Manager\n\n    \"Draft and send a recovery email to Acme\"\n    → LLM drafts → Governance checks →\n       User approves → Email sent via Integration Manager\n\n    \"Schedule a QBR with Acme's VP for next Tuesday\"\n    → LLM creates event → Governance checks →\n       User approves → Calendar updated via Integration Manager\n\n    \"Create a new task for the engineering team\"\n    → LLM proposes → Governance checks →\n       User approves → Jira issue created via Integration Manager\n\nThis is AGENTIC. The LLM is an actor. Not just a reader.\nSide effects exist. Writes occur. Governance applies.\n\nTHE CLASSIFICATION:\n\n┌─────────────────────────────────────────────────┐\n│ │\n│ PROMPT AGENTIC │\n│ ───── ─────── │\n│ Reads from Spine Writes to Spine │\n│ No tool calls Tool calls required │\n│ No side effects Side effects exist │\n│ No governance Governance applies │\n│ No approval Approval may be needed│\n│ No agent-to-agent Agent calls agent │\n│ User gets an answer User gets a proposal │\n│ LLM is a READER LLM is an ACTOR │\n│ │\n│ Example: Example: │\n│ \"What's Acme's health?\" \"Escalate Acme's bug\" │\n│ │\n└─────────────────────────────────────────────────┘\n\nTHE GRAY AREA — ENRICHMENT:\n→ LLM reads Spine + external source → Enriches Spine\n→ Example: LLM reads a contract PDF → Extracts key dates\n→ Writes structured data to Spine\n→ This is agentic (write occurs) but low-risk\n→ Governance: auto-approved (enrichment, not action)\n→ Still classified as agentic because Spine changes\n\nTHE ARCHITECTURE RULE:\n→ If the LLM only READS → It is a prompt\n→ If the LLM WRITES or CALLS → It is agentic\n→ All agentic work passes through Governance\n→ All agentic work is recorded in the Spine\n→ The user always knows what the AI did\n⁠\nThe Complete System — Final Definition\nTHE INTEGRATEWISE SYSTEM\n\nPRODUCT (L1 — Pipeline)\n→ One click to connect tools\n→ Integration Manager handles all tool communication\n→ Spine is the Single Source of Truth\n→ User works on unified data in their workbench\n→ Workers process data continuously\n→ Pipelines flow: Ingest → Normalize → Resolve →\nTimeline → Knowledge → Triage → Projection → Experience\n→ Everything deterministic. Everything reliable.\n\nAI (L2 — OODA)\n→ Watches the product (L1 events)\n→ Lives in its Home (user models, org memory, predictions)\n→ Reasons only when action is needed\n→ Proposes actions through Governance\n→ Learns from every outcome\n→ Gets smarter every day\n→ Communicates via proposals, notifications,\nbriefings, insights, and direct messages\n\nCAPABILITY FABRIC\n→ Registry of everything the workspace can do\n→ Sources: Connected tools, domain packs,\nshared features, platform services\n→ Queried by Workbench and Twin alike\n\nAGNOSTIC LAYERS\n→ Integration agnostic (Nango, Native, MCP, LLM Call, Direct)\n→ AI model agnostic (Claude, GPT, Gemini, Local, Future)\n→ Frontend agnostic (Web, Mobile, CLI, Slack, Embedded)\n→ Deployment agnostic (Vercel, Cloudflare, Docker, On-prem)\n→ Storage agnostic (Postgres, KV, R2, Vector, Queues)\n\nMEMORY\n→ Simple data (structured fields)\n→ Rich data (files, images, documents)\n→ Knowledge (human + AI)\n→ Memory triage: Hot → Warm → Cold → Permanent → Discard\n→ Organizational continuity preserved\n\nTHE ONE-LINE DEFINITION:\n\nThe system connects tools with one auth, unifies data into a\nsingle source of truth, lets users work on that truth in their\nown workbench, and gives the AI a home where it watches, learns,\nreasons, proposes, and grows — every day, forever.\n"}