Enterprise Participation Reference Architecture

How Institutions Operationalise Qualified Operational Understanding

Reference Architecture 002

Enterprise question: How can people, applications, workflows and AI use shared enterprise meaning through participant-specific experiences while preserving evidence, conditions of reliance and execution authority?

Purpose

This reference architecture explains participation within Enterprise Intelligence Architecture: how qualified understanding can be presented, interpreted and used by different participants for declared purposes.

Participants may require different projections, evidence, versions and interfaces. Coherence depends on preserving accepted meaning, provenance and applicable conditions across those differences.

Qualified Operational Understanding supports bounded reliance; it does not itself authorise execution. Proposed consequence-bearing actions remain subject to current authority and applicable execution controls.

This Reference Architecture is the natural companion to Enterprise Intelligence Platform Reference Architecture. RA001 explains enterprise composition; RA002 focuses on participant-specific use of qualified understanding.

Both are complementary explanatory views within the Enterprise Intelligence Architecture capstone, not consecutive processing stages or a complete platform requirement.

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 beneath the capstone and canonical vocabulary. Implementation patterns and platform realisations describe possible ways to realise the responsibilities.

READING RELATIONSHIPS — NOT A PROCESSING SEQUENCE
Enterprise Intelligence Architecture and canonical vocabulary
  RA001: enterprise composition view
  RA002: participant use and experience view
Implementation patterns and platform realisations: possible realisations

Reference architectures explain how established responsibilities work together within a declared scope. 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:

confer institutional acceptance on participant-generated interpretations;
replace Enterprise Intelligence;
change any established constitutional capability;
make a participant's presentation or generated output authoritative by itself;
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.

Participation within the architecture

Participation connects purpose-specific understanding to human and system experiences. The relationships below are responsibilities to preserve, not a mandatory processing pipeline.

Concern	Responsibility and boundary
Meaning and publication	Governed acceptance establishes meaning and standing. Enterprise Product Publication makes Published Enterprise Products available under declared conditions. Preservation, acceptance and publication remain distinct.
Discovery and context	The Enterprise Registry can support discovery and resolution. Semantic technologies may support interpretation without requiring one central graph. Runtime Context Assembly forms Candidate Operational Understanding within the active Intent Scope.
Qualification and reliance	Context Qualification evaluates fitness for the declared purpose and records its outcome. Qualified Operational Understanding exists only where reliance is supported.
Participant experience	Interfaces expose relevant understanding, evidence and limitations for the participant's role, purpose and access. Presentation does not confer authority or broaden qualification.
Coordination and action	Enterprise Coordination may support proposals and interactions. Execution Admissibility separately evaluates proposed consequence-bearing action at its applicable boundary. Permission, actual execution and observed outcome require distinct evidence.
Evidence and learning	Outcome Learning assesses Outcome Evidence and may support findings or proposed revisions. Appropriate governance accepts or reaccepts changes; Institutional Memory preserves accepted understanding and associated history. Improvement is not automatic.
Cross-cutting governance	The Enterprise Control Plane supports continuity across these responsibilities; it is not a later processing stage.

Experience Context

Experience Context describes the participant-specific conditions for presenting and using understanding: role, declared purpose, viewpoint, evidence visibility, access, interaction channel, collaboration boundary, escalation and workflow obligations.

It is a participation view, not an additional universal qualification engine or a new source of institutional truth. Runtime Context Assembly and Context Qualification retain responsibility for purpose-specific formation and qualification. A changed purpose or material context may require renewed assessment.

The experience should make the relevant source, version, qualification scope, limitations and evidence visible. Where reliance is declared, Consumer Binding can record the consumer, purpose and contract version; that declaration is not proof of actual consumption or correct interpretation.

A displayed permitted action, enabled button or tailored explanation does not grant execution permission. Applicable authority and execution controls remain separate.

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.

Participants can rely on shared accepted meaning while consuming different purpose-specific projections, source versions and evidence. Relevant differences and conflicts must remain visible and traceable.

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. Participant outputs may contribute evidence, interpretations or proposed changes. Their production or display does not by itself establish institutional acceptance.

Business Composition

Business Composition describes implementation work that brings interfaces, workflows, applications and services together into operational experiences. It is not a new architectural authority.

Examples include dashboards, workflow automation, collaboration experiences, AI assistants, mobile applications and portals.

Composition should preserve source identity, accepted meaning, qualification scope, access conditions and evidence visibility. Locally generated interpretation must remain distinguishable from source evidence and accepted representation. Proposed changes follow the relevant governance process; interfaces and generated outputs do not approve themselves.

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 should preserve coherent meaning across participant-specific context, role and permitted use. Different experiences need not contain identical information. Their design should expose relevant scope, evidence and limitations rather than imply that every participant holds the same current understanding.

Technology participation

Applications, dashboards, portals, workflow engines, APIs, collaboration tools and AI interfaces may realise participant experiences. A product's presence does not establish qualification, authorised action or effective enforcement.

Assess technology against the required responsibility, documented capabilities, configuration, evidence and residual enterprise obligations. Graphs, catalogues and orchestration services may support selected concerns without becoming mandatory architecture stages.

Relationship to RA001

Enterprise Intelligence Platform Reference Architecture explains enterprise composition across representation, publication, context, qualification, participation, execution controls and learning.

RA002 focuses on participant use: what each participant receives, which reliance is supported, how differences remain traceable and which authority applies to proposed actions. Both views inherit the capstone and vocabulary; neither is a compulsory processing stage or a complete platform requirement.

Illustrative application

A service dashboard, a field workflow and an AI assistant may use different projections of a service incident. A completed work order does not by itself establish restored customer service. Each experience should identify the evidence supporting its conclusion and preserve unresolved differences.

An assistant's restoration recommendation remains a proposal. Any consequential update or customer commitment requires the applicable authority and execution controls. The observed service outcome supplies evidence for later review; it does not retroactively change what was known earlier.

This is an illustrative scenario, not a reported customer deployment.

Enterprise Intelligence Architecture — Canonical Definitions — Governs enterprise-wide definitions.
Execution Admissibility Architecture — Governs evaluation of proposed consequence-bearing action.
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.

Document Status: Public Website Page

Publication Date: 2026

Version: 1.1

Last Updated: 24 October 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.

Editorial reconciliation — 24 October 2026

RA002 reconciled against the EIA capstone and current Framework: participant-specific reliance, separate execution authority, non-sequential responsibility relationships, Outcome Evidence and governed revision clarified. Earlier classification and preflight instructions were removed from the public rendition.