Execution Admissibility Pattern

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

Apply External / Share-Safe Codex AI rules.

A Reference Architecture for Governing Enterprise Consequence

Executive Summary

Enterprise Intelligence does not directly execute operational proposals.

Business Domains assemble Proposed Operational Actions.

Execution Admissibility determines whether those proposed actions may become institutional consequence.

Execution Admissibility is therefore the final Enterprise Implementation Pattern before operational execution.

Execution Admissibility governs consequence.

It does not determine purpose.

It does not assemble context.

It does not coordinate enterprise participants.

It determines whether proposed enterprise consequence is admissible.

Purpose

The Execution Admissibility Pattern defines how enterprises implement:

• admissibility requests
• admissibility evaluation
• execution governance
• operational commit boundaries
• typed execution outcomes
• escalation
• compensation
• evidence preservation
• runtime enforcement

Execution Admissibility transforms Proposed Operational Actions into governed execution decisions.

This pattern defines the reusable implementation architecture for that responsibility.

It is not the SCIA Runtime paper.

It is not an implementation of a specific technology.

SCIA Runtime is the public runtime reference architecture that implements this pattern.

Constitutional Position

Execution Admissibility is a Constitutional Runtime Service coordinated by the Enterprise Control Plane.

This paper defines how enterprises implement that runtime service.

Execution Admissibility is the final Constitutional Runtime Service before enterprise consequence becomes operationally binding.

Architectural Principles

EAP-1 — Execution follows Qualified Operational Understanding

Execution Admissibility evaluates proposed consequence using Qualified Operational Understanding.

It does not create that understanding.

Runtime Context Assembly remains responsible for producing qualified operational understanding before execution governance occurs.

EAP-2 — Execution follows Enterprise Coordination

Execution Admissibility evaluates proposals after enterprise coordination has resolved the relevant participation, dependencies and operational alignment.

It does not coordinate enterprise participants.

Enterprise Coordination remains responsible for coordinating participation before Business Domains assemble operational proposals.

EAP-3 — Execution follows Operational Assembly

Business Domain Operational Assembly produces Proposed Operational Actions.

Execution Admissibility evaluates those proposals before they become enterprise consequence.

It does not replace Business Domain Operational Assembly.

EAP-4 — Execution evaluates consequence rather than intention

Execution Admissibility evaluates whether a proposed action may become institutionally binding.

It does not determine enterprise purpose.

It evaluates consequence using current authority, evidence, state, policy, constraints and qualified understanding.

EAP-5 — Admissibility remains independent of implementation technology

Execution Admissibility is not defined by workflow engines, policy engines, AI platforms, data platforms, cloud platforms or operational systems.

Technology may implement or support the pattern.

Technology does not own the constitutional responsibility.

EAP-6 — Execution decisions preserve evidence

Execution Admissibility produces governed execution decisions with preserved evidence.

The decision, inputs, constraints, authority resolution, policy basis and outcome must remain available for institutional accountability.

EAP-7 — Operational consequence remains non-bypassable

Execution Admissibility must be evaluated immediately before the operational commit boundary.

Operational consequence must not bypass admissibility evaluation.

EAP-8 — SCIA Runtime implements the Execution Admissibility Pattern

SCIA Runtime is the public runtime reference architecture implementing this pattern.

This paper defines the implementation architecture.

SCIA Runtime defines runtime behaviour.

The two should not be confused.

Inputs to Execution Admissibility

Execution Admissibility evaluates:

• Operational Intent
• Qualified Operational Understanding
• Resolved Identity
• Resolved Authority
• Operational State
• Enterprise Policies
• Operational Constraints
• Supporting Evidence
• Business Priorities
• Proposed Operational Action

Execution Admissibility consumes enterprise understanding.

It does not assemble it.

The purpose of the pattern is to evaluate whether a proposed consequence-bearing action may proceed, using qualified context and governed enterprise inputs that have already been assembled by preceding constitutional runtime services.

Proposed Operational Action

Business Domain Operational Assembly produces Proposed Operational Actions.

Execution Admissibility evaluates them.

Execution Admissibility never generates enterprise proposals.

A Proposed Operational Action represents the Business Domain’s assembled operational proposal. It identifies the intended action, intended consequence, relevant context, required authority, participating resources, applicable constraints, supporting evidence and execution prerequisites.

The Proposed Operational Action remains a proposal until Execution Admissibility determines whether it is admissible.

Admissibility Evaluation

Execution Admissibility evaluates Proposed Operational Actions across the following dimensions:

• Authority
• Identity
• Policy
• Operational State
• Evidence
• Constraints
• Semantic Consistency
• Operational Risk
• Purpose Alignment
• Enterprise Consequence
• Qualification Confidence

These dimensions collectively determine whether execution may proceed.

Evaluation does not make Execution Admissibility the owner of intent, context, coordination or operational assembly.

It determines whether the proposed enterprise consequence is admissible at the point of execution.

Admissibility Outcomes

Execution Admissibility produces canonical enterprise outcomes:

• ADMISSIBLE
• ADMISSIBLE_WITH_CONDITIONS
• ESCALATE
• NOT_ADMISSIBLE
• INSUFFICIENT_INFORMATION

These outcomes are enterprise concepts rather than SCIA-specific implementation details.

They express the governed execution decision that operational systems, Business Domains, runtime services and human accountable roles must consume before consequence becomes binding.

ADMISSIBLE

The Proposed Operational Action may proceed to operational execution.

ADMISSIBLE_WITH_CONDITIONS

The Proposed Operational Action may proceed only if specified conditions are satisfied and preserved as part of the execution evidence.

ESCALATE

The Proposed Operational Action requires human, organisational or higher-authority review before execution may proceed.

NOT_ADMISSIBLE

The Proposed Operational Action must not proceed.

INSUFFICIENT_INFORMATION

The Proposed Operational Action cannot be evaluated because required context, evidence, authority, state or constraint information is incomplete.

Operational Commit Boundary

Execution Admissibility is evaluated immediately before the operational commit boundary.

The commit boundary is the point at which enterprise consequence becomes institutionally binding.

Examples include:

• SAP transaction commit
• payment authorisation
• work order dispatch
• customer communication
• field operation
• API invocation
• agent tool execution
• infrastructure change

Execution Admissibility must remain non-bypassable.

The operational commit boundary may be implemented through different platforms, applications, APIs, workflow engines, event systems or operational tools.

The architectural responsibility remains the same: proposed consequence must be evaluated before it binds the institution.

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

Execution Admissibility therefore becomes the final Constitutional Runtime Service before enterprise consequence.

The Enterprise Control Plane coordinates the progression.

It does not replace Execution Admissibility.

It does not itself determine whether a Proposed Operational Action is admissible.

Relationship to SCIA Runtime

SCIA Runtime is the public runtime reference architecture implementing the Execution Admissibility Pattern.

This paper defines the implementation architecture.

SCIA Runtime defines the runtime behaviour.

The two should not be confused.

Implementation Pattern
↓
SCIA Runtime
↓
Technology Realisation
↓
Operational Commit Boundary

Execution Admissibility defines the reusable enterprise implementation pattern.

SCIA Runtime defines how admissibility operates at runtime.

Technology Realisations show how platform capabilities may support SCIA-compatible runtime behaviour.

Platform Contributions

Execution Admissibility remains technology independent.

Platforms may provide implementation capabilities.

They do not own the constitutional pattern.

Microsoft

Microsoft capabilities such as Entra, Purview, Fabric and Power Platform may provide implementation capabilities supporting Execution Admissibility.

They do not implement the constitutional pattern by themselves.

AWS

AWS capabilities such as IAM, Step Functions, EventBridge and Bedrock may provide implementation capabilities supporting Execution Admissibility.

Execution Admissibility remains enterprise owned.

Databricks

Databricks capabilities such as Unity Catalog, Agent Bricks, Mosaic AI and MLflow may provide implementation capabilities supporting Execution Admissibility.

Execution Admissibility remains independent of platform governance.

Technology contributes.

Architecture defines.

Architecture Diagram

Enterprise Intelligence produces understanding.

Business Domains produce proposals.

Execution Admissibility governs consequence.

Non-Goals

This pattern does not:

• replace Runtime Context Assembly
• replace Business Domain Operational Assembly
• replace workflow engines
• replace operational systems
• replace Enterprise Control Plane
• replace SCIA Runtime

Execution Admissibility governs enterprise consequence.

SCIA Runtime implements that governance.

Workflow engines, policy engines, operational systems, cloud services, AI agents and data platforms may support implementation.

They do not become the constitutional responsibility.

Conclusion

Execution Admissibility provides the final constitutional implementation pattern required before enterprise consequence becomes operationally binding.

By separating operational understanding, enterprise coordination, business domain operational assembly and execution governance, Enterprise Intelligence preserves constitutional clarity while enabling safe, explainable and governed enterprise execution.

SCIA Runtime provides the runtime reference architecture implementing this pattern.

Cross References

• Business Domain Operational Assembly Pattern
• Enterprise Coordination Pattern
• Runtime Context Assembly Pattern
• Context Qualification Pattern
• SCIA Runtime
• The Enterprise Control Plane
• Constitutional Runtime Services
• Enterprise Intelligence Framework
• Platform Realisations

Pattern Navigation

Enterprise Coordination Pattern
↓
Business Domain Operational Assembly Pattern
↓
Execution Admissibility Pattern
↓
Platform Realisations

Validation

Before publishing verify:

• Execution Admissibility is consistently described as the final implementation pattern before execution.
• Proposed Operational Actions originate from Business Domain Operational Assembly.
• Qualified Operational Understanding originates from Runtime Context Assembly.
• SCIA Runtime is consistently described as the runtime reference architecture implementing the pattern.
• The Enterprise Control Plane is described as coordinating rather than implementing Execution Admissibility.
• Platform technologies are contributors rather than owners.
• The architectural progression consistently reads:

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

The completed paper establishes the Execution Admissibility Pattern as the culmination of the Enterprise Implementation Pattern catalogue, clearly separating implementation architecture from runtime architecture while positioning SCIA Runtime as the reference implementation of this constitutional runtime service.

Boundary Statement

This page is an Enterprise Implementation Pattern.

It is not the SCIA Runtime paper.

It is not a technology realisation.

It does not determine purpose, assemble context, coordinate enterprise participants or execute operational systems.

It governs whether proposed enterprise consequence is admissible before it becomes institutionally binding.

SCIA Runtime implements this governance as the public runtime reference architecture.

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