SCIA Runtime Reference Architecture

ARQUA · Pre-Execution Pressure Test · Reference Architecture · Sectors · Why Architecture First · Architecture in Practice · About Arqua · Request a Briefing

SCIA Runtime Reference Architecture

Execution Admissibility Architecture for Institutional Systems

SCIA Runtime Reference Architecture expands the Enterprise Intelligence Framework by showing how Execution Admissibility operates at runtime after the architecture has been assessed, inserted, implemented, recorded and pressure-tested.

It is the operational reference architecture stage in the adoption journey, not the primary explanation of Enterprise Intelligence.

SCIA Runtime Reference Architecture is the operational reference architecture stage in the Enterprise Intelligence transformation journey.

Enterprise Intelligence Assessment
↓
Enterprise Insertion Patterns
↓
Enterprise Implementation Patterns
↓
Architecture of Record
↓
Pre-Execution Pressure Test
↓
SCIA Runtime Reference Architecture

It is not introduced as an independent service. It describes how admissibility operates at runtime after the enterprise has identified where Enterprise Intelligence should be introduced, how the capability is realised, where the resulting architecture is recorded and whether operational readiness has been validated.

Within the three architectural views, SCIA Runtime belongs to the Operational View. It demonstrates runtime operation at the execution boundary after constitutional responsibilities have been implemented, governed through the Architecture of Record and validated through the Pre-Execution Pressure Test.

Relationship to the Enterprise Control Plane

SCIA Runtime operates within the Enterprise Control Plane.

It describes the reference runtime architecture for the constitutional Execution Admissibility responsibility.

The Enterprise Control Plane coordinates runtime services.

SCIA Runtime evaluates admissibility immediately before operational execution.

SCIA Runtime therefore remains independent of Runtime Context Assembly, Identity Resolution and Semantic Resolution while consuming outputs produced by those services.

SCIA Runtime consumes Published Enterprise Products through Runtime Context Assembly.

SCIA Runtime never determines publication.

Publication precedes Runtime Context.

Runtime Context precedes Execution Admissibility.

SCIA Runtime — Stateful Contextual Integrity Architecture (SCIA)

SCIA Runtime — Stateful Contextual Integrity Architecture (SCIA) — is the runtime control architecture within Execution Admissibility Architecture. It determines whether a proposed consequential action is admissible at T=0, before execution binds institutional consequence.

At the enterprise level, SCIA Runtime forms part of the Enterprise Execution Control Plane defined by Execution Admissibility Architecture. The Enterprise Execution Control Plane is the architectural boundary at which consequence-bearing actions resolve to a canonical typed admissibility outcome — permitted, conditional, escalated, prevented or unresolved — at T=0.

Clarification: EAA defines the discipline. AoR maps where the control plane must exist. SCIA Runtime defines the public reference runtime architecture for admissibility resolution at the commit boundary. Implementation and operation remain with the organisation and its delivery partners.

Why this matters

Most organisations govern decisions, policies, and data.

But none of these determine whether execution is allowed at the moment consequence binds.

Execution is either admissible — or it should not occur.

The Pre-Execution Pressure Test reveals where execution is uncontrolled.

The Architecture of Record defines where control must exist.

SCIA Runtime describes the reference architecture through which that control is applied at execution.

SCIA Runtime — Stateful Contextual Integrity Architecture

SCIA Runtime determines whether execution is allowed at T=0.

It governs state transitions at execution, not decisions.

It is the reference runtime control architecture derived from the Architecture of Record (AoR).

It defines how admissibility is required to resolve at the point of commit — where institutional consequence becomes binding.

Sovereignty

Sovereignty defines which constraints are binding and who has the authority to enforce them at execution.

In SCIA Runtime:

• sovereignty is explicitly declared
• authority is resolved from sovereignty at runtime
• execution is permitted only within that authority context

Authority State Resolution

SCIA Runtime treats authority as a dynamic operational state, not a static permission.

Before execution occurs, authority is required to remain coherent from the point it is established to the point it is exercised at execution.

Lifecycle-coherence evaluation, gating structures and evidence mechanics are governed separately as protected material and are not published here.

Authority Coherence and Execution Admissibility

Execution admissibility depends on authority remaining structurally coherent before irreversible execution occurs.

Authority State

Authority State is the computable operational representation of authority at a specific execution moment.

It reflects:

• delegated scope,
• thresholds,
• escalation conditions,
• runtime constraints,
• system state,
• and operational context.

Execution Admissibility Architecture evaluates authority as a dynamic operational state — not a static permission.

How this is applied

SCIA Runtime is not introduced first.

It is implemented after defining the Architecture of Record (AoR).

The AoR is typically surfaced through the Pre-Execution Pressure Test™.

The pressure test reveals where execution is uncontrolled and where control is missing at T=0.

SCIA Runtime defines how admissibility is evaluated at runtime and applied at the commit boundary.

Decision systems propose candidate actions at scale.

SCIA Runtime governs whether the corresponding state transition is permitted to execute.

Execution systems bind institutional consequence by mutating state.

Category Definition

SCIA Runtime defines how admissibility is evaluated at runtime and applied at the commit boundary.

It sits at the commit boundary of consequence, where an automated or human-initiated action would otherwise become an institutional commitment.

SCIA Runtime governs state transitions. It does not govern decisions.

It ensures that execution is not triggered by intent alone.

The Institutional Problem

The enterprise does not fail at decisioning. It fails at execution.

Enterprises separate decision generation from execution.

Decision systems propose candidate actions.

Semantic layers define what entities, obligations, and states mean.

Without a governed commit boundary, intent and recommendation can trigger consequence.

Execution without admissibility creates institutional risk.

That risk appears at the moment a transition becomes irreversible or externally consequential:

• a payment is sent
• a contract is issued
• an access right is granted
• an infrastructure change is applied
• a regulatory submission is lodged

Integrated Architecture Overview

Execution requires a governed transition from meaning to consequence.

Institutional systems require an end-to-end execution control chain, not a stronger decision engine.

This diagram shows where execution is enforced — the point where consequence would otherwise bind without control.

Proposal → meaning → decision → commit boundary → control plane → execution → consequence.

Proposal Sources

Humans, agents, workflows, and external systems that initiate proposed actions.

Semantic / Meaning Substrate

Shared definitions of entities, obligations, state, and context.

Decision Systems (Candidate Decisions)

Models, rules, and decision services that output candidate actions.

Execution Commit Boundary

Non-bypassable enforcement surface where consequence would bind.

SCIA Runtime Control Plane

The reference control architecture at which admissibility is resolved before consequence binds.

Execution Systems

Enterprise systems that execute real operations and mutate state.

Institutional Consequence

Financial, legal, operational, or regulatory commitment created by execution.

Semantic and Decision Integration

Admissibility cannot be evaluated on ambiguous meaning.

Meaning, decision, and execution must be separated to be governed.

Meaning binds reality. Decision proposes change.

Semantic = meaning

The semantic substrate defines what entities, obligations, states, and evidence mean.

Decision = proposal

Decision systems output candidate actions. Outputs remain proposals.

SCIA Runtime = admissibility at execution

SCIA Runtime requires admissibility to be re-resolved at runtime, with the typed outcome applied at the commit boundary.

👉 Meaning must bind before admissibility is computed.

This diagram separates meaning, decision, and execution so they can be governed.

Diagram — Semantic → Decision → Commit

Meaning binds before admissibility is computed.

Constraints and Meaning

Admissibility cannot be resolved on ambiguous meaning.

Ambiguity cannot cross the commit boundary.

Applicable constraints must be available in an evaluable form before admissibility can be resolved.

👉 Applicable constraints must be resolvable before admissibility is determined.

Constraint compilation methods, evaluation logic, tests and conformance criteria are governed separately as protected material and are not published here.

Diagram — Meaning → Constraint → Admissibility

Meaning must resolve into applicable constraints before admissibility is determined.

SCIA Runtime Control Plane

Admissibility must be evaluated on machine-checkable meaning, evidence, and authority at T=0.

Admissibility is evaluated at the moment an action would bind institutional consequence.

SCIA Runtime requires admissibility to be re-resolved at runtime, with the typed outcome applied at the commit boundary.

The evaluation is required to be traceable and evidenced at execution.

Authority (who can act)

Decision rights, delegation, mandated scope.

Context (when/where/conditions)

Operating conditions: timing, environment, risk posture, dependencies.

Constraints (rules, policy, limits)

Policy rules, invariants, and limits as applicable conditions.

State (eligibility to transition)

Relevant institutional state is eligible for the proposed transition.

Evidence (what supports the action)

Required evidence exists, is current, and is bound to the action and context.

SCIA Runtime defines the architecture by which system state is permitted to move forward only when integrity is proven at execution.

This diagram shows what is evaluated at T=0 to permit or block execution.

Diagram — Control Plane Detail

Reference control architecture for admissibility resolution at T=0.

Control plane responsibilities (architecture-only)

At T=0, admissibility is resolved across the canonical public categories: - Authority - Context - Constraints - State - Evidence It produces a canonical typed admissibility outcome and records the admissibility basis as evidence at execution. Detailed dimensions, evaluation rules, tests, schemas, scoring and conformance logic remain protected and are not published here. This section does not imply a specific module set, datastore, ledger technology, or operational system.

Execution Commit Boundary (T=0)

The execution commit boundary is the non-bypassable enforcement point where institutional consequence becomes binding.

Execution does not proceed without admissibility.

SCIA Runtime defines the control required at this surface.

This diagram shows the non-bypassable gate that prevents uncontrolled consequence.

Diagram — Execution Commit Boundary

All consequence-binding actions must pass through this boundary.

Typed Admissibility Outcomes

Admissibility resolution produces one canonical typed outcome.

The canonical typed outcomes are:

• Permitted
• Conditional
• Escalated
• Prevented
• Unresolved

Simplified executive framings such as “permitted or prevented” may be used only where they are labelled as executive simplifications. They do not replace the canonical typed outcomes.

Execution Passport pattern

A proposed consequence-bearing action may carry an Execution Passport: a portable authority-state artefact presenting the authority claim relevant to execution.

An Execution Passport is not sufficient by itself. The claim it presents is re-evaluated against authority, context, constraints, state and evidence at T=0.

In this pattern, the passport presents the authority claim, admissibility is resolved at the commit boundary, and the proposed action receives a canonical typed outcome.

Passport structure, payload fields, validity mechanics and lifecycle detail are governed separately as protected material and are not published here.

Related paper: The Desynchronization of Authority

Relationship to Architecture of Record (AoR)

AoR defines where consequence binds — and where control must exist.

AoR identifies where institutional consequence binds across the enterprise.

AoR defines:

• execution surfaces
• authority structures
• admissibility boundaries

SCIA Runtime defines the control required at those boundaries at the point of commit.

This diagram shows how AoR identifies bind points and SCIA enforces them at execution.

Diagram — AoR ↔ SCIA Relationship

AoR surfaces identify bind points; SCIA Runtime defines the control required at the commit boundary.

Example Execution Domains

SCIA Runtime applies wherever execution binds institutional consequence.

Common execution domains:

• Payments
• Contracts
• Infrastructure changes
• Regulatory submissions
• Entitlements / access control

Across these domains, the pattern holds: decision proposes, admissibility is evaluated at execution, execution is enforced, consequence binds.

Positioning Statement

SCIA Runtime is NOT:

• a product
• a service, managed service or Arqua-operated runtime
• a policy engine
• a rules system

SCIA Runtime IS:

• a reference architecture for execution admissibility
• the reference control architecture for institutional action at the commit boundary
• the architectural requirement for runtime integrity at consequence-bearing state transitions

SCIA Runtime defines the architectural control model through which enterprises govern consequence-binding execution.

Explore the Architecture

• Category Overview
• Overview of Execution Admissibility Architecture.
• Execution Admissibility Architecture — Architecture Map
• The architecture layers and how they relate.
• Execution Admissibility Architecture
• The architectural discipline governing admissible execution.
• Architecture of Record (AoR)
• The structural map of institutional consequence across the enterprise.
• SCIA Runtime Reference Architecture
• The runtime reference architecture for admissibility at execution.
• Pre-Execution Pressure Test
• Diagnostic that surfaces execution risk before consequence binds.
• Enterprise Insertion Patterns
• Strategic patterns identifying where Enterprise Intelligence should be introduced.
• Enterprise Implementation Patterns
• Technical patterns explaining how selected constitutional capabilities are realised.

Final statement

Execution is not governed by intent.

It is governed at the moment it becomes real.

SCIA Runtime defines the control required at the point of consequence.

Execution Admissibility Assessment

A diagnostic engagement to surface and control consequence-binding execution.

It:

• identifies workflows where execution binds institutional consequence
• locates T=0 (the commit boundary)
• exposes execution gaps and bypass paths
• defines admissibility conditions and non-bypassable control points

Document Status: Public Reference Architecture

Publication Date: 2026

Version: 1.0

Last Updated: 23 July 2026

Permanent URL: https://app.notion.com/p/2a7718d3cc5b4917b86bac84218fece0

Owner: Arqua Pty Ltd

Author: Mark Tovey

Portfolio: Enterprise Intelligence 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.

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™, Pre-Execution Pressure Test™, and associated architectural terminology may be trademarks, registered trademarks or protected intellectual property of Arqua Pty Ltd.