Enterprise Intelligence on AWS

Platform Realisations — platform directory · Technology Participation in Enterprise Intelligence — technology contributions

Implementing the Arqua Enterprise Intelligence Architecture using Amazon Web Services

Applying this platform mapping

This article describes possible architectural participation, not a tested deployment, certification or proof of control effectiveness. The selected services, versions, configuration and actual access paths need evidence for the proposed use.

Qualification supports reliance for a declared purpose; it does not authorise execution. Applicable authority and conditions may be maintained through valid prior approvals, protected state and proportionate revalidation.

Meaningful human participation identifies what the person reviewed, the judgement contributed, the authority exercised and the action covered. Authorised agents may perform delegated steps under applicable controls. A lane label or approval record alone does not establish those conditions.

Native platforms, existing governance, composed services and human or partner controls may satisfy the responsibilities. SCIA is a reference architecture; this mapping does not establish SCIA compatibility, integration or deployed enforcement.

Permission, actual execution and observed outcome remain distinguishable. Holds, refusals, escalation and non-action have their own consequences. Outcome evidence informs review and governed revision; it does not automatically overwrite accepted meaning or history.

Platform Realisation Principle

Platform implementations assemble sufficient authoritative enterprise understanding within the Intent Scope established by the Operational Intent.

Platform technologies implement Runtime Context Assembly, Enterprise Coordination and Execution Admissibility support.

They do not define Enterprise Intelligence.

AWS capabilities should therefore be described as participating in purpose-specific Runtime Context Assembly rather than searching enterprise information broadly.

Executive Summary

Enterprise Intelligence is not delivered by cloud infrastructure alone.

It emerges from the disciplined implementation of constitutional architectural responsibilities that continuously represent, preserve, assemble, govern and operationalise enterprise understanding.

Amazon Web Services provides a cloud-native platform for implementing Enterprise Intelligence through event-driven architecture, distributed computing, scalable storage, artificial intelligence and operational automation.

This paper demonstrates how AWS services implement the Arqua Enterprise Intelligence Architecture while preserving enterprise ownership, semantic integrity, Business Domain autonomy and platform independence.

The resulting architecture enables Business Domains to assemble Qualified Operational Understanding dynamically from authoritative enterprise representations rather than relying upon duplicated datasets or isolated AI systems.

1. Purpose

This document defines the AWS reference implementation of the Arqua Enterprise Intelligence Framework.

It describes how AWS services collectively implement the constitutional responsibilities required for Enterprise Intelligence while remaining subordinate to enterprise architecture.

The architecture itself remains vendor independent.

AWS implements the architecture.

It does not define it.

2. Normative Architecture

The following constitutional responsibilities remain independent of implementation technology:

• Enterprise Coherence;
• Enterprise Representation Intelligence;
• Institutional Memory;
• Enterprise Participation;
• Runtime Context Assembly;
• Operational Assembly Environment;
• Enterprise Coordination;
• Execution Admissibility Architecture; and
• Enterprise Learning.

These constitutional responsibilities remain unchanged whether Enterprise Intelligence is implemented using AWS, Microsoft Azure, Google Cloud or any future technology platform.

3. Architectural Principles

Enterprise Intelligence on AWS is governed by seven architectural principles.

AP-1 — Enterprise Meaning Belongs to the Enterprise

Enterprise semantics, authority and governance remain enterprise assets.

AP-2 — AWS Implements Architectural Responsibilities

AWS services realise constitutional responsibilities without redefining them.

AP-3 — Enterprise Products Remain Authoritative

Operational Assembly consumes authoritative enterprise products but never replaces them.

AP-4 — Runtime Context is Temporary

Qualified Operational Understanding has purpose-specific validity and freshness limits. Context and qualification evidence may be retained under applicable retention and reconstruction obligations.

AP-5 — Governance is Continuous

Identity, policy, authority and provenance participate throughout Runtime Context Assembly.

AP-6 — AI Consumes Qualified Operational Understanding

Foundation models reason over governed operational context rather than independently constructing enterprise truth.

AP-7 — Cloud Native Does Not Mean Vendor Dependent

Enterprise Intelligence remains portable across cloud providers.

4. Enterprise Representation Layer

Enterprise representations remain the authoritative description of enterprise reality.

Typical representations include:

• Source-Aligned Data Products;
• operational systems;
• events;
• documents;
• telemetry;
• digital twins;
• knowledge graphs; and
• APIs.

AWS implementation technologies may include:

• Amazon S3;
• Amazon Aurora;
• Amazon DynamoDB;
• Amazon Redshift;
• Amazon OpenSearch Service;
• Amazon Timestream;
• Amazon DocumentDB;
• AWS Glue;
• AWS Glue Data Catalog;
• Amazon DataZone;
• Amazon Neptune; and
• domain-owned enterprise repositories.

These services preserve, expose or support enterprise representations.

They do not themselves constitute Enterprise Intelligence.

5. Institutional Memory

Institutional Memory preserves accepted enterprise understanding.

AWS implementations may include:

• Amazon S3;
• AWS Lake Formation for governed data-lake access;
• AWS Glue Data Catalog for technical metadata;
• Amazon DataZone for domain-oriented discovery and governance participation;
• Amazon Neptune, third-party RDF or graph platforms, or enterprise knowledge graph services;
• versioned enterprise metadata;
• enterprise semantic repositories;
• AWS CloudTrail;
• AWS Config;
• AWS Audit Manager; and
• domain-owned evidence repositories.

Institutional Memory is governed understanding rather than long-term storage.

AWS storage, catalogue, metadata, audit and graph services can contribute substrates and evidence.

They do not make AWS the owner of Institutional Memory.

6. Enterprise Registry

The Enterprise Registry advertises authoritative enterprise products.

Each product publishes:

• ownership;
• interface;
• schema;
• semantic definition;
• quality;
• version;
• lineage;
• governance policy;
• permitted use;
• purpose applicability; and
• authority boundary.

The Enterprise Registry is not equivalent to the AWS Glue Data Catalog.

It is an enterprise-owned logical capability implemented through a federation of:

• AWS Glue Data Catalog;
• Amazon DataZone or equivalent business cataloguing;
• Amazon API Gateway metadata;
• Amazon EventBridge Schemas;
• AWS Glue Schema Registry;
• enterprise semantic services;
• operational authority records;
• interface contracts; and
• policy references.

Amazon EventBridge Schemas should be used for schemas associated with EventBridge events.

AWS Glue Schema Registry should be used for governed streaming schemas across supported integrations.

AWS catalogue services contribute registry metadata.

They do not define the Enterprise Registry.

7. Runtime Context Assembly

Runtime Context Assembly constructs purpose-specific operational understanding.

Operational Intent determines:

• participating enterprise products;
• required identities;
• governing policies;
• semantic scope;
• operational authority;
• required freshness;
• required completeness;
• permitted use; and
• consequence boundary.

AWS services supporting Runtime Context Assembly may include:

• Amazon EventBridge;
• AWS Step Functions;
• AWS Lambda;
• Amazon Kinesis;
• Amazon Managed Streaming for Apache Kafka;
• Amazon ECS;
• Amazon EKS;
• Amazon API Gateway;
• Amazon Bedrock;
• Amazon Bedrock AgentCore;
• Amazon SageMaker;
• Amazon S3;
• Amazon Athena;
• Amazon Redshift; and
• domain-owned operational systems.

Together these services can implement a distributed Operational Assembly Environment.

Runtime Context Assembly forms candidate understanding and qualifies it for a defined purpose. Qualified Operational Understanding results where reliance is supported; assembly alone does not establish qualification.

It does not authorise execution by itself.

Enterprise Participation

Operational services may publish Data Products, Event Products and Service Products.

Publication remains enterprise governed.

AWS services may contribute product, event and service interfaces, but they do not establish enterprise authority.

Authority remains with Business Domains, Data Domains or recognised enterprise authorities.

Enterprise Participation determines whether those products may participate in Enterprise Intelligence.

Enterprise Product Publication operationalises that participation.

8. Semantic Resolution

Enterprise Intelligence requires enterprise meaning rather than isolated data.

Semantic Resolution provides:

• ontology reasoning;
• concept resolution;
• dependency interpretation;
• relationship traversal;
• topology navigation;
• enterprise vocabulary;
• semantic qualification; and
• representation alignment.

Semantic services typically integrate:

• Enterprise Knowledge Graphs;
• RDF stores;
• property graphs;
• business glossaries;
• enterprise ontologies;
• semantic models; and
• domain vocabularies.

Enterprise semantic and relationship services may be implemented using Amazon Neptune, a third-party RDF or graph platform, or an enterprise knowledge graph operating outside AWS.

AWS provides infrastructure and implementation capabilities supporting these services.

The enterprise ontology and semantic authority remain enterprise-owned regardless of the graph technology.

9. Identity and Authority

Enterprise execution depends upon trusted identity and operational authority.

AWS implementations may include:

• AWS IAM;
• IAM Identity Center;
• Amazon Cognito;
• Attribute-Based Access Control;
• cross-account roles; and
• AWS Security Token Service.

IAM establishes authenticated principals and AWS permissions.

IAM Identity Center can pass user attributes into AWS sessions for Attribute-Based Access Control.

Cognito may support customer or application identity patterns.

These capabilities support identity-based and resource-based authorisation.

They do not determine the enterprise authority of a representation or whether an action is operationally admissible.

Authority Resolution determines which product, role, claim or decision is authoritative for the operational purpose.

Execution Admissibility determines whether the intended consequence may proceed.

10. Governance

Governance participates throughout Runtime Context Assembly.

AWS governance and evidence services may include:

• AWS Lake Formation;
• AWS Glue;
• AWS IAM;
• IAM Identity Center;
• AWS CloudTrail;
• AWS Config;
• AWS Audit Manager;
• Amazon Macie;
• AWS Security Hub;
• Amazon API Gateway;
• Amazon Bedrock AgentCore policy controls; and
• domain application policy services.

AWS Lake Formation contributes data-lake governance for Amazon S3 and associated AWS Glue Data Catalog metadata, including fine-grained access controls and cross-account sharing.

It is not, on its own, an enterprise-wide governance control plane for operational systems, APIs, agents, documents and cross-platform resources.

Enterprise-wide runtime governance additionally requires IAM, application policy enforcement, API controls, semantic governance, audit services and domain-owned operational authority.

AWS services contribute governance evidence while constitutional governance remains enterprise-owned.

11. Operational Assembly Environment

AWS provides a highly distributed implementation of Operational Assembly.

A typical runtime sequence consists of:

Operational Intent
↓
Amazon EventBridge
↓
Enterprise Registry
↓
Authority Resolution
↓
Identity Resolution
↓
Policy Resolution
↓
Semantic Resolution
↓
AWS Step Functions
↓
AWS Lambda / ECS / EKS
↓
Operational Assembly
↓
Operational Context Manifest
↓
Context Qualification
↓
Qualified Context Manifest
↓
Qualified Operational Understanding
↓
Business Execution

This architecture enables cloud-native Runtime Context Assembly without centralising enterprise knowledge.

AWS hosts or participates in Operational Assembly.

Authoritative enterprise products may remain outside AWS and be accessed through governed interfaces, projections, APIs, events or controlled replication patterns.

12. Artificial Intelligence

AWS provides specialised AI services that consume Qualified Operational Understanding.

Typical services include:

• Amazon Bedrock;
• Amazon Bedrock AgentCore;
• Amazon Quick Suite;
• Amazon SageMaker;
• Amazon Textract;
• Amazon Comprehend; and
• Amazon Transcribe.

Amazon Bedrock provides foundation-model access and AI reasoning.

Amazon Bedrock AgentCore provides agent runtime, tool connectivity and agent controls.

Amazon SageMaker supports model development and specialised machine learning.

Their constitutional responsibility is to support enterprise execution through reasoning, explanation, prediction and specialised intelligence.

They do not replace Runtime Context Assembly, governance, Authority Resolution or enterprise accountability.

Existing Amazon Q Business implementations may participate as interaction clients, but Amazon Q Business should not be treated as the strategic reference implementation for new deployments.

13. Enterprise Interaction

Enterprise users interact with Qualified Operational Understanding through:

• Amazon Quick Suite;
• domain-specific agent experiences implemented through Amazon Bedrock AgentCore;
• operational dashboards;
• business applications;
• APIs;
• AI agents; and
• mobile applications.

Amazon Quick Suite is positioned as the primary human-facing agentic workspace for new AWS reference implementations.

Amazon Bedrock AgentCore is positioned as the runtime foundation for domain-specific enterprise agents, tool connectivity and controlled agent operation.

These interfaces consume governed operational context rather than independently querying enterprise systems or constructing enterprise truth.

14. SCIA Runtime Integration

AWS services may participate in SCIA-compatible execution without making SCIA an AWS capability.

Amazon EventBridge may provide operational events, routing signals and triggering context for candidate operational actions.

AWS Step Functions may orchestrate constrained workflows and expose state transitions that require admissibility evaluation before consequence binds.

AWS IAM, IAM Identity Center and related identity services may contribute identity, permission, role and session attributes used during authority resolution.

Amazon Bedrock and Bedrock AgentCore may support AI reasoning, agent interaction and tool-use preparation while remaining constrained by admissibility controls.

Operational services such as Lambda, ECS, EKS, API Gateway, Kinesis and domain applications may host execution surfaces where proposed actions are formed.

SCIA Runtime remains the runtime reference architecture that evaluates admissibility immediately before operational execution.

AWS capabilities provide runtime signals, orchestration, identity context, AI participation and execution surfaces for SCIA-compatible execution.

They do not own Execution Admissibility, determine enterprise consequence boundaries or replace institutional accountability.

Enterprise Control Plane Participation

AWS contributes implementation capabilities supporting Constitutional Runtime Services.

AWS may contribute to:

• Runtime Context Assembly
• Identity Resolution
• Authority Resolution
• Policy Resolution
• Semantic Resolution
• Context Qualification
• Enterprise Coordination
• Outcome Capture

SCIA Runtime is a reference architecture for admissibility evaluation. The applicable responsibilities may be fulfilled through native, composed, human or partner controls; no separate Arqua runtime is presumed.

AWS does not become the Enterprise Control Plane. It participates in runtime services coordinated by the Enterprise Control Plane while remaining subordinate to the constitutional architecture.

14. Green Lane and Red Lane Execution

AWS can support a Green Lane / Red Lane execution pattern.

Operational Intent
↓
Runtime Context Assembly
↓
Context Qualification
↓
Qualified Operational Understanding
↓
Admissibility Evaluation
↓
Green Lane or Red Lane

Green Lane

Green Lane execution is constrained, repeatable, policy-driven and suitable for known operating conditions.

Characteristics include:

• scheduled work;
• complete operational context;
• repeatable orchestration;
• governed service interactions;
• defined policy conditions; and
• predictable consequence boundaries.

AWS Step Functions can orchestrate Green Lane workflows whose transitions, policies and service interactions have been constrained for repeatable execution.

Determinism depends on the tasks, inputs, side effects, retry behaviour and external systems involved.

Red Lane

Red Lane execution handles ambiguity, exception, investigation, missing context, policy conflict or elevated consequence.

Characteristics include:

• incidents;
• outages;
• emergencies;
• changing operational conditions;
• unresolved context;
• disputed authority;
• policy conflict; and
• elevated consequence.

Runtime Context continuously evolves.

Amazon Bedrock, Amazon Bedrock AgentCore and Amazon Quick Suite may assist reasoning, investigation and coordination while enterprise governance and human authority remain active.

The distinction is not between automation and humans.

The distinction is between admissible repeatable execution and unresolved operational conditions requiring richer context, judgement or escalation.

15. AWS Capability Mapping

16. Architecture Decision Records

ADR-001 — Qualified Operational Understanding remains temporary

Qualified Operational Understanding shall remain purpose-specific, with explicit validity, freshness and retention conditions.

Its permitted reliance period is distinct from the retention of context and qualification evidence.

ADR-002 — AWS implements but does not define the architecture

AWS services implement constitutional responsibilities without redefining enterprise architecture.

ADR-003 — Enterprise semantic governance remains independent

Enterprise semantic governance remains independent of cloud technology.

ADR-004 — Operational Assembly consumes authoritative enterprise products

Operational Assembly consumes authoritative enterprise products and must not replace product ownership.

ADR-005 — AI consumes Qualified Operational Understanding

AI services require inputs qualified for their intended purpose and may help form candidate understanding. Generated content does not acquire accepted standing merely by being produced.

ADR-006 — Execution Admissibility governs irreversible operational actions

Execution Admissibility governs irreversible or consequence-bearing operational actions.

ADR-007 — Enterprise Registry remains enterprise-owned

AWS catalogue and schema services contribute registry metadata but do not define the Enterprise Registry.

17. Non-Goals

This architecture does not:

• replace enterprise applications;
• replace operational systems;
• replace enterprise governance;
• require all enterprise data to reside on AWS;
• centralise Business Domain ownership;
• replace enterprise semantic models;
• make AWS the owner of Institutional Memory;
• make Amazon Quick Suite the intelligence architecture;
• make Bedrock AgentCore equivalent to Execution Admissibility;
• eliminate platform interoperability; or
• redefine the Arqua Enterprise Intelligence Architecture.

AWS provides implementation capabilities rather than enterprise constitutional responsibilities.

18. Reference Architecture

19. Reference Deployment Patterns

AWS-based Enterprise Intelligence deployments may follow several patterns.

Pattern 1 — AWS as Operational Assembly Environment

AWS hosts the assembly, event routing, workflow, agent runtime and execution services while authoritative enterprise products remain governed by their source domains.

Pattern 2 — Federated Enterprise Registry

The Enterprise Registry is implemented through a federation of Glue Data Catalog, DataZone, API metadata, EventBridge Schemas, Glue Schema Registry and enterprise semantic services.

Pattern 3 — Bedrock AgentCore as Agent Runtime Layer

Bedrock AgentCore provides runtime, tool connectivity and controls for domain-specific agent experiences, while enterprise admissibility and accountability remain institution-owned.

Pattern 4 — Quick Suite as Interaction Layer

Amazon Quick Suite provides a human-facing interaction surface for research, business intelligence, automation participation and assisted work while remaining constrained by governed context.

Pattern 5 — Event-Driven Operational Assembly

EventBridge, Step Functions, Lambda, ECS, EKS and API Gateway support operational triggering, workflow and assembly patterns under explicit authority and policy constraints.

Pattern 6 — Lake Formation as Data-Lake Governance Contributor

Lake Formation contributes fine-grained governance for S3 data lakes and Glue Data Catalog metadata while enterprise-wide runtime governance is implemented through additional identity, policy, semantic and operational controls.

Pattern 7 — Enterprise Semantic Services

Amazon Neptune, third-party graph platforms or external enterprise knowledge graphs implement semantic and relationship services while enterprise ontology and semantic authority remain enterprise-owned.

20. Implementation Roadmap

Phase 1

Establish Enterprise Registry, semantic governance and System Model Foundation.

Phase 2

Publish Source-Aligned Data Products.

Phase 3

Implement Runtime Context Assembly using EventBridge, Step Functions, Lambda, ECS, EKS and API Gateway.

Phase 4

Integrate governance through Lake Formation, IAM, IAM Identity Center, API controls, audit services and enterprise policy services.

Phase 5

Connect Amazon Quick Suite, Bedrock AgentCore, operational applications and AI agents to consume Qualified Operational Understanding.

Phase 6

Continuously capture outcomes, preserve Institutional Memory and refine Runtime Context Assembly rules.

21. Architecture of Record

An AWS implementation should be recorded in an Architecture of Record.

The Architecture of Record should identify:

• which AWS capabilities implement which architectural responsibilities;
• which products are authoritative;
• which representations are accepted;
• which enterprise semantic services are authoritative;
• which registry sources participate;
• which context is assembled at runtime;
• which policies apply;
• which identities and authorities participate;
• which workflows can execute;
• which agent tools are available;
• which actions require admissibility evaluation;
• which evidence is captured; and
• which outcomes feed Enterprise Learning.

The Architecture of Record records accepted standing, applicability, obligations and boundaries. Operational evidence is needed to establish whether the implementation conforms to those arrangements.

22. Boundary Conditions

AWS should not be described as:

• the owner of enterprise knowledge;
• the source of enterprise truth;
• the definition of Institutional Memory;
• the authority for enterprise meaning;
• the Enterprise Registry itself;
• the substitute for governance;
• the decision-maker for consequence-bearing action;
• the owner of enterprise semantics;
• the owner of enterprise ontology; or
• the constitutional architecture itself.

AWS may implement capabilities that support these responsibilities when governed by the Arqua Enterprise Intelligence Architecture.

Conclusion

Amazon Web Services provides a cloud-native platform for implementing Enterprise Intelligence.

Its event-driven architecture, distributed compute services, governance capabilities and AI ecosystem can support Runtime Context Assembly and Operational Assembly.

However, Enterprise Intelligence does not emerge from AWS services alone.

It emerges when those services are organised according to enduring constitutional responsibilities that preserve enterprise meaning, governance, authority and institutional understanding.

Within this reference architecture, AWS becomes the implementation platform.

The enterprise remains the owner of its architecture.

This separation ensures Enterprise Intelligence remains durable, portable and resilient as cloud technologies continue to evolve.

Related Architecture Papers

• Enterprise Intelligence Framework
• Runtime Context Assembly
• Operational Assembly Environment
• Enterprise Intelligence on the Microsoft Platform
• Enterprise Representation Intelligence
• Institutional Memory
• System Model Foundation
• Enterprise Coordination
• Execution Admissibility Architecture

© 2025–Present Arqua Pty Ltd. All rights reserved.

This publication forms part of the Arqua Enterprise Intelligence Architecture portfolio.

No part of this publication may be reproduced, redistributed, adapted, republished or incorporated into derivative works without the prior written permission of Arqua Pty Ltd, except for brief quotations used with appropriate attribution.