{"slug":"documentation/ARCHITECTURE_DOCUMENTATION_PLAN","title":"IntegrateWise Architecture Documentation Plan","section":"documentation","sectionLabel":"Documentation","status":"unclassified","type":"document","path":"documentation/ARCHITECTURE_DOCUMENTATION_PLAN.mdx","bytes":45991,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n## 1. Governing Documentation Principle\n\nIntegrateWise must be documented **bottom-up**.\n\nNo top-level architecture diagram may introduce a component, responsibility, data path, or control mechanism that has not already been defined in an underlying core specification.\n\nThe required sequence is:\n\n```text\nArchitecture Doctrine\n        ↓\nArchitecture Kernel and Terminology\n        ↓\nIndependent Core Specifications\n        ↓\nCore Contracts and Boundaries\n        ↓\nCross-Core Interaction Specifications\n        ↓\nRuntime Sequences\n        ↓\nDeployment and Operational Architecture\n        ↓\nCustomer and Marketplace Journeys\n        ↓\nComplete Platform Architecture\n```\n\nA core is considered architecturally defined only when its:\n\n- Purpose\n- Ownership boundary\n- Internal components\n- Data model\n- Inputs and outputs\n- Contracts\n- Runtime lifecycle\n- Security model\n- Failure model\n- Deployment model\n- Observability\n- Invariants\n\nhave been documented.\n\n---\n\n# 2. Architectural Classification\n\nEvery IntegrateWise subsystem must be classified correctly.\n\n| Classification | Meaning                                                     |\n| -------------- | ----------------------------------------------------------- |\n| **Platform**   | A broad domain containing multiple cores                    |\n| **Core**       | A subsystem with an explicit ownership boundary             |\n| **Fabric**     | A distributed coordination layer spanning multiple cores    |\n| **Engine**     | A system that transforms or evaluates inputs                |\n| **Runtime**    | A system responsible for executing definitions              |\n| **Registry**   | An authoritative catalogue of definitions or metadata       |\n| **Manager**    | A lifecycle-management control plane                        |\n| **Workbench**  | A governed human-facing operational surface                 |\n| **Projection** | A derived read model assembled from canonical sources       |\n| **Adapter**    | A provider-specific implementation behind a stable boundary |\n\nThis distinction prevents concepts such as MCP, connectors, capabilities, workflows, and execution from being merged incorrectly.\n\n---\n\n# 3. Canonical Architecture Core Inventory\n\n## Domain A — Trust, Identity, Tenancy, and Commercial Control\n\n### 01. Identity and Authentication Core\n\nOwns:\n\n- User authentication\n- Magic-link authentication\n- OTP step-up authentication\n- Passkeys\n- Enterprise SSO\n- Session issuance\n- Authentication assurance levels\n- Service identities\n- Machine identities\n- Token validation\n- Session revocation\n\nDoes not own provider connections or workspace permissions.\n\n---\n\n### 02. Tenancy and Workspace Context Core\n\nOwns:\n\n```text\nTenant\n→ Organisation\n→ Workspace\n→ Membership\n→ Role\n→ Context Lens\n→ Session Context\n```\n\nResponsibilities include:\n\n- Multi-tenant isolation\n- Organisation and workspace hierarchy\n- Membership\n- Workspace switching\n- RBAC\n- ABAC\n- Role resolution\n- Context-lens resolution\n- Tenant lifecycle\n- Workspace lifecycle\n- Regional placement\n- Tenant suspension\n- Tenant deletion\n- SCIM provisioning\n\nCanonical request context:\n\n```text\ntenantId\norganisationId\nworkspaceId\nuserId\nroleIds[]\ncontextLens\nsessionId\ncorrelationId\ncompiledConfigVersion\n```\n\n---\n\n### 03. One Auth-to-Ecosystem Core\n\nOwns the establishment of the workspace-level ecosystem trust relationship.\n\nIt includes:\n\n- Ecosystem connection establishment\n- Workspace trust grant\n- Delegated provider access\n- Connection-policy creation\n- Scope consent\n- Re-consent\n- Revocation\n- Connection ownership transfer\n- Trust-boundary enforcement\n\nIt does not replace third-party provider authorization where a provider legally or technically requires explicit consent. Instead, it minimizes repeated authentication by centralizing provider trust within the IntegrateWise workspace.\n\n---\n\n### 04. Policy, Consent, and Trust Core\n\nOwns:\n\n- Workspace policies\n- Connection policies\n- Data-access policies\n- Action policies\n- AI-use policies\n- Retention policies\n- Consent records\n- Data-processing constraints\n- Geographic constraints\n- Model-provider restrictions\n- Approval requirements\n- Destructive-operation restrictions\n- Policy versioning\n\nCanonical policy decision:\n\n```text\nActor\n+ Tenant\n+ Workspace\n+ Resource\n+ Capability\n+ Intended Action\n+ Data Classification\n+ Execution Mode\n+ Current Policy Version\n→ Permit | Deny | Require Approval\n```\n\n---\n\n### 05. Entitlement, Billing, and Usage Core\n\nOwns:\n\n- Product plans\n- Tenant entitlements\n- Feature access\n- Capability access\n- Connector limits\n- AI usage limits\n- Storage limits\n- Seat limits\n- Marketplace licensing\n- Trial lifecycle\n- Billing state\n- Usage metering\n- Quotas\n- Overage policy\n- Subscription suspension\n\nBilling determines commercial eligibility. Governance determines operational permission. These responsibilities must remain separate.\n\n---\n\n## Domain B — Activation and Configuration\n\n### 06. Marketplace Platform\n\nOwns:\n\n- AI marketplace packages\n- Tool marketplace packages\n- Connector marketplace listings\n- Discovery metadata\n- Installation\n- Workspace association\n- Tenant activation\n- Entitlement verification\n- Listing versioning\n- Review packages\n- Tool declarations\n- Privacy declarations\n- Revocation\n- Uninstallation\n- Publisher lifecycle\n\nMarketplace-facing packages may include:\n\n```text\nIW Spine Tools\nIW Continuity Fabric\nIW Capability Fabric\nIW One Auth-to-Ecosystem\n```\n\nThese are multiple entry surfaces into one governed IntegrateWise platform.\n\n---\n\n### 07. Plugin and Extension Runtime\n\nOwns:\n\n- Plugin packaging\n- Plugin registration\n- Plugin loading\n- Isolation\n- Extension points\n- Tool extensions\n- UI extensions\n- Tenant enablement\n- Compatibility checks\n- Version negotiation\n- Plugin security controls\n- Plugin upgrade\n- Plugin removal\n- Uninstall cleanup\n\nMarketplace publication and plugin execution are separate architectural concerns.\n\n---\n\n### 08. Onboarding Core\n\nOwns the collection of initial user and workspace intent.\n\nIt captures:\n\n- User profile\n- Organisation information\n- Workspace purpose\n- Role\n- Desired outcomes\n- Marketplace-entry context\n- Initial provider\n- Initial capabilities\n- Data requirements\n- Governance preferences\n- Operational priorities\n\nOnboarding gathers intent. It does not directly provision the runtime.\n\n---\n\n### 09. Configuration Manager\n\nOwns the conversion of intent into a validated platform configuration.\n\nIt includes:\n\n- Configuration definitions\n- Configuration templates\n- Tenant overrides\n- Environment overrides\n- Configuration validation\n- Configuration compilation\n- Dependency resolution\n- Configuration versioning\n- Configuration promotion\n- Configuration rollback\n- Configuration drift detection\n\nCanonical lifecycle:\n\n```text\nIntent\n→ Draft Configuration\n→ Validate\n→ Resolve Dependencies\n→ Compile\n→ Approve\n→ Activate\n→ Observe\n→ Revise\n```\n\n---\n\n### 10. Activation Hub\n\nOwns the projection and coordination of platform activation.\n\nIt manages:\n\n- Activation state\n- Activation checklist\n- Connection progress\n- Initial hydration state\n- Capability-discovery state\n- Configuration state\n- Policy state\n- First-value milestones\n- Activation failures\n- Activation recovery\n\nCanonical activation flow:\n\n```text\nDiscovery\n→ Marketplace Install or Direct Signup\n→ Authenticate\n→ Establish Tenant and Workspace\n→ Capture Intent\n→ Compile Configuration\n→ Establish Ecosystem Trust\n→ Connect Initial Provider\n→ Discover Provider Capabilities\n→ Discover Schemas\n→ Start Instant Hydration\n→ Build Initial Spine Records\n→ Generate Initial Projections\n→ Activate Initial Capabilities\n→ Present First Operational Value\n→ Continue Operational Hydration\n→ Begin Deep Hydration\n→ Enter Operational Plane\n```\n\nHydration tiers:\n\n```text\nInstant Hydration\nProfile + recent entities + active tasks\n\nOperational Hydration\nHistory + relationships + timelines + signals\n\nDeep Hydration\nArchives + documents + embeddings + full backfill\n```\n\n---\n\n## Domain C — Provider, Connector, and Integration Control\n\n### 11. Provider Management Core\n\nOwns:\n\n- Provider definitions\n- Provider capabilities\n- Provider API versions\n- OAuth applications\n- Provider connection metadata\n- Credential references\n- Token refresh\n- Connection health\n- Scope state\n- Revocation\n- Rate-limit metadata\n- Webhook registration\n- Provider-specific constraints\n\nProvider credentials must be stored through managed secret references rather than embedded in integration records.\n\n---\n\n### 12. Connector Runtime\n\nOwns provider-specific transport execution.\n\nIt includes:\n\n- Native adapters\n- Nango adapters\n- MCP adapters\n- REST adapters\n- GraphQL adapters\n- Webhook adapters\n- Polling adapters\n- File-ingestion adapters\n- Provider request translation\n- Provider response translation\n- Rate-limit handling\n- Provider retry logic\n\nProvider-specific logic must remain behind connector adapters.\n\n---\n\n### 13. Integration Manager\n\nOwns the lifecycle of integrations established within a workspace.\n\nIt includes:\n\n- Integration creation\n- Integration enablement\n- Integration suspension\n- Synchronisation configuration\n- Scope configuration\n- Sync scheduling\n- Webhook subscription lifecycle\n- Cursor management\n- Incremental synchronisation\n- Backfill coordination\n- Integration health\n- Integration repair\n- Integration removal\n\nBoundary:\n\n```text\nProvider Management\n    Owns providers, credentials, and provider connections\n\nIntegration Manager\n    Owns workspace integration and synchronisation lifecycle\n\nConnector Runtime\n    Executes provider-specific transport\n\nData Pipeline\n    Processes provider payloads\n```\n\n---\n\n### 14. MCP Pool and MCP Governance Core\n\nOwns the governed exposure and discovery of MCP interfaces.\n\nIt includes:\n\n- Internal MCP servers\n- Marketplace-facing MCP servers\n- Tool discovery\n- Resource discovery\n- Prompt discovery\n- Tenant-scoped MCP sessions\n- Tool filtering\n- Scope enforcement\n- Tool annotations\n- Output schemas\n- Destructive-operation metadata\n- MCP versioning\n- MCP audit\n- MCP health\n- MCP routing\n\nPossible MCP domains include:\n\n```text\nProvider Management MCP\nIntegration Management MCP\nWorkspace MCP\nSpine MCP\nKnowledge MCP\nGovernance MCP\nCapability MCP\nContinuity MCP\nObservability MCP\nDeployment MCP\n```\n\nMCP is an interface protocol. It does not own the underlying business domains.\n\n---\n\n## Domain D — Schema, Ontology, and Data Processing\n\n### 15. Schema Manager and Schema AI Core\n\nOwns:\n\n- Provider schema discovery\n- Raw schema registry\n- Schema fingerprinting\n- Schema versioning\n- Schema change detection\n- Provider entity maps\n- Field mappings\n- Relationship mappings\n- Semantic mapping proposals\n- Schema AI synthesis\n- Human schema review\n- Mapping promotion\n- Mapping rollback\n- Schema drift handling\n\nCanonical schema lifecycle:\n\n```text\nDiscover\n→ Fingerprint\n→ Register\n→ Compare\n→ Map\n→ Infer\n→ Review\n→ Promote\n→ Monitor Drift\n→ Revise\n```\n\n---\n\n### 16. Business Ontology and Canonical Model Core\n\nOwns the meaning of canonical business data.\n\nIt defines:\n\n- Canonical entities\n- Canonical fields\n- Entity relationships\n- Work objects\n- Lifecycle semantics\n- Event semantics\n- Canonical identifiers\n- Cross-provider equivalence\n- Industry extensions\n- Tenant ontology extensions\n- Ontology versioning\n- Ontology compatibility\n\nExamples include:\n\n```text\nAccount\nContact\nOpportunity\nCase\nTask\nProject\nConversation\nMessage\nDocument\nInvoice\nContract\nEmployee\nSignal\nProposal\nApproval\nExecution\n```\n\nCanonical relationship:\n\n```text\nOntology defines meaning.\nSchema Manager maps provider structures to meaning.\nPipeline transforms and validates data.\nEntity Resolution determines identity.\nSpine persists canonical truth.\nProjection Engine assembles usable views.\n```\n\n---\n\n### 17. Data Pipeline\n\nOwns the deterministic processing of incoming and outgoing data.\n\nPipeline stages:\n\n```text\nLOAD\n→ PARSE\n→ VALIDATE\n→ NORMALIZE\n→ RESOLVE\n→ PROMOTE\n→ STORE\n→ PROJECT\n→ INDEX\n→ SIGNAL\n```\n\nIt includes:\n\n- Payload intake\n- Envelope validation\n- Parsing\n- Canonical transformation\n- Data validation\n- Quarantine\n- Dead-letter handling\n- Replay\n- Idempotency\n- Provenance attachment\n- Change-data generation\n- Pipeline metrics\n\nThe AI-oriented runtime may use the broader operational loop:\n\n```text\nLOAD\n→ NORMALIZE\n→ STORE\n→ THINK\n→ APPROVE\n→ ACT\n→ REPEAT\n```\n\nThe ingestion pipeline and AI operational loop must not be treated as the same sequence.\n\n---\n\n### 18. Entity Resolution Core\n\nOwns the determination of canonical identity.\n\nIt includes:\n\n- Identity matching\n- Duplicate detection\n- Probabilistic matching\n- Deterministic matching\n- Merge confidence\n- Relationship resolution\n- Source precedence\n- Survivorship rules\n- Contradiction detection\n- Canonical identifier assignment\n- Split\n- Merge\n- Unmerge\n- Resolution evidence\n\n---\n\n### 19. Promotion and Data Quality Core\n\nOwns decisions about what data becomes canonical.\n\nCanonical lifecycle:\n\n```text\nRaw\n→ Parsed\n→ Normalized\n→ Resolved\n→ Proposed\n→ Approved or Auto-Promoted\n→ Canonical\n```\n\nIt includes:\n\n- Promotion rules\n- Promotion queues\n- Manual review\n- Automatic promotion\n- Rejection\n- Rollback\n- Data-quality scoring\n- Completeness checks\n- Consistency checks\n- Freshness checks\n- Provenance verification\n- Contradiction queues\n- Data stewardship\n\nEntity Resolution determines identity. Promotion determines canonical acceptance.\n\n---\n\n### 20. Event Fabric\n\nOwns the standard movement of domain events between cores.\n\nIt includes:\n\n- Event envelopes\n- Event schemas\n- Event registry\n- Event versioning\n- Topic conventions\n- Correlation IDs\n- Causation IDs\n- Tenant context\n- Ordering guarantees\n- Delivery guarantees\n- Idempotency keys\n- Replay\n- Dead-letter queues\n- Event retention\n- Event observability\n\nCanonical event envelope:\n\n```text\neventId\neventType\neventVersion\ntenantId\nworkspaceId\nactorId\ncorrelationId\ncausationId\noccurredAt\nproducer\npayload\ndataClassification\n```\n\n---\n\n## Domain E — Spine, Knowledge, Memory, Search, and Projection\n\n### 21. Adaptive Spine Core\n\nOwns canonical operational truth.\n\nIt includes:\n\n- Canonical entities\n- Canonical relationships\n- Canonical activities\n- Operational state\n- Change history\n- Source provenance\n- Tenant isolation\n- Canonical mutation controls\n- Versioned records\n- Temporal state\n- Record lineage\n\nThe Spine does not own:\n\n- Provider authentication\n- AI inference\n- User-interface state\n- Workflow orchestration\n- Raw file storage\n- Notification delivery\n\nCritical invariant:\n\n```text\nNo AI model, Twin, agent, workflow, or Workbench writes directly\nto canonical Spine records.\n```\n\nAll writes pass through governed mutation contracts.\n\n---\n\n### 22. Artifact Fabric\n\nOwns binary and semi-structured content.\n\nIt includes:\n\n- Files\n- Attachments\n- Images\n- Email bodies\n- Message threads\n- Meeting transcripts\n- Audio\n- Video references\n- Exports\n- Reports\n- Provider object references\n- Content hashes\n- Storage lifecycle\n- Artifact retention\n- Artifact permissions\n\nArtifacts are stored separately from canonical operational records, with metadata and relationships maintained through the Spine.\n\n---\n\n### 23. Knowledge Platform\n\nOwns explicit organisational knowledge.\n\nIt includes:\n\n- Documents\n- Notes\n- Policies\n- Procedures\n- Playbooks\n- Manuals\n- Extracted knowledge\n- Knowledge relationships\n- Knowledge citations\n- Knowledge versions\n- Knowledge review\n- Knowledge publication\n- Knowledge expiry\n- Tenant knowledge bases\n\nKnowledge is explicit and referenceable. Memory is learned or promoted context.\n\n---\n\n### 24. Memory System\n\nOwns durable contextual memory.\n\nMemory classes:\n\n```text\nConversational Memory\nUser Memory\nWork Memory\nOrganisation Memory\nOperational Memory\nAgent Memory\n```\n\nMemory lifecycle:\n\n```text\nObserve\n→ Capture\n→ Triage\n→ Classify\n→ Scope\n→ Consolidate\n→ Promote\n→ Retrieve\n→ Reinforce\n→ Decay or Archive\n```\n\nIt includes:\n\n- Memory candidates\n- Scope assignment\n- Memory promotion\n- Contradiction resolution\n- Compaction\n- Retention\n- Provenance\n- Forgetting\n- Memory revocation\n- Model-switch continuity\n- Conversation-to-org-memory promotion\n\nThe Memory System does not become a competing source of operational truth.\n\n---\n\n### 25. Search Platform\n\nOwns governed retrieval across platform information.\n\nIt includes:\n\n- Structured search\n- Keyword search\n- Semantic search\n- AI search\n- Entity search\n- Relationship search\n- Knowledge search\n- Artifact search\n- Memory search\n- Permission-aware retrieval\n- Query understanding\n- Search indexing\n- Re-indexing\n- Ranking\n- Citation generation\n- Provenance\n- Search projections\n\nSearch may span multiple stores, but it must not expose storage implementations to consumers.\n\n---\n\n### 26. Projection Engine\n\nOwns the creation of governed read models.\n\nIt includes:\n\n- Workspace projections\n- Entity 360\n- Timeline\n- Role-specific projections\n- Context-lens projections\n- Context bundles\n- Intelligence attachments\n- Signal attachments\n- Action attachments\n- Approval attachments\n- Continuity-state projections\n- Search-result projections\n- Projection caching\n- Projection invalidation\n- Projection versioning\n\nCritical invariant:\n\n```text\nWorkbenches, Twin, agents, and marketplace surfaces consume\ngoverned projections rather than assembling arbitrary records\ndirectly from Spine storage.\n```\n\n---\n\n### 27. Entity 360 Assembler\n\nA Projection Engine module that combines:\n\n```text\nCanonical Entity\n+ Relationships\n+ Activities\n+ Knowledge\n+ Memory\n+ Signals\n+ Intelligence\n+ Tasks\n+ Proposals\n+ Approvals\n+ Executions\n+ Continuity State\n```\n\nThe Entity 360 is the primary governed contextual read path for the Twin.\n\n---\n\n### 28. Timeline Assembler\n\nA Projection Engine module that combines:\n\n```text\nProvider Events\n+ Canonical Changes\n+ User Activity\n+ System Activity\n+ Signals\n+ AI Proposals\n+ Approvals\n+ Executions\n+ Synchronisation Results\n+ Continuity Transitions\n```\n\n---\n\n## Domain F — Signals, Intelligence, Twin, Agents, and Orchestration\n\n### 29. Signal Engine\n\nOwns the interpretation of operational conditions.\n\nIt includes:\n\n- Signal definitions\n- Thresholds\n- Rule-based detection\n- AI-assisted detection\n- Change detection\n- Anomaly detection\n- Risk signals\n- Opportunity signals\n- SLA signals\n- Relationship signals\n- Confidence\n- Evidence\n- Signal correlation\n- Signal suppression\n- Signal expiry\n- Signal resolution\n\n```text\nSignal = interpreted operational condition\nNotification = delivery mechanism\n```\n\n---\n\n### 30. AI Gateway\n\nOwns transport to AI providers.\n\nIt includes:\n\n- Provider authentication\n- Request forwarding\n- Streaming\n- Provider-specific protocol translation\n- Rate limiting\n- Request logging\n- Redaction\n- Cost capture\n- Provider health\n- Transport fallback\n- Circuit breaking\n\nThe AI Gateway does not decide which model should be used.\n\n---\n\n### 31. AI Router and Model Control Plane\n\nOwns capability-to-model resolution.\n\nIt includes:\n\n- Model registry\n- Model capabilities\n- Tenant model policy\n- Routing rules\n- Cost policies\n- Quality policies\n- Latency policies\n- Model availability\n- Provider fallback\n- Evaluation scores\n- Tenant classes\n- Model deprecation\n- Model versioning\n\nCanonical division:\n\n```text\nHermes requests an AI capability.\nGovernance determines whether it is permitted.\nAI Router selects the implementation.\nAI Gateway performs provider transport.\n```\n\n---\n\n### 32. Intelligence Services\n\nOwn reusable AI capabilities.\n\nExamples include:\n\n- Classification\n- Extraction\n- Summarisation\n- Embedding\n- Retrieval augmentation\n- Reasoning\n- Recommendation\n- Forecasting\n- Explanation\n- Similarity\n- Ranking\n- Data enrichment\n- Schema synthesis\n- Signal interpretation\n\nEach intelligence capability must have:\n\n- Input schema\n- Output schema\n- Model requirements\n- Evaluation criteria\n- Data-classification policy\n- Cost controls\n- Fallback behaviour\n- Evidence requirements\n\n---\n\n### 33. Twin Runtime\n\nOwns the user-facing cognitive collaborator.\n\nIt includes:\n\n- Twin identity\n- Session continuity\n- Context requests\n- Conversation state\n- Silent-partner behaviour\n- User instruction interpretation\n- Proposal generation\n- Explanation\n- Handoff\n- Context retention\n- User feedback\n- Personalisation boundaries\n\nThe Twin may propose work but does not bypass Governance or Capability Fabric.\n\n---\n\n### 34. Hermes Orchestration Core\n\nOwns cross-domain orchestration between:\n\n- Twin\n- Intelligence Services\n- Agent Runtime\n- Workflow Engine\n- Governance\n- Capability Fabric\n- Continuity Fabric\n- Memory\n- Search\n- Communication\n\nCanonical boundaries:\n\n```text\nTwin\n    Cognitive collaborator\n\nHermes\n    Orchestration authority\n\nAI Router\n    Capability and model resolution\n\nAgent Runtime\n    Adaptive autonomous execution\n\nWorkflow Engine\n    Defined process execution\n\nContinuity Fabric\n    Durable coordination over time\n\nCapability Fabric\n    Authorised business operations\n```\n\n---\n\n### 35. Agent Runtime / ADK Runtime\n\nOwns agent execution.\n\nIt includes:\n\n- Agent definitions\n- Agent identities\n- Agent sessions\n- Agent plans\n- Agent tool access\n- Agent memory boundaries\n- Delegation\n- Multi-agent coordination\n- Sandboxing\n- Runtime limits\n- Checkpoints\n- Human intervention\n- Evidence collection\n- Failure recovery\n- Agent evaluation\n\nCritical invariants:\n\n```text\nNo agent writes directly to Spine.\n\nNo agent invokes destructive capabilities without a policy decision.\n\nEvery agent action must have an attributable tenant, identity,\npurpose, capability, and evidence trail.\n```\n\n---\n\n### 36. AI Evaluation and Feedback Core\n\nOwns:\n\n- Prompt evaluations\n- Model evaluations\n- Agent evaluations\n- Retrieval evaluations\n- Hallucination checks\n- Grounding checks\n- Human feedback\n- Outcome feedback\n- Quality scoring\n- Regression suites\n- Model comparison\n- Prompt versioning\n- Evaluation datasets\n- Production quality monitoring\n\nAI systems cannot be operationally governed without a formal evaluation core.\n\n---\n\n## Domain G — Governance, Capability, Workflow, Execution, and Continuity\n\n### 37. Governance and Approval Core\n\nOwns:\n\n- Policy evaluation\n- Proposal intake\n- Approval routing\n- Approval state\n- Reviewer assignment\n- Delegation\n- Separation of duties\n- Approval expiry\n- Rejection\n- Reconsideration\n- Emergency override\n- Evidence\n- Decision audit\n\nCanonical lifecycle:\n\n```text\nProposal\n→ Policy Evaluation\n→ Auto-Approve | Require Review | Deny\n→ Decision\n→ Execution Authorization\n→ Evidence Verification\n→ Closure\n```\n\n---\n\n### 38. Capability Registry\n\nOwns authoritative capability definitions.\n\nEach capability declares:\n\n- Capability ID\n- Business purpose\n- Input schema\n- Output schema\n- Provider implementations\n- Required scopes\n- Required policies\n- Governance classification\n- Execution modes\n- Destructive impact\n- Reversibility\n- Idempotency\n- Compensation support\n- Cost\n- Rate limits\n- Availability\n- Tenant enablement\n- Evidence requirements\n- Version\n- Deprecation state\n\nCapabilities must be presented as business abilities, not as raw connector operations.\n\n---\n\n### 39. Capability Fabric\n\nOwns the resolution and invocation of governed business capabilities.\n\nIt includes:\n\n- Capability discovery\n- Capability resolution\n- Provider implementation selection\n- Tenant capability enablement\n- Scope verification\n- Policy verification\n- Governance handoff\n- Invocation\n- Evidence capture\n- Result normalization\n- Failure normalization\n- Compensation invocation\n\nExecution modes:\n\n```text\nDirect Execution\nLocal-First Execution\nProposal Mode\n```\n\n---\n\n### 40. Task Runtime\n\nOwns accountable units of work.\n\nIt includes:\n\n- Task definitions\n- Task ownership\n- Task assignment\n- Task status\n- Task priority\n- Due dates\n- Dependencies\n- Evidence\n- Human tasks\n- Agent tasks\n- Workflow tasks\n- Escalation\n- Completion\n- Reopening\n\n---\n\n### 41. Workflow Engine\n\nOwns structured process execution.\n\nIt includes:\n\n- Workflow definitions\n- Workflow versions\n- Steps\n- Branches\n- Conditions\n- Delays\n- Human tasks\n- Agent tasks\n- Capability invocations\n- Subflows\n- Retry\n- Timeout\n- Compensation\n- Execution state\n- Workflow migration\n- Long-running workflows\n- Workflow evidence\n\nBoundary:\n\n```text\nTask\n    A unit of accountable work\n\nWorkflow\n    A structured sequence of work\n\nAgent\n    An adaptive executor\n\nCapability\n    An authorised business operation\n\nContinuity\n    Durable coordination across time\n```\n\n---\n\n### 42. Execution Runtime\n\nOwns the actual execution lifecycle after authorization.\n\nCanonical sequence:\n\n```text\nReceive Authorization\n→ Validate Preconditions\n→ Reserve Execution\n→ Resolve Capability\n→ Invoke Adapter\n→ Observe Result\n→ Persist Evidence\n→ Apply Compensation if Required\n→ Reconcile External and Internal State\n→ Close Execution\n```\n\nIt includes:\n\n- Idempotency\n- Execution leases\n- Timeout\n- Retry\n- Result normalization\n- Partial-failure handling\n- Compensation\n- Write-back\n- Execution evidence\n- Execution reconciliation\n\n---\n\n### 43. Continuity Fabric\n\nOwns durable operational coordination beyond an active user or AI session.\n\nIt includes:\n\n- Continuity Scheduler\n- Continuity State Manager\n- Event Evaluator\n- Playbook Coordinator\n- Retry and Recovery Engine\n- Execution Monitor\n- Escalation Manager\n- Closure Manager\n- Long-running state\n- Scheduled continuation\n- Condition-based continuation\n- Failure recovery\n- Reconciliation\n\nCanonical continuity lifecycle:\n\n```text\nObserve\n→ Orient\n→ Decide\n→ Authorize\n→ Schedule\n→ Execute\n→ Monitor\n→ Retry or Escalate\n→ Reconcile\n→ Close\n→ Learn\n```\n\nContinuity does not replace workflow, agents, tasks, or capabilities. It ensures they remain coordinated over time.\n\n---\n\n### 44. Notification and Communication Fabric\n\nOwns delivery of operational information.\n\nIt includes:\n\n- In-app notifications\n- Email\n- Slack\n- Microsoft Teams\n- Approval requests\n- Escalations\n- Digests\n- User-to-agent communication\n- Agent-to-user communication\n- Agent-to-agent communication\n- Delivery preferences\n- Delivery state\n- Read state\n- Acknowledgement\n- Deduplication\n- Communication audit\n\n---\n\n### 45. Audit and Evidence Core\n\nOwns immutable operational accountability.\n\nIt records:\n\n- Actor\n- Tenant\n- Workspace\n- Policy\n- Proposal\n- Approval\n- Capability\n- Execution\n- Input references\n- Output references\n- External-system result\n- Data lineage\n- Model invocation\n- Human intervention\n- Timestamp\n- Correlation\n- Causation\n- Evidence integrity\n\nAudit logging and application observability must remain separate. Audit records prove what occurred; observability helps operate the system.\n\n---\n\n## Domain H — Experience and Projection Surfaces\n\n### 46. Workspace Shell\n\nOwns:\n\n- Tenant and workspace navigation\n- Context propagation\n- Role-aware navigation\n- Global search\n- Notifications\n- Awareness Drawer\n- Twin entry\n- Approval entry\n- Shared design-system application\n- Cross-workbench handoff\n- Session restoration\n\n---\n\n### 47. User Workbench\n\nOwns the primary human operational surface.\n\nIt includes:\n\n- Role-aware work views\n- Domain lenses\n- Industry lenses\n- Entity 360\n- Timelines\n- Tasks\n- Signals\n- Knowledge\n- Actions\n- Twin handoff\n- Personal and work context\n- Projection-based rendering\n\nThe Workbench must not perform direct provider reads or contain canonical business logic.\n\n---\n\n### 48. Awareness and Signal Surface\n\nOwns the contextual surfacing of relevant signals.\n\nIt includes:\n\n- Role-based thresholds\n- Signal ranking\n- Signal suppression\n- Evidence preview\n- Context handoff\n- Twin handoff\n- Governance handoff\n- Action handoff\n\n---\n\n### 49. AI / Twin Workbench\n\nOwns:\n\n- Conversational interaction\n- Context display\n- Evidence display\n- Citations\n- Proposal review\n- Agent status\n- Workflow status\n- Handoff between conversation and operational work\n- Session restoration\n\n---\n\n### 50. Governance Workbench\n\nOwns:\n\n- Approval queues\n- Proposal review\n- Policy evidence\n- Risk display\n- Impact display\n- Decision capture\n- Delegation\n- Overrides\n- Execution tracking\n- Audit inspection\n\n---\n\n### 51. Knowledge and Memory Workbench\n\nOwns:\n\n- Knowledge discovery\n- Memory triage\n- Memory promotion\n- Contradiction review\n- Knowledge editing\n- Citation inspection\n- Retention controls\n- Organisation-memory governance\n\n---\n\n### 52. Administration Workbench\n\nOwns administrative projections and actions for:\n\n- Users\n- Roles\n- Policies\n- Connections\n- Integrations\n- Capabilities\n- Models\n- Billing\n- Usage\n- Audit\n- Retention\n- Marketplace installations\n- Plugins\n- Tenant operations\n\n---\n\n### 53. Projection Registry and Design System\n\nOwns the definition of reusable experience projections.\n\nIt includes:\n\n- Projection manifests\n- Workspace manifests\n- Domain-lens manifests\n- Role-lens manifests\n- Capability attachments\n- Design tokens\n- Paper and Forest theme\n- SPINE visual language\n- Accessibility\n- Responsive behaviour\n- Component contracts\n- Frontend compatibility\n\nFrontends remain replaceable projections over stable platform contracts.\n\n---\n\n## Domain I — Platform Access, Operations, and Reliability\n\n### 54. API Gateway and Endpoint Registry\n\nOwns:\n\n- External API routing\n- Internal API routing\n- Authentication enforcement\n- Tenant-context enforcement\n- Rate limiting\n- Version routing\n- Endpoint discovery\n- Endpoint registration\n- Endpoint health\n- Deprecation\n- Contract metadata\n- Service bindings\n- API observability\n\nThe Endpoint Registry is a living platform contract, not a static document.\n\n---\n\n### 55. Developer Platform and SDK Core\n\nOwns:\n\n- TypeScript SDK\n- API clients\n- MCP client helpers\n- Capability SDK\n- Connector SDK\n- Plugin SDK\n- Webhook SDK\n- Schema definitions\n- Test harnesses\n- Local development\n- Sandbox tenants\n- Mock providers\n- Contract testing\n- Developer documentation\n\n---\n\n### 56. Secrets and Key Management Core\n\nOwns:\n\n- Secret references\n- Encryption keys\n- Provider secrets\n- Rotation\n- Revocation\n- Environment separation\n- Access policies\n- Secret audit\n- Tenant-managed keys where supported\n- Signing keys\n- Token-signing rotation\n\nNo application domain may manage raw secrets independently.\n\n---\n\n### 57. Observability Platform\n\nOwns:\n\n- Logs\n- Metrics\n- Traces\n- Correlation\n- Service health\n- Queue health\n- Provider health\n- AI-provider health\n- Integration health\n- Pipeline health\n- SLOs\n- Error budgets\n- Alerts\n- Operational dashboards\n- Incident context\n\n---\n\n### 58. Reliability, Recovery, and Disaster Management Core\n\nOwns:\n\n- Backup\n- Restore\n- Queue replay\n- Event replay\n- Data reconciliation\n- Regional recovery\n- Dependency outage handling\n- Provider outage handling\n- Circuit breakers\n- Degraded modes\n- Recovery point objectives\n- Recovery time objectives\n- Disaster exercises\n- Tenant-specific recovery\n- Operational runbooks\n\n---\n\n### 59. Platform Administration and Control Plane\n\nOwns:\n\n- Tenant provisioning\n- Tenant suspension\n- Workspace administration\n- Service configuration\n- Feature flags\n- Environment controls\n- Rollout controls\n- Migration controls\n- Platform policies\n- Operational overrides\n- System status\n- Capacity controls\n- Administrative audit\n\n---\n\n### 60. Deployment and Infrastructure Core\n\nThe canonical product plane is Cloudflare-first and must not be documented as a mixed Supabase/Postgres product architecture.\n\nPrimary product-plane components:\n\n```text\nCloudflare Workers\nCloudflare D1\nCloudflare KV\nCloudflare R2\nCloudflare Vectorize\nCloudflare Queues\nCloudflare Durable Objects\nCloudflare AI Gateway\nCloudflare Workers AI\n```\n\nPermitted external dependencies may include:\n\n```text\nIdentity provider\nBilling provider\nProvider APIs\nExternal AI providers\nEmail/communication providers\nNango\nCustomer-controlled systems\nOptional local or VPS-hosted models\n```\n\nHostinger or another VPS may host Hermes experiments, local models, or operational tooling, but must not silently become a second canonical product data plane.\n\n---\n\n# 4. Canonical Cross-Core Runtime\n\n## Activation Plane\n\n```text\nMarketplace or Direct Entry\n→ Identity\n→ Tenant and Workspace Context\n→ Onboarding\n→ Configuration Compilation\n→ Policy and Consent\n→ One Auth-to-Ecosystem\n→ Provider Connection\n→ Integration Activation\n→ Schema Discovery\n→ Instant Hydration\n→ Spine Promotion\n→ Projection Generation\n→ Initial Capability Activation\n→ First Operational Value\n```\n\n## Operational Read Plane\n\n```text\nProvider Changes\n→ Connector Runtime\n→ Integration Manager\n→ Event Fabric\n→ Data Pipeline\n→ Schema Mapping\n→ Entity Resolution\n→ Promotion\n→ Spine\n→ Projection Engine\n→ Entity 360 / Timeline / Search\n→ Workbench or Twin\n```\n\n## Governed Intelligence Plane\n\n```text\nProjection or Signal\n→ Hermes\n→ Context Bundle\n→ Intelligence Capability\n→ AI Router\n→ AI Gateway\n→ Model\n→ Grounded Result\n→ Proposal\n→ Governance\n```\n\n## Governed Action Plane\n\n```text\nApproved Proposal or User Instruction\n→ Governance Decision\n→ Capability Fabric\n→ Execution Runtime\n→ Connector Adapter\n→ External System\n→ Result\n→ Evidence\n→ Spine Reconciliation\n→ Projection Refresh\n```\n\n## Continuity Plane\n\n```text\nSchedule or Condition\n→ Continuity Fabric\n→ Evaluate State\n→ Hermes / Workflow / Agent / Task\n→ Governance\n→ Capability Execution\n→ Monitor\n→ Retry or Escalate\n→ Reconcile\n→ Close\n→ Learn\n```\n\n---\n\n# 5. Top-Level Structural Architecture\n\n```text\n┌──────────────────────────────────────────────────────────────┐\n│ EXPERIENCE AND PROJECTION SURFACES                           │\n│ Workspace Shell │ User │ Twin │ Governance │ Knowledge      │\n│ Administration │ Marketplace Surfaces                        │\n└──────────────────────────────┬───────────────────────────────┘\n                               │\n┌──────────────────────────────▼───────────────────────────────┐\n│ PROJECTION, SEARCH, SIGNAL, AND CONTEXT                       │\n│ Projection Engine │ Entity 360 │ Timeline │ Search │ Signals │\n└──────────────────────────────┬───────────────────────────────┘\n                               │\n┌──────────────────────────────▼───────────────────────────────┐\n│ GOVERNED INTELLIGENCE AND ORCHESTRATION                       │\n│ Twin │ Hermes │ Agent Runtime │ Intelligence │ AI Router     │\n│ AI Gateway │ Evaluation                                        │\n└──────────────────────────────┬───────────────────────────────┘\n                               │\n┌──────────────────────────────▼───────────────────────────────┐\n│ GOVERNANCE, CAPABILITY, EXECUTION, AND CONTINUITY             │\n│ Governance │ Capability Fabric │ Workflow │ Task │ Execution │\n│ Continuity Fabric │ Communication │ Audit                    │\n└──────────────────────────────┬───────────────────────────────┘\n                               │\n┌──────────────────────────────▼───────────────────────────────┐\n│ SPINE, KNOWLEDGE, MEMORY, AND ARTIFACTS                       │\n│ Adaptive Spine │ Knowledge │ Memory │ Artifact Fabric        │\n└──────────────────────────────┬───────────────────────────────┘\n                               │\n┌──────────────────────────────▼───────────────────────────────┐\n│ DATA, SCHEMA, ONTOLOGY, AND EVENT PROCESSING                  │\n│ Ontology │ Schema AI │ Pipeline │ Resolution │ Promotion     │\n│ Event Fabric │ Data Quality                                  │\n└──────────────────────────────┬───────────────────────────────┘\n                               │\n┌──────────────────────────────▼───────────────────────────────┐\n│ PROVIDER, CONNECTOR, INTEGRATION, AND MCP                     │\n│ Provider Manager │ Integration Manager │ Connectors │ MCP    │\n└──────────────────────────────┬───────────────────────────────┘\n                               │\n┌──────────────────────────────▼───────────────────────────────┐\n│ ACTIVATION, TRUST, CONFIGURATION, AND COMMERCIAL CONTROL      │\n│ Identity │ Tenancy │ One Auth │ Policy │ Configuration       │\n│ Onboarding │ Activation │ Entitlements │ Marketplace         │\n└──────────────────────────────┬───────────────────────────────┘\n                               │\n┌──────────────────────────────▼───────────────────────────────┐\n│ PLATFORM AND OPERATIONS                                      │\n│ API Gateway │ Endpoint Registry │ Secrets │ Observability    │\n│ Reliability │ Administration │ Cloudflare Product Plane      │\n└──────────────────────────────┬───────────────────────────────┘\n                               │\n┌──────────────────────────────▼───────────────────────────────┐\n│ INFRASTRUCTURE                                               │\n│ Cloudflare Product Plane                                     │\n└──────────────────────────────────────────────────────────────┘\n```\n\n---\n\n# 6. Canonical Documentation Hierarchy\n\n```text\n00 — Architecture Doctrine\n\n01 — Architecture Kernel and Terminology\n     01.01 Canonical Vocabulary\n     01.02 Architecture Laws\n     01.03 Domain Classification\n     01.04 Naming Standards\n     01.05 Tenant Context Standard\n     01.06 Contract Standards\n\n02 — Trust and Commercial Control\n     02.01 Identity and Authentication\n     02.02 Tenancy and Workspace Context\n     02.03 One Auth-to-Ecosystem\n     02.04 Policy, Consent, and Trust\n     02.05 Entitlements, Billing, and Usage\n\n03 — Activation and Configuration\n     03.01 Marketplace Platform\n     03.02 Plugin Runtime\n     03.03 Onboarding\n     03.04 Configuration Manager\n     03.05 Activation Hub\n     03.06 Hydration Architecture\n\n04 — Provider and Integration\n     04.01 Provider Management\n     04.02 Connector Runtime\n     04.03 Integration Manager\n     04.04 MCP Pool and Governance\n\n05 — Schema, Ontology, and Data\n     05.01 Schema Manager\n     05.02 Schema AI\n     05.03 Business Ontology\n     05.04 Data Pipeline\n     05.05 Entity Resolution\n     05.06 Promotion and Data Quality\n     05.07 Event Fabric\n\n06 — Spine, Knowledge, and Context\n     06.01 Adaptive Spine\n     06.02 Artifact Fabric\n     06.03 Knowledge Platform\n     06.04 Memory System\n     06.05 Search Platform\n     06.06 Projection Engine\n     06.07 Entity 360\n     06.08 Timeline\n\n07 — Intelligence and Orchestration\n     07.01 Signal Engine\n     07.02 AI Gateway\n     07.03 AI Router and Model Control Plane\n     07.04 Intelligence Services\n     07.05 Twin Runtime\n     07.06 Hermes Orchestration\n     07.07 Agent Runtime\n     07.08 AI Evaluation and Feedback\n\n08 — Governance and Execution\n     08.01 Governance and Approval\n     08.02 Capability Registry\n     08.03 Capability Fabric\n     08.04 Task Runtime\n     08.05 Workflow Engine\n     08.06 Execution Runtime\n     08.07 Continuity Fabric\n     08.08 Notification and Communication\n     08.09 Audit and Evidence\n\n09 — Experience Architecture\n     09.01 Workspace Shell\n     09.02 User Workbench\n     09.03 Awareness Surface\n     09.04 Twin Workbench\n     09.05 Governance Workbench\n     09.06 Knowledge and Memory Workbench\n     09.07 Administration Workbench\n     09.08 Projection Registry\n     09.09 Design System\n\n10 — Platform and Operations\n     10.01 API Gateway\n     10.02 Endpoint Registry\n     10.03 Developer Platform\n     10.04 Secrets and Key Management\n     10.05 Observability\n     10.06 Reliability and Recovery\n     10.07 Platform Administration\n     10.08 Deployment Architecture\n\n11 — Cross-Core Contracts\n     11.01 API Contracts\n     11.02 Event Contracts\n     11.03 Queue Contracts\n     11.04 MCP Contracts\n     11.05 Capability Contracts\n     11.06 Projection Contracts\n     11.07 Context Contracts\n     11.08 Error Contracts\n\n12 — End-to-End Runtime\n     12.01 Activation Runtime\n     12.02 Ingestion Runtime\n     12.03 Read Runtime\n     12.04 Intelligence Runtime\n     12.05 Proposal and Approval Runtime\n     12.06 Action Runtime\n     12.07 Continuity Runtime\n     12.08 Recovery Runtime\n\n13 — Security, Privacy, and Governance\n\n14 — Customer and Marketplace Journeys\n\n15 — Failure, Recovery, and Reconciliation\n\n16 — Architecture Decision Records\n\n17 — Capability and Feature Coverage Matrix\n\n18 — Complete IntegrateWise Platform Architecture\n```\n\n---\n\n# 7. Core Specification Template\n\nEvery core must use the following canonical template.\n\n## A. Purpose\n\nWhy the core exists and which platform problem it owns.\n\n## B. Ownership Boundary\n\n- What it owns\n- What it does not own\n- Adjacent owners\n- Forbidden responsibilities\n\n## C. Internal Components\n\nAll modules inside the core and their responsibilities.\n\n## D. Data Model\n\n- Entities\n- Identifiers\n- Relationships\n- State machines\n- Tenant boundaries\n- Retention\n- Versioning\n\n## E. Inputs and Outputs\n\nAll accepted inputs and emitted outputs.\n\n## F. Contracts\n\nFor every API, event, queue, MCP tool, capability, or projection:\n\n- Producer\n- Consumer\n- Schema\n- Authentication\n- Tenant context\n- Authorization\n- Idempotency\n- Retry\n- Errors\n- Versioning\n\n## G. Runtime Lifecycle\n\nThe full internal processing sequence.\n\n## H. Security and Governance\n\n- Authentication\n- Authorization\n- Policy evaluation\n- Approval\n- Data isolation\n- Audit\n- Revocation\n- Destructive actions\n\n## I. Failure Model\n\n- Invalid input\n- Duplicate delivery\n- Dependency failure\n- Timeout\n- Partial success\n- Rate limiting\n- Policy denial\n- Approval rejection\n- Schema mismatch\n- Tenant suspension\n- Recovery and reconciliation\n\n## J. Deployment and Operations\n\n- Runtime\n- Deployment unit\n- Storage\n- Queues\n- Bindings\n- Scaling\n- Configuration\n- Health\n- Metrics\n- Logs\n- Traces\n- Alerts\n- Recovery\n\n## K. Invariants\n\nRules that cannot be violated.\n\n## L. Acceptance Tests\n\nObservable conditions proving that the core satisfies its architecture.\n\n## M. Open Decisions\n\nExplicit unresolved decisions that must not be silently implemented.\n\n---\n\n# 8. Final Governing Rules\n\n```text\nRULE-1:\nA core cannot appear in the top-level architecture until its\nownership, contracts, data model, lifecycle, security, failure\nmodel, deployment model, and invariants are documented.\n\nRULE-2:\nNo top-level diagram may introduce hidden responsibilities.\n\nRULE-3:\nNo Workbench, Twin, agent, or model may access provider systems\nor canonical stores outside governed platform contracts.\n\nRULE-4:\nNo agent or AI model may write directly to the Adaptive Spine.\n\nRULE-5:\nEvery operation must be attributable to a tenant, workspace,\nactor, policy, capability, execution, and evidence record.\n\nRULE-6:\nProvider-specific logic must remain behind adapters.\n\nRULE-7:\nOntology defines meaning; Schema Manager defines mapping;\nEntity Resolution defines identity; Promotion defines acceptance;\nSpine defines canonical persistence.\n\nRULE-8:\nSignals, notifications, tasks, workflows, agents, capabilities,\nexecutions, and continuity are separate architectural concepts.\n\nRULE-9:\nFrontends are replaceable projections over stable platform contracts.\n\nRULE-10:\nThe Cloudflare product plane remains canonical. External compute\nmust not become an undocumented competing source of truth.\n\nRULE-11:\nCanonical truth is deterministic and customer-owned.\nAI outputs remain proposals, interpretations, or governed evidence\nuntil accepted through defined platform contracts.\n\nRULE-12:\nThe complete architecture is a composition of validated cores,\nnot a collection of conceptual boxes.\n```\n"}