Canonical Definitions — Execution Admissibility Architecture

Page introduction

This page defines the core terms used across the Arqua corpus. It is intended to stabilise how Execution Admissibility Architecture, Architecture of Record, SCIA Runtime, and related concepts are understood.

Definitions table

Term	Definition	What it is not	Where it sits	Inputs	Outputs	Canonical parent	Related concepts
Arqua	The architectural category owner defining Execution Admissibility Architecture (EAA): the discipline of governing whether consequential execution is permitted to bind at T=0.	Not an implementation platform, systems integrator, or assurance body.	Category definition + reference architectures + diagnostics.	Enterprise operating context; consequence surfaces; governance intent.	Architectural definitions, reference architectures, diagnostics, and mapping patterns.	—	EAA; AoR; SCIA Runtime; Pressure Tests; Structural Context Library.
Enterprise Bridge	A translation and alignment construct that maps an established enterprise discipline, framework, standard, regulatory context, platform pattern, or sector practice into Execution Admissibility Architecture, showing where existing governance remains necessary and where consequence-binding execution must be controlled at T=0.	Not an official extension, certification, endorsement, compliance mapping, legal opinion, implementation guide, or formal representation of any external framework, standard, regulator, or vendor platform.	Between existing enterprise governance disciplines and Arqua’s EAA/AoR/SCIA Runtime architecture corpus.	External framework or discipline; governance artefacts; architecture artefacts; controls; workflows; system patterns; sector context; consequence-bearing workflow candidates.	Bridge note; alignment questions; execution-admissibility gap analysis; artefact mapping; Pressure Test candidates; AoR baseline prompts; implementation-boundary guidance.	Arqua	EAA; AoR; SCIA Runtime; Pre-Execution Pressure Test; Structural Context Library; execution surface; T=0; evidence at execution.
Execution Admissibility Architecture (EAA)	The architecture discipline governing the boundary between decision, admissibility, and execution, with the invariant: no state transition without proven integrity at the commit boundary.	Not decision governance; not post-hoc audit; not an “AI policy” document.	Category-level architecture above systems and delivery.	Authority models; operating policies; execution surfaces; constraints; context requirements.	Admissibility model, control points, and runtime enforcement patterns.	Arqua	AoR; SCIA Runtime; admissibility vector; institutional commit boundary; evidence at execution.
Execution admissibility	The determination that a proposed consequential action is permitted to execute at T=0, given resolved authority, constraints, state, context, and evidence.	Not “approval” as a UI step; not a retrospective justification; not a best-effort control.	Runtime decision at the commit boundary.	Authority state; constraints; contextual signals; evidence; current system state.	Typed admissibility outcome (permit / deny / hold / escalate) and associated evidence trail.	EAA	T=0; institutional consequence; SCIA Runtime; evidence at execution; context at execution.
T=0	T=0: The institutional commit boundary: the moment a proposed action becomes consequence-binding execution. In distributed systems, a workflow may contain multiple T=0 boundaries, each tied to a distinct consequence class or irreversible state transition.	Not the time a decision is made; not a review meeting; not a policy publication moment.	Commit boundary of consequence-binding execution.	Proposed action; current authoritative state; required proofs.	Consequence-binding state transition (or refusal to transition).	EAA	Institutional commit boundary; execution surface; SCIA Runtime; evidence at execution.
Institutional consequence	The durable organisational outcome produced when an action binds (e.g., funds move, a contract commits, access changes, a record becomes authoritative).	Not “impact” in the abstract; not analytics; not internal intention.	Downstream of execution; the reason admissibility exists.	Execution events; institutional systems of record; obligations.	Committed state, obligation, entitlement, liability, access, or record truth.	EAA	Consequence system; execution surface; commit boundary; AoR.
Institutional commit boundary	The boundary where an execution system transitions a state that binds institutional consequence (the “commit” surface).	Not a business approval workflow; not a governance committee; not a documentation gate.	Runtime boundary inside execution systems.	Action intent; admissibility outcome; proofs; constraints.	Committed state transition (or rejection/hold).	EAA	T=0; execution surface; consequence system; SCIA Runtime.
Execution surface	Any interface, workflow, API, event, or mechanism through which a system can perform a consequence-binding action.	Not a “feature”; not only user interfaces; not only AI models.	Located and mapped by AoR; governed by EAA.	System interfaces; triggers; service boundaries; permissions.	Identified control points requiring admissibility enforcement.	AoR	AoR; commit boundary; consequence systems; pressure tests.
Consequence system	A system whose state transitions create institutional consequence (payments, entitlements, contracts, identity/access, regulatory records, critical infrastructure operations).	Not a dashboard or reporting layer; not a sandbox.	Downstream execution domain where consequence is committed.	Execution requests; admissibility outcomes; authoritative state.	Committed changes and records of consequence.	AoR	Institutional consequence; execution surface; commit boundary; evidence at execution.
Architecture of Record (AoR)	The mapping layer that defines where consequence binds and where execution control must exist, linking enterprise operating intent to concrete execution surfaces.	Not a documentation library; not an enterprise architecture “as-is/to-be” deck; not a CMDB.	Between category discipline (EAA) and runtime enforcement (SCIA Runtime).	Business capabilities; consequence systems; workflows; integration topology; authority chains.	Authoritative map of consequence surfaces and required control points.	EAA	Execution surfaces; commit boundaries; SCIA Runtime placement; pressure tests.
SCIA Runtime	SCIA Runtime — Stateful Contextual Integrity Architecture — 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.	Not “decision governance”; not a model; not a policy document; not an implementation product claim.	Runtime enforcement layer at/near the commit boundary.	Authority state; constraints; context; evidence; current operational state.	Admissibility outcomes + enforced execution allow/deny/hold + provenance.	EAA	Admissibility vector; evidence at execution; constraint compilation; authority lifecycle integrity.
Stateful Contextual Integrity Architecture	The underlying architectural concept (expanded name) for SCIA Runtime: integrity is proven in-state, in-context, at the moment execution would bind consequence.	Not “sovereign coherent intelligence”; not a general AI architecture.	Definition level inside SCIA Runtime.	Operational state; contextual signals; proofs.	Integrity-gated state transition permissions.	SCIA Runtime	State at execution; context at execution; evidence at execution; T=0.
Admissibility Vector	The defined set of required dimensions that must resolve before a consequence-binding state transition is permitted.	Not a checklist for humans; not an after-action audit framework.	Core construct inside EAA/SCIA Runtime.	Authority; state; constraints; context; evidence.	Vector resolution result (admissible / not admissible / conditional) with justification.	EAA	Authority; constraint compilation; evidence/context/state at execution.
Authority	The legitimate institutional basis by which an actor or system is permitted to cause a specific consequential action.	Not “role-based access” alone; not informal influence; not system capability.	One axis of the admissibility vector.	Mandates; delegations; policies; approvals; accountabilities.	Authority claims + required proofs at execution.	EAA	Authority state; authority lifecycle integrity; authority drift; AoR.
Authority State	The current, runtime-resolved status of authority for a proposed action (valid/invalid/expired/superseded/conditional), computed from authoritative sources and context.	Not a static permission grant; not an org chart.	Runtime resolution inside SCIA Runtime.	Delegations; entitlements; constraints; context; evidence.	Resolvable authority outcome used for admissibility at T=0.	SCIA Runtime	Authority; state at execution; context at execution; evidence at execution.
Authority Lifecycle Integrity	The end-to-end integrity of authority as it is created, delegated, interpreted, exercised, and evidenced—such that execution can prove legitimacy at T=0.	Not “governance process maturity”; not policy intent without enforceable binding.	Governance + architecture construct supporting SCIA Runtime.	Mandates; delegations; records; constraints; execution evidence patterns.	Provenance, lineage, and enforceable authority semantics.	EAA	Authority drift; evidence at execution; AoR; constraint compilation.
Authority Drift	The divergence between intended authority and effective authority as systems, teams, vendors, or automation pathways change over time.	Not “bad actors”; not only a training problem; not a monitoring metric by itself.	Risk pattern diagnosed by pressure tests and mitigated by EAA/SCIA Runtime.	System changes; policy changes; automation pathways; vendor layers.	Uncontrolled execution surfaces; misaligned authority states.	Authority Lifecycle Integrity	Pressure tests; AoR; evidence/context at execution.
Constraint Compilation	The process of assembling and resolving the constraints that must hold for a proposed action to be admissible at T=0 (policy, rules, thresholds, prohibitions, conditions).	Not “policy documentation”; not model prompt rules; not informal guidelines.	Runtime support function inside SCIA Runtime.	Policies; rules; contracts; regulatory constraints; state constraints.	Executable constraint set used in admissibility evaluation.	SCIA Runtime	Constraints; evidence at execution; context/state at execution.
Evidence at execution	The proofs produced and captured at T=0 demonstrating that admissibility conditions were met (or not met) for a specific execution attempt.	Not post-hoc narrative; not a compliance report template.	Output of SCIA Runtime at commit boundary.	Logs, attestations, signatures, lineage, resolved context/state snapshots.	Audit-grade trace of admissibility evaluation and enforcement outcome.	SCIA Runtime	Execution admissibility assurance; institutional commit boundary; context/state at execution.
Context at execution	The runtime contextual inputs required to evaluate admissibility (who/what/where/when, jurisdiction, purpose, current conditions, surrounding system state).	Not “background information” for a decision meeting; not a static form field.	One axis supporting admissibility at T=0.	Signals, environment, jurisdictional parameters, workflow context.	Resolved context snapshot used in admissibility evaluation.	SCIA Runtime	Constraints; state at execution; evidence at execution.
State at execution	The authoritative operational state relevant to the proposed action at the moment of commit (including prior transitions and current entitlements/obligations).	Not a database record in isolation; not a plan; not a future intention.	One axis supporting admissibility at T=0.	System-of-record state; workflow state; authority state; constraint state.	Resolved state snapshot used for admissibility evaluation.	SCIA Runtime	Operational state architecture; evidence at execution; institutional consequence.
Pre-Execution Pressure Test	A diagnostic that reveals where execution is currently uncontrolled by mapping the surfaces where automated or human decisions can bind consequence without an admissibility boundary.	Not penetration testing; not an implementation audit; not assurance certification.	Diagnostic entry point into AoR/EAA work.	A selected high-consequence workflow; stakeholders; system topology.	Execution topology + identified uncontrolled execution surfaces + control-point candidates.	Arqua	AoR; execution surface; authority drift; consequence systems.
Execution Admissibility Assurance	The ability to demonstrate, with evidence generated at T=0, that consequence-binding actions only executed when admissibility resolved.	Not a regulatory certification; not a claim that systems are compliant by definition.	Outcome posture enabled by EAA/SCIA Runtime patterns.	Evidence at execution; admissibility outcomes; control-point mapping.	Demonstrable execution integrity trail suitable for oversight and review.	EAA	Evidence at execution; authority lifecycle integrity; AoR.
Enterprise Execution Control Plane	The enterprise-level architectural control boundary, defined by Execution Admissibility Architecture, through which an organisation determines whether a proposed consequence-bearing action is admissible at T=0 before it binds institutional consequence. It resolves authority, state, context, constraints, risk, and evidence at or before the institutional commit boundary.	Not a software platform, orchestration layer, observability tool, policy engine, AI governance dashboard, model evaluation framework, managed service, compliance certification, legal assurance, or implementation product.	Between the category discipline and operational implementation. Execution Admissibility Architecture defines it. Architecture of Record maps where it must exist. SCIA Runtime defines the reference runtime architecture for admissibility resolution at the commit boundary.	Execution surfaces; authority chains; operational state; semantic context; policy constraints; risk conditions; evidence requirements.	Admissibility control model; required control points; admissibility outcomes; evidence at execution; and implementation boundaries for delivery partners.	Execution Admissibility Architecture (EAA)	EAA; AoR; SCIA Runtime; T=0; institutional commit boundary; admissibility vector; evidence at execution; Execution-Bound Enterprise.
Structural Context Library	A library of recurring authority and consequence patterns observed across sectors, used to accelerate diagnosis and architectural design.	Not a control catalogue; not a compliance standard.	Supporting knowledge base for Arqua diagnostics and architecture.	Sector patterns; authority archetypes; consequence-binding motifs.	Reusable patterns and diagnostic lenses.	Arqua	Authority pattern; pressure tests; AoR.
Authority pattern	A recurring structural configuration of mandate, delegation, accountability, and execution surfaces that determines how authority actually binds in an operating environment.	Not an org chart; not a job description.	Pattern unit within the Structural Context Library.	Observed workflows; governance artefacts; system boundaries.	Pattern description usable for diagnosis and design.	Structural Context Library	Authority lifecycle integrity; authority drift; consequence systems.
AI-Ready Enterprise Semantics	The semantic preparation of enterprise meaning (definitions, types, relationships, decision vocabularies) so automated and human systems share stable interpretation.	Not prompt engineering; not a data lake; not a taxonomy project alone.	Upstream prerequisite feeding EAA/SCIA Runtime.	Business definitions; policy intent; domain models; metadata.	Shared semantic layer that stabilises meaning across systems and time.	Arqua	Meaning and coherence; operational state architecture; constraint compilation.
Operational State Architecture	The architecture of how operational states are represented, transitioned, and proven across systems—so state at execution can be resolved reliably at T=0.	Not a single database schema; not a workflow diagram.	Foundational architecture supporting admissibility evaluation.	State models; transitions; system-of-record design; provenance.	Resolvable, authoritative state snapshots and transition semantics.	EAA	State at execution; evidence at execution; AoR.
Execution-Bound Enterprise	An enterprise posture where decisions may be distributed and exploratory, but execution is governed: consequence binds only through admissible state transitions at T=0.	Not centralised decision-making; not “slower governance”.	Operating model outcome enabled by EAA + AoR + SCIA Runtime.	Mapped execution surfaces; admissibility controls; semantic prerequisites.	Reduced uncontrolled execution; durable accountability; evidence at execution.	EAA	T=0; institutional consequence; AoR; SCIA Runtime.
Sovereign AI	AI governance framing concerned with jurisdictional control, public-sector authority, and national sovereignty constraints on AI-driven decisions and execution.	Not a claim of sovereign coherent intelligence; not a guarantee of national control by default.	Context framing that may shape constraints, authority, and context at execution.	Jurisdictional policies; security/assurance requirements; cross-border constraints.	Sovereignty-aligned constraint and governance requirements.	Arqua	Jurisdiction-aware controls; constraints; authority; government contexts.

Enterprise Bridges are not canonical definitions of external frameworks. They are Arqua-authored translation and alignment notes that help established enterprise disciplines identify where execution-admissibility questions arise.

Canonical admissibility vector

The canonical execution admissibility vector consists of authority, state, constraints, context, and evidence.

Related paper concepts

Term	Definition
Execution Attribution Collapse	A failure mode in which a consequential action can be technically executed and procedurally logged, but the institution cannot reconstruct a defensible chain connecting authorised judgment to evidence, interpretation, system transformations, permissions, and execution at T=0.
Execution Passport	A portable authority-state bundle carried with a proposed consequential action. It presents the authority claim, scope, context, constraints, evidence, validity conditions, expiry, and escalation requirements needed for SCIA Runtime to determine execution admissibility at T=0. It is not itself an approval, permission grant, product, or guarantee of admissibility.
Alignment Architecture	A three-layer architectural model connecting Meaning, Execution, and Admissibility to preserve coherent action in AI-mediated systems. It treats alignment as architectural continuity between originating intent and consequential execution, and positions admissibility as the control boundary at T=0 where consequence-bearing action is permitted or refused.
Meeting-to-runtime gap	The gap between a point-in-time human decision or approval and downstream execution under changed authority, evidence, state, context, policy, or consequence conditions.

Note: Authority decay is discussed in Arqua papers as a time-sensitive form of Authority Drift. Use Authority Drift as the canonical site term.

Meaning and coherence note

Meaning and coherence are semantic prerequisites. They support admissibility, but do not replace the execution admissibility vector.

Architecture relationship diagram (text)

Decision systems propose.
AoR maps where consequence binds.
SCIA Runtime evaluates admissibility at T=0.
Execution systems bind consequence only if admissibility resolves.

Boundary statement

These definitions describe architectural concepts. They do not assert legal compliance, regulatory certification, assurance, system operation, or implementation.