Enterprise Intelligence Platform Reference Architecture

Composing Enterprise Intelligence Across Existing Systems

Reference Architecture 001

Enterprise question: How can representation, publication, purpose-specific understanding, participation and execution controls work together across an enterprise environment?

Purpose

This reference architecture provides an enterprise composition view within Enterprise Intelligence Architecture. Existing systems, governance, human procedures and partner capabilities may fulfil these responsibilities without requiring one central platform.

It explains the handoffs among representation, publication, discovery, context formation and qualification, participant experiences, coordination, execution controls and learning.

Reference Architectures demonstrate composition. They do not replace Constitutional Architecture papers, and they do not prescribe platform implementation.

The EIA capstone defines the integrated architecture; the canonical vocabulary defines its terms. This vendor-neutral composition view helps assess handoffs and residual responsibilities for a declared scope. Its four blueprints are explanatory groupings, not canonical layers, a deployment order or a compulsory adoption sequence.

For the integrated architecture and current responsibility relationships, see Enterprise Intelligence Architecture. The blueprints below provide the scoped composition view.

Architectural Responsibilities

Operational Systems

Operational systems provide records and evidence of operating conditions and change within their source scope.

Enterprise Representation

Forms and evolves representations from operational evidence. Institutional acceptance remains a separate enterprise governance decision.

Enterprise Product Publication

Makes Published Enterprise Products available under declared contracts, lifecycle and governance. Acceptance, preservation and publication remain distinct.

Runtime Context Assembly and Context Qualification

Context formation produces Candidate Operational Understanding and an Assembly Manifest. Context Qualification evaluates fitness for the declared purpose and records its outcome. Qualified Operational Understanding results only where reliance is supported; it does not authorise execution.

Enterprise Participation

Projects Qualified Operational Understanding into participant experiences.

Enterprise Coordination

Coordinates execution across people, applications, automation and AI.

Execution Admissibility

Separately evaluates proposed consequence-bearing action at its applicable boundary against current authority and enterprise conditions. Coordination and qualified understanding do not themselves confer permission.

Outcome Learning

Assesses Outcome Evidence and may support findings, challenges or proposed revision. Appropriate governance accepts or reaccepts changes. Institutional Memory preserves accepted understanding and associated history; improvement is not automatic.

Reference Architecture position

Enterprise Intelligence Reference Architectures sit between Constitutional Architecture and Platform Realisations.

• Constitutional Architecture: defines enduring architectural responsibilities.
• Reference Architectures: explain how those responsibilities work together.
• Implementation Patterns: describe reusable approaches to realising capabilities.
• Platform Realisations: illustrate participation by particular technology ecosystems.

Technology-specific realisations are maintained separately from this reference architecture.

Boundary

This reference architecture describes how constitutional capabilities operate together as an enterprise operating model.

It does not:

• define new constitutional capabilities;
• replace any Constitutional Architecture paper;
• define implementation patterns for individual capabilities;
• prescribe AWS, Microsoft Fabric, Microsoft 365, Databricks, Snowflake, Google Cloud or any other platform;
• assert compliance, assurance, system operation or regulatory certification.

Accountability for architecture adoption, implementation, decision-making, execution and consequence remains with the organisation.

Blueprint 1 — Enterprise Representation Blueprint

This blueprint describes how the enterprise continuously forms and publishes institutional understanding.

Operational evidence supports representation formation and evolution. Governed enterprise evaluation determines acceptance. Accepted standing can then support preservation in Institutional Memory and publication for declared uses. These responsibilities do not require one storage pipeline.

Enterprise Representation Intelligence forms and evolves enterprise representations and supports their evaluation; it does not confer institutional acceptance by itself.

Enterprise Product Publication makes accepted representation available through Published Enterprise Products under declared conditions.

Institutional Memory preserves accepted understanding so it can be reused, reviewed and revised without losing continuity.

Blueprint 2 — Operational Understanding Blueprint

This blueprint explains how Published Enterprise Products support purpose-specific context formation and qualification. Qualification may be unsupported or unresolved; QOU is not guaranteed.

Published products can be discovered and selected for an operational purpose. Semantic relationships support interpretation; Runtime Context Assembly gathers relevant information, and Context Qualification evaluates its suitability for bounded reliance.

The Enterprise Registry provides discoverability.

A semantic graph can support semantic participation; this does not require all sources to be centralised in one graph.

Runtime Context Assembly forms purpose-specific context. Context Qualification separately assesses bounded reliance in that context.

Blueprint 3 — Business Execution Blueprint

This blueprint describes how execution participants consume Qualified Operational Understanding.

People, applications, workflows and agents can consume qualified understanding through appropriate experiences. Enterprise Coordination supports their interaction. Consequential execution remains separately subject to current authority and applicable execution controls.

Different participants can use the same architectural responsibilities through different interfaces and implementations.

Enterprise Coordination supports proposals and interactions across people, systems, workflows, services, applications and agents. Permission, actual execution and observed outcomes require distinct evidence.

Execution remains subject to authority, policy, context, evidence and admissibility constraints where consequence may bind.

Blueprint 4 — Enterprise Control Plane Blueprint

The Enterprise Control Plane spans all previous blueprints.

The Enterprise Control Plane spans representation, understanding and execution. It is a cross-cutting responsibility rather than a stage after the other blueprints.

Control-plane responsibilities include:

• Identity
• Policy
• Metadata
• Semantics
• Governance
• Observability
• Responsible AI
• Lifecycle
• Execution Governance

The Enterprise Control Plane governs participation rather than platform ownership.

It preserves the continuity conditions under which representations, products, context, participants and execution may operate coherently.

Enterprise capability mapping

Relationship to Platform Realisations

Reference Architectures remain platform independent.

Platform Realisations can examine how technologies such as:

• AWS
• Microsoft Fabric
• Microsoft 365
• Power Platform
• Copilot Studio
• Databricks
• Snowflake
• Google Cloud

implement these reference architectures.

Those Platform Realisations should preserve shared accepted meaning while allowing purpose-specific representations, projections and domain differences. They should show how technology ecosystems participate in Enterprise Intelligence while preserving the constitutional architecture.

Using this composition view

For a scoped workflow or decision, identify the participating systems and people, source evidence and accepted meanings, publication conditions, consumer reliance, purpose-specific qualification, coordination, execution controls and observed outcomes. Record which existing capabilities fulfil each responsibility, which handoffs are evidenced and which gaps remain.

The blueprints help structure that assessment; they are not a maturity score or proof of implementation conformance. Publication, adoption or a vendor capability claim does not establish effective operation.

Related Reference Architectures

• Enterprise Participation Reference Architecture — Explains how Qualified Operational Understanding becomes governed operational experiences.

Explore further

• Enterprise Intelligence Architecture
• Enterprise Implementation Patterns
• Platform Realisations

Editorial reconciliation — 24 October 2026

RA001 composition view clarified against the EIA capstone and current Framework: no central platform or mandatory blueprint sequence; Context Qualification, Execution Admissibility and Outcome Learning made explicit. RA001 and RA002 retain complementary explanatory scopes.