4. Architectural Overview

This section describes the high-level structure of the architecture, focusing on how responsibilities are separated, how execution occurs, and how trust is maintained across boundaries. It intentionally distinguishes logical concerns from physical deployment choices.

4.1 Logical Architecture

At a logical level, the architecture is organised around capabilities, not systems.

The core logical layers are:

1. Experience Layer (DXP)
   • Responsible for user interaction, navigation, and presentation
   • Declares intent (what outcome is required), not execution logic
   • Does not contain business rules or integration logic
2. Capability Exposure Layer
   • Presents capabilities via stable, versioned contracts
   • Provides discovery, invocation metadata, and governance hooks
   • Exposes both deterministic and AI-assisted capabilities uniformly
3. Execution Layer
   • Resolves a capability invocation to a concrete executor
   • Selects deterministic or AI-assisted execution based on policy, context, and availability
   • Orchestrates execution without embedding domain semantics
4. Integration and Systems Layer
   • Contains existing systems, APIs, ESBs, data stores, and legacy platforms
   • Is accessed only through explicit capability execution paths
   • Remains isolated from the DXP and experience concerns

This separation ensures that:

• The DXP remains lightweight and change-tolerant
• Capabilities are reusable and independently evolvable
• Execution strategies can change without impacting consumers

4.2 Physical Architecture

Physically, the architecture is deployed as a set of independently scalable components.

Typical physical groupings include:

• DXP Runtime
  • Web and client-facing services
  • Stateless where possible
  • Scales with user demand
• Capability Gateway
  • Hosts MCP endpoints and capability metadata
  • Enforces authentication, authorisation, and policy
  • Provides a single ingress for capability invocation
• Execution Services
  • Deterministic executors (e.g. rules engines, transformation services)
  • AI-assisted executors (e.g. model-backed services)
  • Deployed and scaled independently
• Integration Infrastructure
  • Existing APIs, ESBs, ODSs, and adapters
  • Largely unchanged, but progressively surfaced through capabilities

Physical deployment may vary by environment, but logical boundaries remain consistent.

4.3 Trust and Security Boundaries

The architecture explicitly defines and enforces trust boundaries.

Key boundaries include:

• User to DXP
  • Identity established and authenticated
  • No direct access to backend systems
• DXP to Capability Gateway
  • Authenticated, authorised, and audited
  • Requests are declarative and scoped to allowed capabilities
• Capability Execution to Systems
  • Least-privilege access
  • Credentials and secrets isolated from the DXP
  • No implicit trust between executors and legacy systems

AI-assisted executors are treated as lower-trust components:

• Inputs and outputs are validated
• Execution is constrained by policy
• Provenance and confidence are mandatory

4.4 Data Flow Overview

Data flows through the architecture in a controlled, directional manner.

Typical flow:

1. User interacts with the DXP
2. DXP issues a capability invocation with inputs and context
3. Capability gateway validates and routes the request
4. Executor retrieves or processes data via integration services
5. Result, confidence, and provenance are returned to the DXP

Key principles:

• No shared databases between layers
• No implicit data access
• All data movement is observable and auditable

The DXP never directly queries backend systems.

4.5 Control Flow Overview

Control flow is capability-driven, not system-driven.

Key characteristics:

• The DXP initiates control flow by requesting outcomes
• Execution decisions are deferred to runtime
• Executors do not call back into the DXP

Control flow supports:

• Synchronous execution for low-latency outcomes
• Asynchronous execution for long-running or AI-assisted tasks
• Progressive disclosure of results where appropriate

This model avoids tight coupling and enables incremental evolution of both the DXP and backend systems.

flowchart LR
    %% Users and Channels
    User["End Users (Staff, Partners, Public)"]
    Admin["Admins / Product Teams"]

    %% DXP Presentation Shell
    subgraph DXP["DXP Presentation Shell (Deterministic & Stable)"]
        UI["UI Components (Capability-driven)"]
        Nav["Navigation & Layout"]
        State["Explicit UI / Case State"]
        Auth["Identity & Access Control"]
        A11y["Accessibility & Theming"]
        Telemetry["UX Telemetry & Audit UI"]
    end

    %% AI Interaction Layer
    subgraph AI_LAYER["AI Interaction Layer (Bounded & Replaceable)"]
        Intent["Intent Detection"]
        Reasoning["Contextual Reasoning"]
        PromptLib["Versioned Prompts"]
        Explain["Explanation & Confidence Generation"]
    end

    %% MCP Layer
    subgraph MCP_LAYER["Model Context Protocol (MCP)"]
        ToolRegistry["Tool Registry (Capabilities)"]
        Schema["Tool Schemas & Validation"]
        Policy["Capability Policies (Read / Write / Scope)"]
        Audit["MCP Invocation Logs"]
    end

    %% Integration Substrate
    subgraph INTEGRATION["Integration Substrate (Deterministic)"]
        API["API Gateway / APIM"]
        ESB["ESB / Red Hat Fuse (Selective Use)"]
        ODS["Operational Data Store"]
        Transform["Deterministic Transformations"]
    end

    %% Legacy Systems
    subgraph LEGACY["Legacy & Systems of Record"]
        L1["Legacy System A (No Native APIs)"]
        L2["Legacy System B"]
        L3["Document & Records System (e.g. TRIM)"]
        DB[("Databases / File Stores")]
    end

    %% Observability & Governance
    subgraph GOV["Cross-Cutting Governance"]
        Sec["Security Monitoring"]
        AuditTrail["Enterprise Audit Logs"]
        Risk["Model Risk & Drift Monitoring"]
    end

    %% Flows
    User --> UI
    Admin --> UI
    UI --> Nav
    UI --> State
    UI --> Auth
    UI --> A11y
    UI --> Telemetry
    State --> Intent
    Intent --> Reasoning
    Reasoning --> PromptLib
    Reasoning --> Explain
    Reasoning --> ToolRegistry
    ToolRegistry --> Schema
    ToolRegistry --> Policy
    ToolRegistry --> Audit
    ToolRegistry --> API
    API --> ESB
    API --> ODS
    ESB --> Transform
    ODS --> Transform
    Transform --> L1
    Transform --> L2
    Transform --> L3
    Transform --> DB
    Telemetry --> AuditTrail
    Audit --> AuditTrail
    API --> AuditTrail
    Reasoning --> Risk
    Policy --> Sec