STATUS: EXTERNAL — share-safe, bounded, regulator-visible.
Apply External / Share-Safe Codex AI rules.
How Institutions Operationalise Qualified Operational Understanding
Reference Architecture 002
Enterprise question: How do authorised enterprise participants consistently operationalise qualified operational understanding without independently constructing their own interpretation of enterprise reality?
Purpose
Enterprise Participation provides the constitutional architecture through which authorised enterprise participants consistently operationalise qualified operational understanding into governed operational experiences.
Enterprise Participation does not produce enterprise understanding. Enterprise Intelligence performs that responsibility by transforming operational reality into Qualified Operational Understanding.
Enterprise Participation ensures every participant acts from that shared understanding.
This Reference Architecture is the natural companion to Enterprise Intelligence Platform Reference Architecture. RA001 explains how institutions continuously produce Qualified Operational Understanding. RA002 explains how authorised enterprise participants consistently operationalise that understanding.
Together they form the complete Enterprise Intelligence lifecycle.
Reference Architecture position
Enterprise Participation Reference Architecture is a first-class Enterprise Intelligence Reference Architecture.
It is not:
- Constitutional Architecture;
- an Applied Pattern;
- a Technology Pattern; or
- Platform Architecture.
It sits alongside RA001 and above platform realisation architectures.
Constitutional Architecture
↓
RA001 — Enterprise Intelligence Platform Reference Architecture
↓
RA002 — Enterprise Participation Reference Architecture
↓
Platform Realisation Reference ArchitecturesReference Architectures demonstrate how constitutional capabilities operate together as complete enterprise operating models. Platform Realisations show how specific technologies participate in one or both reference architectures without becoming the architecture.
Boundary
This reference architecture describes how authorised enterprise participants operationalise Qualified Operational Understanding into governed operational experiences.
It does not:
- create institutional understanding;
- replace Enterprise Intelligence;
- change any established constitutional capability;
- make applications, dashboards, workflows or AI responsible for constructing enterprise reality;
- make Business Composition the constitutional architecture;
- prescribe Microsoft, Salesforce, ServiceNow, SAP, AWS, Databricks, Snowflake, Stardog 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.
Complete Enterprise Intelligence lifecycle
The canonical lifecycle is:
Operational Reality
↓
Enterprise Representation Intelligence
↓
Enterprise Representation
↓
Enterprise Publication
↓
Enterprise Product
↓
Enterprise Registry
↓
Context-Aware Semantic Graph
↓
Operational Context Assembly
↓
Qualified Operational Understanding
↓
Enterprise Participation
↓
Operational Experiences
↓
Enterprise Coordination
↓
Enterprise Outcomes
↓
Institutional LearningEnterprise Intelligence continuously transforms operational reality into Qualified Operational Understanding.
Enterprise Participation operationalises that understanding into governed operational experiences.
Enterprise Coordination synchronises those experiences into coherent enterprise outcomes.
Institutional Learning ensures those outcomes continuously improve future enterprise understanding.
Complementary constitutional functions
Function | Responsibility | Produces |
Enterprise Intelligence | Determines what the institution understands. | Qualified Operational Understanding. |
Enterprise Participation | Determines how authorised participants legitimately operationalise institutional understanding. | Operational Experiences. |
Enterprise Coordination | Synchronises operational experiences into coherent enterprise outcomes. | Enterprise Outcomes. |
Institutional Learning | Transforms enterprise outcomes into enduring institutional memory and future operational understanding. | Revised institutional memory and future operational understanding. |
These functions are complementary. Enterprise Intelligence establishes qualified understanding. Enterprise Participation operationalises that understanding for authorised participants. Enterprise Coordination synchronises participant-specific experiences into coherent outcomes. Institutional Learning converts outcomes into future understanding through governed revision.
Experience Context
Experience Context is the participant-specific qualification of qualified operational understanding required to create an operational experience.
Operational Context Assembly answers:
What does the institution understand?
Experience Context answers:
What does this participant require from that understanding in order to fulfil its role?
Experience Context never changes institutional understanding. It tailors participation while preserving institutional meaning.
Experience Context may determine:
- participant role;
- authorised purpose;
- required viewpoint;
- permitted actions;
- required evidence visibility;
- interaction channel;
- escalation conditions;
- collaboration boundary;
- workflow obligations; and
- presentation requirements.
Experience Context is not a new source of truth. It is a participant-specific operational qualification of already qualified institutional understanding.
Enterprise participant model
Enterprise Participation supports multiple participant types.
Examples include:
- human participants;
- operational applications;
- dashboards;
- workflow engines;
- mobile experiences;
- business portals;
- partner portals;
- customer portals;
- APIs;
- collaborative platforms;
- AI assistants;
- autonomous AI agents; and
- machine-to-machine integrations.
Every participant consumes the same institutional understanding. Only the operational experience differs.
A dashboard may present visibility. A workflow may coordinate work. An AI assistant may support interpretation. A portal may expose participant-specific interaction. A machine-to-machine integration may transmit state or request action. None of these participants independently establishes institutional understanding.
Business Composition
Business Composition is not the constitutional architecture.
Business Composition is an implementation capability operating within Enterprise Participation. Its purpose is to create governed operational experiences using Qualified Operational Understanding.
Examples include:
- operational applications;
- dashboards;
- workflow automation;
- collaboration experiences;
- AI assistants;
- mobile applications; and
- portals.
Business Composition operationalises institutional understanding. It never establishes institutional understanding.
The constitutional boundary is deliberate:
- Enterprise Intelligence determines what the institution understands.
- Business Composition creates participant-specific operational experiences from that understanding.
- Enterprise Coordination synchronises those experiences into enterprise outcomes.
Operational experiences
Operational Experiences are participant-specific operationalisations of shared institutional understanding.
They may include:
- decision-support experiences;
- workflow experiences;
- dashboard experiences;
- collaborative experiences;
- assistant-mediated experiences;
- portal experiences;
- mobile experiences;
- API-mediated experiences; and
- machine-to-machine experiences.
Operational Experiences do not fragment institutional understanding. They express the same Qualified Operational Understanding through participant-specific context, authority, role and permitted-use constraints.
Technology participation
Technology participates within enterprise capabilities. Technology never defines enterprise capabilities.
Enterprise Capability | Typical Technology Participation |
Enterprise Representation | AWS, Databricks, Snowflake |
Enterprise Publication | Publication services, metadata platforms |
Enterprise Registry | Enterprise catalogues |
Context-Aware Semantic Graph | Stardog, graph technologies |
Operational Context Assembly | Microsoft Fabric, orchestration services |
Enterprise Participation | Microsoft Power Platform, Power BI, Power Apps, Power Automate, Teams, Copilot, Copilot Studio, Salesforce, ServiceNow, SAP, portal platforms, workflow engines |
Enterprise Coordination | Business process platforms, workflow engines |
Institutional Learning | Analytics, observability, evaluation platforms |
These technologies may implement, support or participate in enterprise capabilities. They do not own the constitutional responsibilities.
Relationship to RA001
Enterprise Intelligence Platform Reference Architecture explains how institutions continuously produce Qualified Operational Understanding.
Enterprise Participation Reference Architecture explains how Qualified Operational Understanding becomes governed operational experiences across authorised enterprise participants.
RA001
Operational Reality
↓
Qualified Operational Understanding
RA002
Qualified Operational Understanding
↓
Operational Experiences
↓
Enterprise Outcomes
↓
Institutional LearningRA001 and RA002 are not competing architectures. They describe adjacent responsibilities in one institutional lifecycle.
Related pages
- Enterprise Intelligence Platform Reference Architecture — Explains how institutions continuously produce Qualified Operational Understanding.
- Enterprise Intelligence Architecture — Defines the complete enterprise-facing operating architecture.
- Runtime Context Assembly — Produces Qualified Operational Understanding consumed through Enterprise Participation.
- Enterprise Product Publication Pattern — Operationalises intentionally published Enterprise Products.
- Enterprise Intelligence Execution Architecture — Describes the coordination path from shared understanding into operational work.
Preflight boundary
Before this reference architecture is used externally, confirm:
Does this clearly state what it does, what it does not do, who remains accountable, and where uncertainty is explicitly marked?
Document Status: Public Website Page
Publication Date: 2026
Version: 1.0
Last Updated: 4 August 2026
Owner: Arqua Pty Ltd
Author: Mark Tovey
Portfolio: Enterprise Intelligence Architecture
Reference Architecture: RA002
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.
The concepts, architectural models, constitutional frameworks, terminology and diagrams presented on this page constitute original intellectual property developed by Arqua Pty Ltd.
Publication of this material does not grant any licence to implement, commercialise or reproduce the underlying intellectual property.
Arqua®, SCIA™, Enterprise Intelligence Architecture™, Runtime Context Assembly™, Enterprise Representation Intelligence™, Institutional Memory™, Execution Admissibility™, and associated architectural terminology may be trademarks, registered trademarks or protected intellectual property of Arqua Pty Ltd.