Business Domain Operational Assembly Pattern

STATUS: EXTERNAL — share-safe, bounded, regulator-visible.

Apply External / Share-Safe Codex AI rules.

A Reference Architecture for Business Domain Operational Intelligence

Executive Summary

Business Domains are not responsible for creating enterprise truth.

Enterprise truth remains within authoritative Enterprise Products.

Business Domains continuously assemble:

• Qualified Operational Understanding
• operational priorities
• enterprise policies
• operational constraints
• enterprise resources
• enterprise coordination
• business objectives

These inputs are assembled into a coherent operational proposal.

Operational Assembly is the constitutional implementation responsibility of the Business Domain.

It transforms enterprise understanding into operational readiness without becoming the source of enterprise truth or the owner of execution governance.

Execution remains independently governed through Execution Admissibility.

Purpose

The Business Domain Operational Assembly Pattern defines how Business Domains:

• consume Qualified Operational Understanding
• assemble operational readiness
• coordinate enterprise resources
• evaluate operational alternatives
• establish execution proposals
• prepare enterprise consequence

Business Domains assemble.

They do not determine admissibility.

This pattern defines the implementation responsibility through which Business Domains convert qualified enterprise understanding into Proposed Operational Actions before the execution governance boundary.

Constitutional Position

Business Domain Operational Assembly is an Enterprise Implementation Pattern.

It realises the constitutional responsibilities of Enterprise Coordination within Business Domains.

Execution Admissibility remains a separate Constitutional Runtime Service.

Business Domain Operational Assembly is the final enterprise assembly activity before execution governance.

It does not authorise execution.

Architectural Principles

BDOA-1 — Business Domains consume rather than own enterprise truth

Business Domains consume authoritative enterprise representations, Qualified Operational Understanding and governed operational context.

They do not create enterprise truth.

Enterprise truth remains within authoritative Enterprise Products and accepted enterprise representations.

BDOA-2 — Operational Assembly is purpose-driven

Operational Assembly is driven by Operational Intent and business objectives.

It assembles readiness for a defined operational purpose rather than creating generic process movement.

BDOA-3 — Business Domains assemble operational readiness

Business Domains assemble the conditions required for operational readiness.

This includes resources, priorities, constraints, dependencies, evidence and proposed action structures.

BDOA-4 — Business Domains coordinate enterprise capabilities

Business Domains coordinate enterprise capabilities required for a proposed operational response.

They align resources and participation without absorbing enterprise-wide ownership or constitutional authority.

BDOA-5 — Business Domains produce operational proposals rather than execution

Operational Assembly produces Proposed Operational Actions.

These proposals do not bind institutional consequence until evaluated by Execution Admissibility.

BDOA-6 — Execution remains independently governed

Execution Admissibility determines whether Proposed Operational Actions may become enterprise consequence.

Business Domains do not bypass or replace that governance boundary.

BDOA-7 — Operational Assembly remains technology independent

Operational Assembly is not defined by workflow engines, collaboration tools, AI platforms, data platforms or orchestration products.

Technology may support assembly.

Technology does not define the architectural responsibility.

BDOA-8 — Business Domains remain autonomous while participating within Enterprise Intelligence

Business Domains retain operational autonomy while participating in Enterprise Intelligence.

Operational Assembly allows Business Domains to prepare enterprise consequence without becoming owners of enterprise truth or execution governance.

Inputs to Operational Assembly

Operational Assembly consumes:

• Qualified Operational Understanding
• Operational Intent
• Enterprise Coordination
• Enterprise Products
• Graph Products
• Enterprise Events
• Identity
• Authority
• Policies
• Operational Constraints
• Business Priorities
• Operational Objectives

Business Domains assemble these enterprise assets into operational readiness.

The purpose of assembly is not to create a new source of truth.

The purpose is to prepare a coherent operational proposal using qualified understanding, governed participation and current operational constraints.

Operational Assembly Responsibilities

Business Domain Operational Assembly includes:

• operational planning
• operational option formation
• resource selection
• operational sequencing
• priority balancing
• operational readiness
• dependency coordination
• exception handling
• escalation preparation
• proposal generation

Operational Assembly produces enterprise proposals.

It does not perform enterprise execution.

These responsibilities may be supported by workflow platforms, collaboration systems, operational tools, AI assistants or domain applications.

Those technologies contribute to assembly.

They do not own the Business Domain responsibility.

Proposed Operational Action

Proposed Operational Action is the Business Domain’s assembled operational proposal.

It includes:

• intended action
• participating resources
• required authority
• operational constraints
• supporting evidence
• intended consequence
• execution prerequisites

The Proposed Operational Action becomes the formal input to Execution Admissibility.

It represents what the Business Domain is proposing to do, why the proposal is operationally relevant, what resources participate, what constraints apply and what consequence is intended.

A Proposed Operational Action is not execution.

It remains a proposal until Execution Admissibility evaluates whether it may proceed.

Enterprise Control Plane

The Enterprise Control Plane coordinates the constitutional runtime progression:

Operational Intent
↓
Runtime Context Assembly
↓
Enterprise Coordination
↓
Business Domain Operational Assembly
↓
Execution Admissibility
↓
Operational Execution

Business Domain Operational Assembly therefore represents the final enterprise assembly activity before execution governance.

It converts coordinated enterprise understanding into Proposed Operational Actions without authorising those actions to execute.

Relationship to SCIA Runtime

Business Domain Operational Assembly produces Proposed Operational Actions.

SCIA Runtime evaluates those proposals.

Business Domains assemble operational readiness.

SCIA Runtime determines whether enterprise consequence is admissible.

Business Domains never bypass Execution Admissibility.

Business Domain Operational Assembly
↓
Proposed Operational Action
↓
SCIA Runtime
↓
Typed Admissibility Outcome
↓
Operational Execution

SCIA Runtime does not replace Business Domain Operational Assembly.

It evaluates the admissibility of assembled proposals at the operational commit boundary.

Platform Contributions

Business Domain Operational Assembly remains technology independent.

Platforms may contribute implementation capabilities.

They do not define the pattern.

Microsoft

Microsoft capabilities such as Business Domain workspaces, Power Platform, Microsoft Fabric and Microsoft 365 Copilot may support Operational Assembly.

They do not replace it.

AWS

AWS capabilities such as operational services, Step Functions and Amazon Bedrock may support Operational Assembly.

They do not govern execution.

Databricks

Databricks capabilities such as Lakeflow, Mosaic AI and Unity Catalog may support Operational Assembly.

They do not replace Business Domain responsibility.

Technology contributes.

Architecture defines.

Architecture Diagram

Business Domains assemble operational proposals.

Execution Admissibility governs enterprise consequence.

Green Lane and Red Lane Assembly

Business Domain Operational Assembly supports deterministic and adaptive execution modes.

Green Lane — Deterministic assembly

Green Lane assembly applies where work is planned and operational conditions are stable.

Characteristics:

• planned work
• complete context
• stable priorities
• predictable coordination

Business Domains assemble deterministic operational proposals when the operational intent, available context, priorities and coordination pathways are sufficiently stable.

Red Lane — Adaptive assembly

Red Lane assembly applies where operational conditions are changing, incomplete or incident-driven.

Characteristics:

• incidents
• outages
• incomplete information
• dynamic priorities
• AI-assisted operational reasoning

Business Domains assemble adaptive operational proposals when operational conditions require rapid interpretation, changing resource selection, human judgement or AI-assisted operational reasoning.

Operational Assembly supports both execution modes.

In both modes, execution remains independently governed through Execution Admissibility.

Non-Goals

This pattern does not:

• replace Runtime Context Assembly
• replace Enterprise Coordination
• replace workflow engines
• replace Business Processes
• replace Execution Admissibility
• replace operational systems

Business Domain Operational Assembly establishes operational readiness.

Execution remains independently governed.

Workflow engines, business process platforms, domain applications and AI systems may support Operational Assembly.

They do not become the architectural responsibility.

Conclusion

Business Domain Operational Assembly transforms Qualified Operational Understanding into Proposed Operational Actions.

Rather than executing enterprise consequence directly, Business Domains continuously assemble enterprise resources, operational priorities, policies and constraints into coordinated operational proposals.

Execution Admissibility then independently determines whether those proposals may become institutional consequence.

This separation preserves Business Domain autonomy while ensuring enterprise execution remains constitutionally governed.

Cross References

• Operational Intent Pattern
• Runtime Context Assembly Pattern
• Enterprise Coordination Pattern
• Execution Admissibility Pattern
• SCIA Runtime
• The Enterprise Control Plane
• Qualified Operational Understanding
• Enterprise Intelligence Framework

Pattern Navigation

Runtime Context Assembly Pattern
↓
Enterprise Coordination Pattern
↓
Business Domain Operational Assembly Pattern
↓
Execution Admissibility Pattern

Validation

Before publishing verify:

• Business Domains are consistently described as operational assembly environments rather than execution engines.
• Business Domains consume Qualified Operational Understanding.
• Proposed Operational Action is introduced as a governed enterprise artefact.
• SCIA Runtime evaluates Proposed Operational Actions rather than coordinating them.
• Business Domain Operational Assembly is clearly separated from Execution Admissibility.
• Platform technologies are described as contributors rather than owners of Business Domain Operational Assembly.
• The architectural progression consistently reads:

Operational Intent
↓
Runtime Context Assembly
↓
Qualified Operational Understanding
↓
Enterprise Coordination
↓
Business Domain Operational Assembly
↓
Proposed Operational Action
↓
Execution Admissibility
↓
Operational Execution

The completed paper establishes Business Domain Operational Assembly as the implementation pattern that bridges Enterprise Intelligence and enterprise execution while preserving the constitutional separation between operational assembly and execution governance.

Boundary Statement

This page is an Enterprise Implementation Pattern.

It is not a Business Process paper, workflow paper or execution paper.

It does not define enterprise truth.

It does not authorise enterprise execution.

It does not replace Execution Admissibility, SCIA Runtime, Runtime Context Assembly, Enterprise Coordination or operational systems.

Business Domains remain accountable for Operational Assembly.

Execution consequence remains independently governed through Execution Admissibility.

Human and organisational accountability remains with the institution applying the pattern.