Unclassified

IntegrateWise Architecture Documentation Plan

1. Governing Documentation Principle

IntegrateWise must be documented bottom-up.

No 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.

The required sequence is:

Architecture Doctrine
        ↓
Architecture Kernel and Terminology
        ↓
Independent Core Specifications
        ↓
Core Contracts and Boundaries
        ↓
Cross-Core Interaction Specifications
        ↓
Runtime Sequences
        ↓
Deployment and Operational Architecture
        ↓
Customer and Marketplace Journeys
        ↓
Complete Platform Architecture

A core is considered architecturally defined only when its:

Purpose
Ownership boundary
Internal components
Data model
Inputs and outputs
Contracts
Runtime lifecycle
Security model
Failure model
Deployment model
Observability
Invariants

have been documented.

2. Architectural Classification

Every IntegrateWise subsystem must be classified correctly.

Classification	Meaning
Platform	A broad domain containing multiple cores
Core	A subsystem with an explicit ownership boundary
Fabric	A distributed coordination layer spanning multiple cores
Engine	A system that transforms or evaluates inputs
Runtime	A system responsible for executing definitions
Registry	An authoritative catalogue of definitions or metadata
Manager	A lifecycle-management control plane
Workbench	A governed human-facing operational surface
Projection	A derived read model assembled from canonical sources
Adapter	A provider-specific implementation behind a stable boundary

This distinction prevents concepts such as MCP, connectors, capabilities, workflows, and execution from being merged incorrectly.

3. Canonical Architecture Core Inventory

Domain A — Trust, Identity, Tenancy, and Commercial Control

01. Identity and Authentication Core

Owns:

User authentication
Magic-link authentication
OTP step-up authentication
Passkeys
Enterprise SSO
Session issuance
Authentication assurance levels
Service identities
Machine identities
Token validation
Session revocation

Does not own provider connections or workspace permissions.

02. Tenancy and Workspace Context Core

Owns:

Tenant
→ Organisation
→ Workspace
→ Membership
→ Role
→ Context Lens
→ Session Context

Responsibilities include:

Multi-tenant isolation
Organisation and workspace hierarchy
Membership
Workspace switching
RBAC
ABAC
Role resolution
Context-lens resolution
Tenant lifecycle
Workspace lifecycle
Regional placement
Tenant suspension
Tenant deletion
SCIM provisioning

Canonical request context:

tenantId
organisationId
workspaceId
userId
roleIds[]
contextLens
sessionId
correlationId
compiledConfigVersion

03. One Auth-to-Ecosystem Core

Owns the establishment of the workspace-level ecosystem trust relationship.

It includes:

Ecosystem connection establishment
Workspace trust grant
Delegated provider access
Connection-policy creation
Scope consent
Re-consent
Revocation
Connection ownership transfer
Trust-boundary enforcement

It 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.

04. Policy, Consent, and Trust Core

Owns:

Workspace policies
Connection policies
Data-access policies
Action policies
AI-use policies
Retention policies
Consent records
Data-processing constraints
Geographic constraints
Model-provider restrictions
Approval requirements
Destructive-operation restrictions
Policy versioning

Canonical policy decision:

Actor
+ Tenant
+ Workspace
+ Resource
+ Capability
+ Intended Action
+ Data Classification
+ Execution Mode
+ Current Policy Version
→ Permit | Deny | Require Approval

05. Entitlement, Billing, and Usage Core

Owns:

Product plans
Tenant entitlements
Feature access
Capability access
Connector limits
AI usage limits
Storage limits
Seat limits
Marketplace licensing
Trial lifecycle
Billing state
Usage metering
Quotas
Overage policy
Subscription suspension

Billing determines commercial eligibility. Governance determines operational permission. These responsibilities must remain separate.

Domain B — Activation and Configuration

06. Marketplace Platform

Owns:

AI marketplace packages
Tool marketplace packages
Connector marketplace listings
Discovery metadata
Installation
Workspace association
Tenant activation
Entitlement verification
Listing versioning
Review packages
Tool declarations
Privacy declarations
Revocation
Uninstallation
Publisher lifecycle

Marketplace-facing packages may include:

IW Spine Tools
IW Continuity Fabric
IW Capability Fabric
IW One Auth-to-Ecosystem

These are multiple entry surfaces into one governed IntegrateWise platform.

07. Plugin and Extension Runtime

Owns:

Plugin packaging
Plugin registration
Plugin loading
Isolation
Extension points
Tool extensions
UI extensions
Tenant enablement
Compatibility checks
Version negotiation
Plugin security controls
Plugin upgrade
Plugin removal
Uninstall cleanup

Marketplace publication and plugin execution are separate architectural concerns.

08. Onboarding Core

Owns the collection of initial user and workspace intent.

It captures:

User profile
Organisation information
Workspace purpose
Role
Desired outcomes
Marketplace-entry context
Initial provider
Initial capabilities
Data requirements
Governance preferences
Operational priorities

Onboarding gathers intent. It does not directly provision the runtime.

09. Configuration Manager

Owns the conversion of intent into a validated platform configuration.

It includes:

Configuration definitions
Configuration templates
Tenant overrides
Environment overrides
Configuration validation
Configuration compilation
Dependency resolution
Configuration versioning
Configuration promotion
Configuration rollback
Configuration drift detection

Canonical lifecycle:

Intent
→ Draft Configuration
→ Validate
→ Resolve Dependencies
→ Compile
→ Approve
→ Activate
→ Observe
→ Revise

10. Activation Hub

Owns the projection and coordination of platform activation.

It manages:

Activation state
Activation checklist
Connection progress
Initial hydration state
Capability-discovery state
Configuration state
Policy state
First-value milestones
Activation failures
Activation recovery

Canonical activation flow:

Discovery
→ Marketplace Install or Direct Signup
→ Authenticate
→ Establish Tenant and Workspace
→ Capture Intent
→ Compile Configuration
→ Establish Ecosystem Trust
→ Connect Initial Provider
→ Discover Provider Capabilities
→ Discover Schemas
→ Start Instant Hydration
→ Build Initial Spine Records
→ Generate Initial Projections
→ Activate Initial Capabilities
→ Present First Operational Value
→ Continue Operational Hydration
→ Begin Deep Hydration
→ Enter Operational Plane

Hydration tiers:

Instant Hydration
Profile + recent entities + active tasks

Operational Hydration
History + relationships + timelines + signals

Deep Hydration
Archives + documents + embeddings + full backfill

Domain C — Provider, Connector, and Integration Control

11. Provider Management Core

Owns:

Provider definitions
Provider capabilities
Provider API versions
OAuth applications
Provider connection metadata
Credential references
Token refresh
Connection health
Scope state
Revocation
Rate-limit metadata
Webhook registration
Provider-specific constraints

Provider credentials must be stored through managed secret references rather than embedded in integration records.

12. Connector Runtime

Owns provider-specific transport execution.

It includes:

Native adapters
Nango adapters
MCP adapters
REST adapters
GraphQL adapters
Webhook adapters
Polling adapters
File-ingestion adapters
Provider request translation
Provider response translation
Rate-limit handling
Provider retry logic

Provider-specific logic must remain behind connector adapters.

13. Integration Manager

Owns the lifecycle of integrations established within a workspace.

It includes:

Integration creation
Integration enablement
Integration suspension
Synchronisation configuration
Scope configuration
Sync scheduling
Webhook subscription lifecycle
Cursor management
Incremental synchronisation
Backfill coordination
Integration health
Integration repair
Integration removal

Boundary:

Provider Management
    Owns providers, credentials, and provider connections

Integration Manager
    Owns workspace integration and synchronisation lifecycle

Connector Runtime
    Executes provider-specific transport

Data Pipeline
    Processes provider payloads

14. MCP Pool and MCP Governance Core

Owns the governed exposure and discovery of MCP interfaces.

It includes:

Internal MCP servers
Marketplace-facing MCP servers
Tool discovery
Resource discovery
Prompt discovery
Tenant-scoped MCP sessions
Tool filtering
Scope enforcement
Tool annotations
Output schemas
Destructive-operation metadata
MCP versioning
MCP audit
MCP health
MCP routing

Possible MCP domains include:

Provider Management MCP
Integration Management MCP
Workspace MCP
Spine MCP
Knowledge MCP
Governance MCP
Capability MCP
Continuity MCP
Observability MCP
Deployment MCP

MCP is an interface protocol. It does not own the underlying business domains.

Domain D — Schema, Ontology, and Data Processing

15. Schema Manager and Schema AI Core

Owns:

Provider schema discovery
Raw schema registry
Schema fingerprinting
Schema versioning
Schema change detection
Provider entity maps
Field mappings
Relationship mappings
Semantic mapping proposals
Schema AI synthesis
Human schema review
Mapping promotion
Mapping rollback
Schema drift handling

Canonical schema lifecycle:

Discover
→ Fingerprint
→ Register
→ Compare
→ Map
→ Infer
→ Review
→ Promote
→ Monitor Drift
→ Revise

16. Business Ontology and Canonical Model Core

Owns the meaning of canonical business data.

It defines:

Canonical entities
Canonical fields
Entity relationships
Work objects
Lifecycle semantics
Event semantics
Canonical identifiers
Cross-provider equivalence
Industry extensions
Tenant ontology extensions
Ontology versioning
Ontology compatibility

Examples include:

Account
Contact
Opportunity
Case
Task
Project
Conversation
Message
Document
Invoice
Contract
Employee
Signal
Proposal
Approval
Execution

Canonical relationship:

Ontology defines meaning.
Schema Manager maps provider structures to meaning.
Pipeline transforms and validates data.
Entity Resolution determines identity.
Spine persists canonical truth.
Projection Engine assembles usable views.

17. Data Pipeline

Owns the deterministic processing of incoming and outgoing data.

Pipeline stages:

LOAD
→ PARSE
→ VALIDATE
→ NORMALIZE
→ RESOLVE
→ PROMOTE
→ STORE
→ PROJECT
→ INDEX
→ SIGNAL

It includes:

Payload intake
Envelope validation
Parsing
Canonical transformation
Data validation
Quarantine
Dead-letter handling
Replay
Idempotency
Provenance attachment
Change-data generation
Pipeline metrics

The AI-oriented runtime may use the broader operational loop:

LOAD
→ NORMALIZE
→ STORE
→ THINK
→ APPROVE
→ ACT
→ REPEAT

The ingestion pipeline and AI operational loop must not be treated as the same sequence.

18. Entity Resolution Core

Owns the determination of canonical identity.

It includes:

Identity matching
Duplicate detection
Probabilistic matching
Deterministic matching
Merge confidence
Relationship resolution
Source precedence
Survivorship rules
Contradiction detection
Canonical identifier assignment
Split
Merge
Unmerge
Resolution evidence

19. Promotion and Data Quality Core

Owns decisions about what data becomes canonical.

Canonical lifecycle:

Raw
→ Parsed
→ Normalized
→ Resolved
→ Proposed
→ Approved or Auto-Promoted
→ Canonical

It includes:

Promotion rules
Promotion queues
Manual review
Automatic promotion
Rejection
Rollback
Data-quality scoring
Completeness checks
Consistency checks
Freshness checks
Provenance verification
Contradiction queues
Data stewardship

Entity Resolution determines identity. Promotion determines canonical acceptance.

20. Event Fabric

Owns the standard movement of domain events between cores.

It includes:

Event envelopes
Event schemas
Event registry
Event versioning
Topic conventions
Correlation IDs
Causation IDs
Tenant context
Ordering guarantees
Delivery guarantees
Idempotency keys
Replay
Dead-letter queues
Event retention
Event observability

Canonical event envelope:

eventId
eventType
eventVersion
tenantId
workspaceId
actorId
correlationId
causationId
occurredAt
producer
payload
dataClassification

Domain E — Spine, Knowledge, Memory, Search, and Projection

21. Adaptive Spine Core

Owns canonical operational truth.

It includes:

Canonical entities
Canonical relationships
Canonical activities
Operational state
Change history
Source provenance
Tenant isolation
Canonical mutation controls
Versioned records
Temporal state
Record lineage

The Spine does not own:

Provider authentication
AI inference
User-interface state
Workflow orchestration
Raw file storage
Notification delivery

Critical invariant:

No AI model, Twin, agent, workflow, or Workbench writes directly
to canonical Spine records.

All writes pass through governed mutation contracts.

22. Artifact Fabric

Owns binary and semi-structured content.

It includes:

Files
Attachments
Images
Email bodies
Message threads
Meeting transcripts
Audio
Video references
Exports
Reports
Provider object references
Content hashes
Storage lifecycle
Artifact retention
Artifact permissions

Artifacts are stored separately from canonical operational records, with metadata and relationships maintained through the Spine.

23. Knowledge Platform

Owns explicit organisational knowledge.

It includes:

Documents
Notes
Policies
Procedures
Playbooks
Manuals
Extracted knowledge
Knowledge relationships
Knowledge citations
Knowledge versions
Knowledge review
Knowledge publication
Knowledge expiry
Tenant knowledge bases

Knowledge is explicit and referenceable. Memory is learned or promoted context.

24. Memory System

Owns durable contextual memory.

Memory classes:

Conversational Memory
User Memory
Work Memory
Organisation Memory
Operational Memory
Agent Memory

Memory lifecycle:

Observe
→ Capture
→ Triage
→ Classify
→ Scope
→ Consolidate
→ Promote
→ Retrieve
→ Reinforce
→ Decay or Archive

It includes:

Memory candidates
Scope assignment
Memory promotion
Contradiction resolution
Compaction
Retention
Provenance
Forgetting
Memory revocation
Model-switch continuity
Conversation-to-org-memory promotion

The Memory System does not become a competing source of operational truth.

25. Search Platform

Owns governed retrieval across platform information.

It includes:

Structured search
Keyword search
Semantic search
AI search
Entity search
Relationship search
Knowledge search
Artifact search
Memory search
Permission-aware retrieval
Query understanding
Search indexing
Re-indexing
Ranking
Citation generation
Provenance
Search projections

Search may span multiple stores, but it must not expose storage implementations to consumers.

26. Projection Engine

Owns the creation of governed read models.

It includes:

Workspace projections
Entity 360
Timeline
Role-specific projections
Context-lens projections
Context bundles
Intelligence attachments
Signal attachments
Action attachments
Approval attachments
Continuity-state projections
Search-result projections
Projection caching
Projection invalidation
Projection versioning

Critical invariant:

Workbenches, Twin, agents, and marketplace surfaces consume
governed projections rather than assembling arbitrary records
directly from Spine storage.

27. Entity 360 Assembler

A Projection Engine module that combines:

Canonical Entity
+ Relationships
+ Activities
+ Knowledge
+ Memory
+ Signals
+ Intelligence
+ Tasks
+ Proposals
+ Approvals
+ Executions
+ Continuity State

The Entity 360 is the primary governed contextual read path for the Twin.

28. Timeline Assembler

A Projection Engine module that combines:

Provider Events
+ Canonical Changes
+ User Activity
+ System Activity
+ Signals
+ AI Proposals
+ Approvals
+ Executions
+ Synchronisation Results
+ Continuity Transitions

Domain F — Signals, Intelligence, Twin, Agents, and Orchestration

29. Signal Engine

Owns the interpretation of operational conditions.

It includes:

Signal definitions
Thresholds
Rule-based detection
AI-assisted detection
Change detection
Anomaly detection
Risk signals
Opportunity signals
SLA signals
Relationship signals
Confidence
Evidence
Signal correlation
Signal suppression
Signal expiry
Signal resolution

Signal = interpreted operational condition
Notification = delivery mechanism

30. AI Gateway

Owns transport to AI providers.

It includes:

Provider authentication
Request forwarding
Streaming
Provider-specific protocol translation
Rate limiting
Request logging
Redaction
Cost capture
Provider health
Transport fallback
Circuit breaking

The AI Gateway does not decide which model should be used.

31. AI Router and Model Control Plane

Owns capability-to-model resolution.

It includes:

Model registry
Model capabilities
Tenant model policy
Routing rules
Cost policies
Quality policies
Latency policies
Model availability
Provider fallback
Evaluation scores
Tenant classes
Model deprecation
Model versioning

Canonical division:

Hermes requests an AI capability.
Governance determines whether it is permitted.
AI Router selects the implementation.
AI Gateway performs provider transport.

32. Intelligence Services

Own reusable AI capabilities.

Examples include:

Classification
Extraction
Summarisation
Embedding
Retrieval augmentation
Reasoning
Recommendation
Forecasting
Explanation
Similarity
Ranking
Data enrichment
Schema synthesis
Signal interpretation

Each intelligence capability must have:

Input schema
Output schema
Model requirements
Evaluation criteria
Data-classification policy
Cost controls
Fallback behaviour
Evidence requirements

33. Twin Runtime

Owns the user-facing cognitive collaborator.

It includes:

Twin identity
Session continuity
Context requests
Conversation state
Silent-partner behaviour
User instruction interpretation
Proposal generation
Explanation
Handoff
Context retention
User feedback
Personalisation boundaries

The Twin may propose work but does not bypass Governance or Capability Fabric.

34. Hermes Orchestration Core

Owns cross-domain orchestration between:

Twin
Intelligence Services
Agent Runtime
Workflow Engine
Governance
Capability Fabric
Continuity Fabric
Memory
Search
Communication

Canonical boundaries:

Twin
    Cognitive collaborator

Hermes
    Orchestration authority

AI Router
    Capability and model resolution

Agent Runtime
    Adaptive autonomous execution

Workflow Engine
    Defined process execution

Continuity Fabric
    Durable coordination over time

Capability Fabric
    Authorised business operations

35. Agent Runtime / ADK Runtime

Owns agent execution.

It includes:

Agent definitions
Agent identities
Agent sessions
Agent plans
Agent tool access
Agent memory boundaries
Delegation
Multi-agent coordination
Sandboxing
Runtime limits
Checkpoints
Human intervention
Evidence collection
Failure recovery
Agent evaluation

Critical invariants:

No agent writes directly to Spine.

No agent invokes destructive capabilities without a policy decision.

Every agent action must have an attributable tenant, identity,
purpose, capability, and evidence trail.

36. AI Evaluation and Feedback Core

Owns:

Prompt evaluations
Model evaluations
Agent evaluations
Retrieval evaluations
Hallucination checks
Grounding checks
Human feedback
Outcome feedback
Quality scoring
Regression suites
Model comparison
Prompt versioning
Evaluation datasets
Production quality monitoring

AI systems cannot be operationally governed without a formal evaluation core.

Domain G — Governance, Capability, Workflow, Execution, and Continuity

37. Governance and Approval Core

Owns:

Policy evaluation
Proposal intake
Approval routing
Approval state
Reviewer assignment
Delegation
Separation of duties
Approval expiry
Rejection
Reconsideration
Emergency override
Evidence
Decision audit

Canonical lifecycle:

Proposal
→ Policy Evaluation
→ Auto-Approve | Require Review | Deny
→ Decision
→ Execution Authorization
→ Evidence Verification
→ Closure

38. Capability Registry

Owns authoritative capability definitions.

Each capability declares:

Capability ID
Business purpose
Input schema
Output schema
Provider implementations
Required scopes
Required policies
Governance classification
Execution modes
Destructive impact
Reversibility
Idempotency
Compensation support
Cost
Rate limits
Availability
Tenant enablement
Evidence requirements
Version
Deprecation state

Capabilities must be presented as business abilities, not as raw connector operations.

39. Capability Fabric

Owns the resolution and invocation of governed business capabilities.

It includes:

Capability discovery
Capability resolution
Provider implementation selection
Tenant capability enablement
Scope verification
Policy verification
Governance handoff
Invocation
Evidence capture
Result normalization
Failure normalization
Compensation invocation

Execution modes:

Direct Execution
Local-First Execution
Proposal Mode

40. Task Runtime

Owns accountable units of work.

It includes:

Task definitions
Task ownership
Task assignment
Task status
Task priority
Due dates
Dependencies
Evidence
Human tasks
Agent tasks
Workflow tasks
Escalation
Completion
Reopening

41. Workflow Engine

Owns structured process execution.

It includes:

Workflow definitions
Workflow versions
Steps
Branches
Conditions
Delays
Human tasks
Agent tasks
Capability invocations
Subflows
Retry
Timeout
Compensation
Execution state
Workflow migration
Long-running workflows
Workflow evidence

Boundary:

Task
    A unit of accountable work

Workflow
    A structured sequence of work

Agent
    An adaptive executor

Capability
    An authorised business operation

Continuity
    Durable coordination across time

42. Execution Runtime

Owns the actual execution lifecycle after authorization.

Canonical sequence:

Receive Authorization
→ Validate Preconditions
→ Reserve Execution
→ Resolve Capability
→ Invoke Adapter
→ Observe Result
→ Persist Evidence
→ Apply Compensation if Required
→ Reconcile External and Internal State
→ Close Execution

It includes:

Idempotency
Execution leases
Timeout
Retry
Result normalization
Partial-failure handling
Compensation
Write-back
Execution evidence
Execution reconciliation

43. Continuity Fabric

Owns durable operational coordination beyond an active user or AI session.

It includes:

Continuity Scheduler
Continuity State Manager
Event Evaluator
Playbook Coordinator
Retry and Recovery Engine
Execution Monitor
Escalation Manager
Closure Manager
Long-running state
Scheduled continuation
Condition-based continuation
Failure recovery
Reconciliation

Canonical continuity lifecycle:

Observe
→ Orient
→ Decide
→ Authorize
→ Schedule
→ Execute
→ Monitor
→ Retry or Escalate
→ Reconcile
→ Close
→ Learn

Continuity does not replace workflow, agents, tasks, or capabilities. It ensures they remain coordinated over time.

44. Notification and Communication Fabric

Owns delivery of operational information.

It includes:

In-app notifications
Email
Slack
Microsoft Teams
Approval requests
Escalations
Digests
User-to-agent communication
Agent-to-user communication
Agent-to-agent communication
Delivery preferences
Delivery state
Read state
Acknowledgement
Deduplication
Communication audit

45. Audit and Evidence Core

Owns immutable operational accountability.

It records:

Actor
Tenant
Workspace
Policy
Proposal
Approval
Capability
Execution
Input references
Output references
External-system result
Data lineage
Model invocation
Human intervention
Timestamp
Correlation
Causation
Evidence integrity

Audit logging and application observability must remain separate. Audit records prove what occurred; observability helps operate the system.

Domain H — Experience and Projection Surfaces

46. Workspace Shell

Owns:

Tenant and workspace navigation
Context propagation
Role-aware navigation
Global search
Notifications
Awareness Drawer
Twin entry
Approval entry
Shared design-system application
Cross-workbench handoff
Session restoration

47. User Workbench

Owns the primary human operational surface.

It includes:

Role-aware work views
Domain lenses
Industry lenses
Entity 360
Timelines
Tasks
Signals
Knowledge
Actions
Twin handoff
Personal and work context
Projection-based rendering

The Workbench must not perform direct provider reads or contain canonical business logic.

48. Awareness and Signal Surface

Owns the contextual surfacing of relevant signals.

It includes:

Role-based thresholds
Signal ranking
Signal suppression
Evidence preview
Context handoff
Twin handoff
Governance handoff
Action handoff

49. AI / Twin Workbench

Owns:

Conversational interaction
Context display
Evidence display
Citations
Proposal review
Agent status
Workflow status
Handoff between conversation and operational work
Session restoration

50. Governance Workbench

Owns:

Approval queues
Proposal review
Policy evidence
Risk display
Impact display
Decision capture
Delegation
Overrides
Execution tracking
Audit inspection

51. Knowledge and Memory Workbench

Owns:

Knowledge discovery
Memory triage
Memory promotion
Contradiction review
Knowledge editing
Citation inspection
Retention controls
Organisation-memory governance

52. Administration Workbench

Owns administrative projections and actions for:

Users
Roles
Policies
Connections
Integrations
Capabilities
Models
Billing
Usage
Audit
Retention
Marketplace installations
Plugins
Tenant operations

53. Projection Registry and Design System

Owns the definition of reusable experience projections.

It includes:

Projection manifests
Workspace manifests
Domain-lens manifests
Role-lens manifests
Capability attachments
Design tokens
Paper and Forest theme
SPINE visual language
Accessibility
Responsive behaviour
Component contracts
Frontend compatibility

Frontends remain replaceable projections over stable platform contracts.

Domain I — Platform Access, Operations, and Reliability

54. API Gateway and Endpoint Registry

Owns:

External API routing
Internal API routing
Authentication enforcement
Tenant-context enforcement
Rate limiting
Version routing
Endpoint discovery
Endpoint registration
Endpoint health
Deprecation
Contract metadata
Service bindings
API observability

The Endpoint Registry is a living platform contract, not a static document.

55. Developer Platform and SDK Core

Owns:

TypeScript SDK
API clients
MCP client helpers
Capability SDK
Connector SDK
Plugin SDK
Webhook SDK
Schema definitions
Test harnesses
Local development
Sandbox tenants
Mock providers
Contract testing
Developer documentation

56. Secrets and Key Management Core

Owns:

Secret references
Encryption keys
Provider secrets
Rotation
Revocation
Environment separation
Access policies
Secret audit
Tenant-managed keys where supported
Signing keys
Token-signing rotation

No application domain may manage raw secrets independently.

57. Observability Platform

Owns:

Logs
Metrics
Traces
Correlation
Service health
Queue health
Provider health
AI-provider health
Integration health
Pipeline health
SLOs
Error budgets
Alerts
Operational dashboards
Incident context

58. Reliability, Recovery, and Disaster Management Core

Owns:

Backup
Restore
Queue replay
Event replay
Data reconciliation
Regional recovery
Dependency outage handling
Provider outage handling
Circuit breakers
Degraded modes
Recovery point objectives
Recovery time objectives
Disaster exercises
Tenant-specific recovery
Operational runbooks

59. Platform Administration and Control Plane

Owns:

Tenant provisioning
Tenant suspension
Workspace administration
Service configuration
Feature flags
Environment controls
Rollout controls
Migration controls
Platform policies
Operational overrides
System status
Capacity controls
Administrative audit

60. Deployment and Infrastructure Core

The canonical product plane is Cloudflare-first and must not be documented as a mixed Supabase/Postgres product architecture.

Primary product-plane components:

Cloudflare Workers
Cloudflare D1
Cloudflare KV
Cloudflare R2
Cloudflare Vectorize
Cloudflare Queues
Cloudflare Durable Objects
Cloudflare AI Gateway
Cloudflare Workers AI

Permitted external dependencies may include:

Identity provider
Billing provider
Provider APIs
External AI providers
Email/communication providers
Nango
Customer-controlled systems
Optional local or VPS-hosted models

Hostinger or another VPS may host Hermes experiments, local models, or operational tooling, but must not silently become a second canonical product data plane.

4. Canonical Cross-Core Runtime

Activation Plane

Marketplace or Direct Entry
→ Identity
→ Tenant and Workspace Context
→ Onboarding
→ Configuration Compilation
→ Policy and Consent
→ One Auth-to-Ecosystem
→ Provider Connection
→ Integration Activation
→ Schema Discovery
→ Instant Hydration
→ Spine Promotion
→ Projection Generation
→ Initial Capability Activation
→ First Operational Value

Operational Read Plane

Provider Changes
→ Connector Runtime
→ Integration Manager
→ Event Fabric
→ Data Pipeline
→ Schema Mapping
→ Entity Resolution
→ Promotion
→ Spine
→ Projection Engine
→ Entity 360 / Timeline / Search
→ Workbench or Twin

Governed Intelligence Plane

Projection or Signal
→ Hermes
→ Context Bundle
→ Intelligence Capability
→ AI Router
→ AI Gateway
→ Model
→ Grounded Result
→ Proposal
→ Governance

Governed Action Plane

Approved Proposal or User Instruction
→ Governance Decision
→ Capability Fabric
→ Execution Runtime
→ Connector Adapter
→ External System
→ Result
→ Evidence
→ Spine Reconciliation
→ Projection Refresh

Continuity Plane

Schedule or Condition
→ Continuity Fabric
→ Evaluate State
→ Hermes / Workflow / Agent / Task
→ Governance
→ Capability Execution
→ Monitor
→ Retry or Escalate
→ Reconcile
→ Close
→ Learn

5. Top-Level Structural Architecture

┌──────────────────────────────────────────────────────────────┐
│ EXPERIENCE AND PROJECTION SURFACES                           │
│ Workspace Shell │ User │ Twin │ Governance │ Knowledge      │
│ Administration │ Marketplace Surfaces                        │
└──────────────────────────────┬───────────────────────────────┘
                               │
┌──────────────────────────────▼───────────────────────────────┐
│ PROJECTION, SEARCH, SIGNAL, AND CONTEXT                       │
│ Projection Engine │ Entity 360 │ Timeline │ Search │ Signals │
└──────────────────────────────┬───────────────────────────────┘
                               │
┌──────────────────────────────▼───────────────────────────────┐
│ GOVERNED INTELLIGENCE AND ORCHESTRATION                       │
│ Twin │ Hermes │ Agent Runtime │ Intelligence │ AI Router     │
│ AI Gateway │ Evaluation                                        │
└──────────────────────────────┬───────────────────────────────┘
                               │
┌──────────────────────────────▼───────────────────────────────┐
│ GOVERNANCE, CAPABILITY, EXECUTION, AND CONTINUITY             │
│ Governance │ Capability Fabric │ Workflow │ Task │ Execution │
│ Continuity Fabric │ Communication │ Audit                    │
└──────────────────────────────┬───────────────────────────────┘
                               │
┌──────────────────────────────▼───────────────────────────────┐
│ SPINE, KNOWLEDGE, MEMORY, AND ARTIFACTS                       │
│ Adaptive Spine │ Knowledge │ Memory │ Artifact Fabric        │
└──────────────────────────────┬───────────────────────────────┘
                               │
┌──────────────────────────────▼───────────────────────────────┐
│ DATA, SCHEMA, ONTOLOGY, AND EVENT PROCESSING                  │
│ Ontology │ Schema AI │ Pipeline │ Resolution │ Promotion     │
│ Event Fabric │ Data Quality                                  │
└──────────────────────────────┬───────────────────────────────┘
                               │
┌──────────────────────────────▼───────────────────────────────┐
│ PROVIDER, CONNECTOR, INTEGRATION, AND MCP                     │
│ Provider Manager │ Integration Manager │ Connectors │ MCP    │
└──────────────────────────────┬───────────────────────────────┘
                               │
┌──────────────────────────────▼───────────────────────────────┐
│ ACTIVATION, TRUST, CONFIGURATION, AND COMMERCIAL CONTROL      │
│ Identity │ Tenancy │ One Auth │ Policy │ Configuration       │
│ Onboarding │ Activation │ Entitlements │ Marketplace         │
└──────────────────────────────┬───────────────────────────────┘
                               │
┌──────────────────────────────▼───────────────────────────────┐
│ PLATFORM AND OPERATIONS                                      │
│ API Gateway │ Endpoint Registry │ Secrets │ Observability    │
│ Reliability │ Administration │ Cloudflare Product Plane      │
└──────────────────────────────┬───────────────────────────────┘
                               │
┌──────────────────────────────▼───────────────────────────────┐
│ INFRASTRUCTURE                                               │
│ Cloudflare Product Plane                                     │
└──────────────────────────────────────────────────────────────┘

6. Canonical Documentation Hierarchy

00 — Architecture Doctrine

01 — Architecture Kernel and Terminology
     01.01 Canonical Vocabulary
     01.02 Architecture Laws
     01.03 Domain Classification
     01.04 Naming Standards
     01.05 Tenant Context Standard
     01.06 Contract Standards

02 — Trust and Commercial Control
     02.01 Identity and Authentication
     02.02 Tenancy and Workspace Context
     02.03 One Auth-to-Ecosystem
     02.04 Policy, Consent, and Trust
     02.05 Entitlements, Billing, and Usage

03 — Activation and Configuration
     03.01 Marketplace Platform
     03.02 Plugin Runtime
     03.03 Onboarding
     03.04 Configuration Manager
     03.05 Activation Hub
     03.06 Hydration Architecture

04 — Provider and Integration
     04.01 Provider Management
     04.02 Connector Runtime
     04.03 Integration Manager
     04.04 MCP Pool and Governance

05 — Schema, Ontology, and Data
     05.01 Schema Manager
     05.02 Schema AI
     05.03 Business Ontology
     05.04 Data Pipeline
     05.05 Entity Resolution
     05.06 Promotion and Data Quality
     05.07 Event Fabric

06 — Spine, Knowledge, and Context
     06.01 Adaptive Spine
     06.02 Artifact Fabric
     06.03 Knowledge Platform
     06.04 Memory System
     06.05 Search Platform
     06.06 Projection Engine
     06.07 Entity 360
     06.08 Timeline

07 — Intelligence and Orchestration
     07.01 Signal Engine
     07.02 AI Gateway
     07.03 AI Router and Model Control Plane
     07.04 Intelligence Services
     07.05 Twin Runtime
     07.06 Hermes Orchestration
     07.07 Agent Runtime
     07.08 AI Evaluation and Feedback

08 — Governance and Execution
     08.01 Governance and Approval
     08.02 Capability Registry
     08.03 Capability Fabric
     08.04 Task Runtime
     08.05 Workflow Engine
     08.06 Execution Runtime
     08.07 Continuity Fabric
     08.08 Notification and Communication
     08.09 Audit and Evidence

09 — Experience Architecture
     09.01 Workspace Shell
     09.02 User Workbench
     09.03 Awareness Surface
     09.04 Twin Workbench
     09.05 Governance Workbench
     09.06 Knowledge and Memory Workbench
     09.07 Administration Workbench
     09.08 Projection Registry
     09.09 Design System

10 — Platform and Operations
     10.01 API Gateway
     10.02 Endpoint Registry
     10.03 Developer Platform
     10.04 Secrets and Key Management
     10.05 Observability
     10.06 Reliability and Recovery
     10.07 Platform Administration
     10.08 Deployment Architecture

11 — Cross-Core Contracts
     11.01 API Contracts
     11.02 Event Contracts
     11.03 Queue Contracts
     11.04 MCP Contracts
     11.05 Capability Contracts
     11.06 Projection Contracts
     11.07 Context Contracts
     11.08 Error Contracts

12 — End-to-End Runtime
     12.01 Activation Runtime
     12.02 Ingestion Runtime
     12.03 Read Runtime
     12.04 Intelligence Runtime
     12.05 Proposal and Approval Runtime
     12.06 Action Runtime
     12.07 Continuity Runtime
     12.08 Recovery Runtime

13 — Security, Privacy, and Governance

14 — Customer and Marketplace Journeys

15 — Failure, Recovery, and Reconciliation

16 — Architecture Decision Records

17 — Capability and Feature Coverage Matrix

18 — Complete IntegrateWise Platform Architecture

7. Core Specification Template

Every core must use the following canonical template.

A. Purpose

Why the core exists and which platform problem it owns.

B. Ownership Boundary

What it owns
What it does not own
Adjacent owners
Forbidden responsibilities

C. Internal Components

All modules inside the core and their responsibilities.

D. Data Model

Entities
Identifiers
Relationships
State machines
Tenant boundaries
Retention
Versioning

E. Inputs and Outputs

All accepted inputs and emitted outputs.

F. Contracts

For every API, event, queue, MCP tool, capability, or projection:

Producer
Consumer
Schema
Authentication
Tenant context
Authorization
Idempotency
Retry
Errors
Versioning

G. Runtime Lifecycle

The full internal processing sequence.

H. Security and Governance

Authentication
Authorization
Policy evaluation
Approval
Data isolation
Audit
Revocation
Destructive actions

I. Failure Model

Invalid input
Duplicate delivery
Dependency failure
Timeout
Partial success
Rate limiting
Policy denial
Approval rejection
Schema mismatch
Tenant suspension
Recovery and reconciliation

J. Deployment and Operations

Runtime
Deployment unit
Storage
Queues
Bindings
Scaling
Configuration
Health
Metrics
Logs
Traces
Alerts
Recovery

K. Invariants

Rules that cannot be violated.

L. Acceptance Tests

Observable conditions proving that the core satisfies its architecture.

M. Open Decisions

Explicit unresolved decisions that must not be silently implemented.

8. Final Governing Rules

RULE-1:
A core cannot appear in the top-level architecture until its
ownership, contracts, data model, lifecycle, security, failure
model, deployment model, and invariants are documented.

RULE-2:
No top-level diagram may introduce hidden responsibilities.

RULE-3:
No Workbench, Twin, agent, or model may access provider systems
or canonical stores outside governed platform contracts.

RULE-4:
No agent or AI model may write directly to the Adaptive Spine.

RULE-5:
Every operation must be attributable to a tenant, workspace,
actor, policy, capability, execution, and evidence record.

RULE-6:
Provider-specific logic must remain behind adapters.

RULE-7:
Ontology defines meaning; Schema Manager defines mapping;
Entity Resolution defines identity; Promotion defines acceptance;
Spine defines canonical persistence.

RULE-8:
Signals, notifications, tasks, workflows, agents, capabilities,
executions, and continuity are separate architectural concepts.

RULE-9:
Frontends are replaceable projections over stable platform contracts.

RULE-10:
The Cloudflare product plane remains canonical. External compute
must not become an undocumented competing source of truth.

RULE-11:
Canonical truth is deterministic and customer-owned.
AI outputs remain proposals, interpretations, or governed evidence
until accepted through defined platform contracts.

RULE-12:
The complete architecture is a composition of validated cores,
not a collection of conceptual boxes.