IntegrateWise Platform Thesis v1.0
Tier C — Historical. This document is a point-in-time snapshot preserved for reference. For current architecture, see CANONICAL_PLATFORM_ARCHITECTURE.md.
Canonical Constitutional Document
Status: Approved and Locked
Version: 1.0
Last Updated: PR #37
Executive Summary
IntegrateWise is Organizational Continuity Infrastructure.
It sits above every business system of record and preserves operational continuity across people, AI, workflows, and software. Its purpose is not to replace existing systems, but to connect them into one governed continuity layer that compounds organizational memory, protects canonical truth, and makes execution auditable.
IntegrateWise is built on a simple constitutional principle:
Truth you own. AI you rent. Approval in between.
This means:
- Truth is owned by the platform, not by models, user interfaces, or disconnected tools.
- AI is a replaceable reasoning layer, not the authority center.
- Approval is the control point that prevents automation from bypassing governance.
The product is the LOOP. Every connector, workflow, user action, AI proposal, approval, and automated execution participates in this loop. The LOOP is how IntegrateWise creates continuity over time.
1. Product Identity
IntegrateWise is not a CRM.
It is not an AI assistant.
It is not just another workspace.
It is the continuity layer that sits above business systems and preserves the organization's operational memory, decision history, and execution control.
The product category is Organizational Continuity Infrastructure.
That category matters because it defines the platform's mission:
- preserve operational truth,
- retain decision context,
- govern AI and automation,
- route execution through controlled workflows,
- and compound organizational learning over time.
This is a platform for continuity, not a point solution for one department or one use case.
2. Core Doctrine
The platform is governed by a single constitutional principle:
Truth you own. AI you rent. Approval in between.
This principle is the foundation of every architecture, product, and implementation decision.
Truth you own
Canonical operational truth lives in the platform's Adaptive Spine. Truth is not outsourced to language models, scattered across frontends, or fragmented across integrations. The Spine is the canonical substrate that owns entity state, relationships, lineage, signals, and operational truth.
AI you rent
AI models are treated as ephemeral reasoning engines. They can be replaced, upgraded, swapped, or omitted without changing the platform's identity. The AI layer is powerful, but it is not authoritative.
Approval in between
All important actions must pass through a governance gate before execution. AI may propose. Automation may prepare. Humans or policy may approve. But execution only happens after governance.
This doctrine is what keeps the system trustworthy.
3. The LOOP
The product is the LOOP.
Observe → Understand → Propose → Govern → Execute → Writeback → Evidence Return → Remember → Organize → Learn
The LOOP is the platform's operating pattern. It turns raw events into durable continuity.
Observe
The platform collects signals from systems of record, connectors, users, workflows, and external events.
Understand
The platform resolves identity, context, relationships, and meaning. Data is normalized into operational objects.
Propose
The Twin reasons over context and generates recommendations, summaries, and action proposals.
Govern
Policies, evidence, and human approval determine whether an action may proceed.
Execute
Approved actions are carried out by workflow runtimes, connector actions, or automation packages.
Writeback
Execution results are written back to external systems where appropriate.
Evidence Return
Outcomes, logs, and artifacts are returned to the platform so the loop is auditable.
Remember
The platform records decision context, outcome context, and memory of what happened.
Organize
Knowledge is structured into reusable operational context, policies, patterns, and institutional learning.
Learn
The system refines future reasoning, proposals, and governance based on what happened.
Every completed loop compounds continuity.
4. Platform Architecture
The architecture is permanent in its conceptual shape, even if implementation technologies evolve.
Projections
↓
Gateway
↓
Capability Engine
↓
Projection Engine
↓
Adaptive Spine
↓
Memory
↓
Governance
↓
Workflow Runtime
This architecture is layered so that concerns stay separated.
Gateway
The Gateway is the single public ingress point. All external access flows through it.
Capability Engine
The Capability Engine orchestrates business capabilities and platform actions. It is where shared business logic is exposed as durable platform capability.
Projection Engine
The Projection Engine transforms backend capability into persona-specific experiences. It adapts platform output to the needs of a customer success workspace, executive dashboard, sales environment, or any other projection.
Adaptive Spine
The Adaptive Spine is the canonical operational substrate. It stores and coordinates the platform's truth layer, including entities, relationships, signals, timeline, lineage, and evidence.
Memory
Memory is a separate system that compounds context over time. It stores decisions, reflections, work context, personal context, and organizational learning.
Governance
Governance applies policy, approval, evidence review, compliance checks, and audit controls.
Workflow Runtime
Workflow Runtime executes approved actions. It is where writeback, automation, and connector-driven execution happen.
5. Adaptive Spine
The Adaptive Spine is the canonical continuity substrate.
It owns:
- Entity360,
- identity resolution,
- relationships,
- canonical business objects,
- signals,
- timelines,
- lineage,
- and operational truth.
The Spine does not replace source systems of record.
Instead, it aggregates, normalizes, and preserves continuity across them. It is the place where the organization's operational state becomes coherent.
The Spine is not just a database. It is the platform's truth layer.
6. Memory
Memory is separate from truth.
That distinction is important.
Truth is canonical operational state. Memory is compounding context.
Memory includes:
- personal memory,
- work memory,
- organizational memory,
- conversational memory,
- AI memory,
- decision memory,
- and reflection memory.
Memory evolves over time. It can be promoted, versioned, scoped, linked, retrieved, or allowed to decay. It helps the system remember what happened, what was decided, what worked, and what should be repeated.
The Twin reasons over memory, but memory does not replace truth.
7. Twin Doctrine
The Twin is a reasoning layer.
It is not the operating system. It is not the system of record. It is not the execution authority.
The Twin can:
- observe,
- understand,
- reason,
- propose,
- explain,
- and draft.
The Twin cannot:
- own truth,
- bypass governance,
- execute direct writeback,
- or mutate systems of record without approval.
This matters because the platform is designed for safe human-AI collaboration, not autonomous hidden control.
The Twin helps the organization think. It does not own the organization's truth.
8. Governance Doctrine
Governance is the control plane.
Nothing writes without governance.
Every important action flows through:
- proposal,
- evidence,
- policy,
- approval,
- execution.
Governance ensures that the platform remains trustworthy, auditable, and aligned with organizational intent.
Governance owns:
- policies,
- human-in-the-loop review,
- audit,
- evidence,
- confidence,
- lineage,
- and approval state.
If a proposal cannot pass governance, it does not execute.
9. Execution Doctrine
Execution belongs to the Workflow Runtime.
Workflows may use:
- MCP,
- browser agents,
- APIs,
- Cloudflare Workers,
- automation packages,
- connector actions,
- scheduled jobs,
- or other supported execution mechanisms.
The execution mechanism is replaceable.
The governance model is not.
The Twin proposes. The workflow executes approved actions. This preserves the doctrine that reasoning and execution remain separate.
10. Source Systems
Source systems remain authoritative.
IntegrateWise does not replace:
- CRM,
- support tools,
- finance systems,
- collaboration platforms,
- or knowledge systems.
Instead, it preserves continuity across them.
This is an essential design decision. The platform is not trying to become the system of record for every domain. It is trying to create a governed continuity layer above them.
That allows the organization to unify operational context without forcing every team into one monolithic application.
11. Workbench Doctrine
The Workbench is the primary operating surface of IntegrateWise.
People do not work inside applications. AI does not work inside applications. Governance does not happen inside applications. Everything operates through governed Workbenches that project continuity from the Adaptive Spine.
Applications become capabilities rather than destinations. The Workbench is never the system of record, never owns canonical truth, and only projects governed context into the appropriate experience.
The Workbench exists to eliminate operational fragmentation by bringing together context, memory, knowledge, intelligence, tasks, conversations, approvals, evidence, and actions into a continuous operating environment.
Every Workbench is a projection:
- No Workbench owns data.
- No Workbench owns truth.
- Every Workbench reads from the same governed platform.
- Different Workbenches expose different perspectives over the same organizational continuity.
Specialized Workbenches include:
- Human Workbench — the primary workspace where people understand, decide, collaborate, approve, and act.
- Twin Workbench — the reasoning workspace where the Twin observes, understands, reasons, drafts, explains, and proposes without bypassing governance.
- Governance Workbench — the operational control plane for approvals, policies, evidence, lineage, confidence, audit, and governance decisions.
- Knowledge Workbench — the projection for documentation, institutional memory, architecture, playbooks, and lessons learned.
- Domain Workbenches — role-specific projections such as Executive, Customer Success, Sales, Finance, Engineering, Marketing, Operations, and HR.
Constitutional principles:
- Every experience is a Workbench.
- Every Workbench is a projection.
- No Workbench owns canonical truth.
- Every Workbench consumes governed context.
- Specialized Workbenches share one Adaptive Spine.
- Governance protects all Workbenches equally.
- Applications remain replaceable; the Workbench remains consistent.
This replaces the old Frontend Doctrine and any separate Human Workbench Doctrine. The Human Workbench is one specialized projection within the broader Workbench Doctrine, alongside the Twin, Governance, Knowledge, and role-specific Workbenches.
See docs/architecture/WORKBENCH_DOCTRINE.md for the canonical Workbench Doctrine.
12. Backend Principles
The backend is the permanent asset.
It owns:
- continuity,
- cognition,
- governance,
- execution,
- memory,
- and knowledge.
The Workbench layer owns:
- rendering,
- interaction,
- local UI state,
- and user experience.
The backend follows these principles:
- Gateway is the only public entry point.
- Internal services communicate through platform contracts.
- Capabilities are shared.
- Projection decides presentation.
- Runtime is replaceable.
- Providers are replaceable.
- Models are replaceable.
- Doctrine remains stable even when implementation changes.
13. The Seven Agnostic Principles
IntegrateWise is:
- model agnostic,
- provider agnostic,
- runtime agnostic,
- frontend agnostic,
- connector agnostic,
- workflow agnostic,
- and infrastructure agnostic.
Only the platform protocol is permanent.
This means the platform can evolve technically without changing its identity.
That flexibility is critical for long-lived continuity infrastructure.
14. Canonical Laws
These are the platform's constitutional laws:
- Identity belongs to IntegrateWise.
- The Adaptive Spine is the only canonical operational truth.
- Memory compounds; truth remains canonical.
- Nothing writes without governance.
- The Twin reasons and proposes; it does not execute writeback.
- Workflows execute approved actions.
- Every interaction follows the LOOP.
- Frontends are projections; the platform is permanent.
- Source systems remain the systems of record.
- Implementation technologies may evolve; the doctrine does not.
These laws should remain stable unless the platform's philosophy itself changes.
15. Documentation Structure
To avoid drift between architecture, implementation, and planning, the documentation is divided into four permanent artifacts.
1. Platform Thesis (this document)
Defines:
- product identity,
- doctrine,
- the LOOP,
- and platform philosophy.
Changes only when the platform's constitutional assumptions change.
2. Canonical Architecture
Defines:
- backend topology,
- gateway routes,
- projection engine,
- capability engine,
- Adaptive Spine,
- memory,
- governance,
- workflow runtime,
- and frontend contracts.
Changes only when the architecture changes.
3. Canonical State
Defines:
- what is implemented,
- what is verified,
- what is deployed,
- production gates,
- and the current reality matrix.
Must be based on code and validation, not assumptions.
4. Sprint Plan
Defines:
- active implementation work,
- current priorities,
- and short-term delivery goals.
Temporary and disposable after work is complete.
16. Authentication and Access
Every client must authenticate and authorize through the platform gateway.
The platform may support identity providers such as Clerk or Supabase for user login and session issuance. Once authenticated, the user's session and tenant context determine authorization boundaries.
Connector onboarding and approval are separate from identity. Identity proves who the user is. Authorization determines what they may access. Governance determines what may execute.
This separation is critical for trust.
17. Data Flow and Continuity Flow
Data enters the platform through connectors, webhooks, syncs, user actions, or automated events.
It is then:
- ingested,
- normalized,
- identity-resolved,
- written into the Spine,
- assembled into Entity360,
- reasoned over by the Twin,
- governed,
- executed by workflows,
- written back to source systems,
- and returned as evidence and memory.
This is how IntegrateWise compounds continuity.
The platform does not merely store data. It turns data into operational memory, governed action, and reusable organizational learning.
18. API and SDK Direction
The platform should expose a canonical API Gateway and a type-safe SDK.
The SDK is the preferred way for frontends and clients to interact with the platform. It ensures that:
- frontends remain thin,
- business logic stays in the backend,
- contract boundaries stay stable,
- and implementation details remain hidden.
Clients should not talk directly to internal services, databases, or runtime primitives. They should use the Gateway and SDK.
This keeps the platform swappable without exposing topology to every consumer.
19. Stakeholder Interpretation
For stakeholders, the most important idea is simple:
IntegrateWise is the organizational continuity layer for the business.
It keeps truth, memory, governance, and execution aligned across many tools and many frontends. It allows AI to help without letting AI become the authority. It lets the organization modernize without losing continuity.
That is the real product.
Not a dashboard.
Not a chatbot.
Not a workflow tool.
Not a CRM.
A governed system for organizational continuity.
20. Final Identity
If this platform must be reduced to one sentence, it is this:
IntegrateWise is Organizational Continuity Infrastructure that preserves operational continuity across people, AI, workflows, and software through a governed continuity loop, while allowing unlimited frontends to project the same canonical operational truth.
That sentence should remain the anchor for every future product, engineering, and architecture decision.
Source: PR #37 - Official Platform Thesis v1.0
Locked: Constitutional document - changes require architectural review