The Desynchronization of Authority

Arqua Architecture Paper

Version 1.0 | May 2026

Companion evidence note

The architecture paper defines the problem: execution-connected AI can separate evidence, interpretation, authority, execution, and accountability across time.

We have also published a companion note mapping recent public incidents, disputes, and governance warnings to the same pattern.

These examples show why prior approval, technical permission, human involvement, and retrospective audit are not enough when AI-mediated systems can bind institutional consequence.

Read Public Signals of Execution Attribution Collapse

Executive summary

Most organisations govern decisions. Very few govern execution. AI-mediated systems make that gap consequential.

This paper explains the institutional failure mode that emerges when point-in-time authority is treated as continuously valid while AI-mediated systems execute later, faster, and under changed runtime conditions.

It introduces three terms intended to become part of Arqua’s public architecture language: Execution Attribution Collapse, the Execution Passport pattern, and the meeting-to-runtime gap. The paper also explains why execution-connected AI requires Execution Admissibility Architecture (EAA) at T=0: the institutional commit boundary where proposed action becomes consequence-binding execution.

EAA is the discipline. Architecture of Record (AoR) maps where consequence binds. SCIA Runtime evaluates admissibility at the commit boundary using authority, evidence, context, constraints, and state. The Pre-Execution Pressure Test identifies where execution is currently uncontrolled.

How this relates to Arqua

• Execution Admissibility Architecture (EAA) is the category and discipline.
• Architecture of Record (AoR) maps where institutional consequence binds and where control must exist.
• SCIA Runtime evaluates admissibility at the commit boundary, T=0.
• The Pre-Execution Pressure Test identifies where execution is currently uncontrolled.
• The Execution Passport is a pattern introduced by this paper to explain how authority-state must travel to T=0 so SCIA Runtime can validate or refuse execution.

The Execution Passport does not itself grant execution. It presents the authority claim. SCIA Runtime validates or refuses that claim at the institutional commit boundary.

Integration note

Execution Admissibility Architecture does not replace identity, workflow, policy, audit, observability, operational resilience, model-risk, or GRC disciplines. Those controls remain necessary. Arqua’s claim is narrower: execution-connected AI requires those disciplines to converge around a specific architectural question at the moment consequence binds — is this proposed action institutionally admissible at T=0?

Key concepts introduced

Execution Attribution Collapse — when an institution can prove that process occurred, but cannot reconstruct a defensible chain from authorised judgment to consequence-binding execution.

Execution Passport — a portable authority-state bundle that presents an execution authority claim for SCIA Runtime validation at T=0.

Meeting-to-runtime gap — the gap between point-in-time decision authority and downstream execution under changed authority, evidence, state, context, policy, or consequence conditions.

Read this if

Read this paper if you are responsible for AI governance, enterprise architecture, operational risk, model risk, procurement governance, cybersecurity operations, board assurance, compliance architecture, transformation, or consequence-bearing automation.

Table of contents

• Companion evidence note
• Executive summary
• How this relates to Arqua
• Key concepts introduced
• Read this if
• Table of contents
• A concrete failure scenario
• The central thesis
• Scope: execution-connected AI
• The meeting-to-runtime gap
• AI compresses the time available to repair authority gaps
• Synthesised cognition and synthetic synchronization
• Execution Attribution Collapse
• Existing controls are necessary but incomplete
• Relationship to existing controls
• Execution admissibility at T=0
• Proportionality
• The Execution Passport pattern
• Security and trust note
• What the Execution Passport must carry
• SCIA Runtime and the commit boundary
• T=0 in distributed systems
• Governed asynchrony
• Examples
• How institutions should start
• Core definitions
• Boundary statement
• Reference context
• Appendix A. Short positioning version
• Related Arqua pages
• Download the paper
• Use this paper to start a conversation
• CTA

A concrete failure scenario

At 10:00 a.m., a risk committee approves a supplier recommendation. The decision is based on an AI-generated risk summary, vendor due-diligence data, sanctions screening, contract value, operational need, and a set of assumptions about delivery urgency and risk exposure.

The approval is not absolute. It is conditional, even if the conditions are not fully written down. It depends on the supplier being within scope, the evidence remaining current, the contract value staying within threshold, the risk posture remaining acceptable, and the committee members acting within the authority capacity they held at the time of approval.

At 3:47 p.m., an AI-enabled procurement workflow releases a purchase order. By then, the contract value has changed, new vendor information has entered a downstream system, and the supplier risk profile is no longer identical to the state reviewed by the committee.

The ERP system shows approval. The AI system has logs. The workflow shows that the correct user clicked the correct button. The meeting minutes exist. But the institution cannot prove that the approval still applied to the action that bound the organisation.

This is not a simple logging failure. It is not only an explainability failure. It is not solved by showing that a human was involved. The institution can prove that process occurred. It cannot prove that legitimate authority remained attached to execution.

Arqua calls this Execution Attribution Collapse.

The central thesis

For execution-connected AI, governance fails when evidence, interpretation, authority, execution, and accountability no longer refer to the same decision state.

The core problem is not that humans now outsource cognition. Humans have always relied on distributed cognition: experts, institutions, advisers, tools, records, procedures, committees, auditors, maps, markets, courts, and systems. Enterprise has always worked by distributing cognition across roles and artefacts.

The shift is that AI turns distributed cognition into synthetic, asynchronous, executable cognition. It can retrieve, summarise, interpret, recommend, transform, plan, and act at a speed and scale that separates the decision event from the execution event.

This changes the governance question. It is no longer enough to ask: Was this approved? Was there a human in the loop? Was the model explainable? Was there an audit trail? Those questions remain necessary, but they are incomplete.

The harder question is: Did legitimate authority remain attached to the action at the moment consequence bound?

Scope: execution-connected AI

This paper is not about every AI interaction. It is not primarily concerned with low-risk summarisation, drafting, search, brainstorming, or internal productivity tools where outputs remain advisory and do not bind institutional consequence.

It is concerned with AI-mediated systems that can cause, materially shape, accelerate, or authorise consequential enterprise action. These include actions involving payments, contracts, procurement commitments, access changes, infrastructure changes, compliance determinations, customer-impacting decisions, employee-impacting decisions, legal workflow actions, risk decisions, regulatory submissions, and operational state transitions.

In these environments, the relevant governance problem is not only whether the model is accurate, safe, fair, explainable, or monitored. It is whether the institution can prove that execution was admissible at the moment it occurred.

The meeting-to-runtime gap

Enterprise authority is not created only in meetings. It is also expressed through policies, delegated mandates, operating procedures, risk appetite statements, committee charters, contracts, access controls, workflow approvals, system permissions, board resolutions, and regulatory obligations.

Meetings matter because they reveal a deeper pattern: institutions authorise action by creating point-in-time decision states. A meeting, approval workflow, committee review, exception process, or executive sign-off binds evidence, assumptions, interpretation, authority, scope, risk, and intended action into a decision state.

Traditional governance assumes that this decision state remains valid long enough for execution to occur. That assumption is increasingly fragile.

A decision state can decay when evidence changes, assumptions expire, policy changes, risk thresholds shift, scope expands, delegation changes, operating context changes, system state changes, or the action proposed at runtime diverges from the action authorised earlier.

This is the 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.

Authority decay should be understood as a time-sensitive form of Authority Drift.

The question is not only whether authority existed, but whether it still existed for this action, in this state, at this boundary.

AI compresses the time available to repair authority gaps

The gap between decision and execution is not new. Organisations have always suffered from incomplete information, vague action items, stale approvals, undocumented assumptions, political framing, missing stakeholders, side-channel decisions, weak minutes, delayed escalations, and post-meeting reinterpretation.

AI does not invent these problems. It accelerates them.

In slower organisations, misunderstandings could often be caught through follow-up calls, human hesitation, manual review, delayed execution, informal escalation, or operational friction. There was slack in the system.

AI-mediated execution removes that slack. It can scale a decision before ambiguity is resolved. It can transform a meeting output into operational action faster than humans can contest the transformation. It can act before the institution has re-synchronised around changed evidence or changed risk.

The institution may retain the appearance of governance: a meeting occurred, approval was recorded, minutes were produced, a workflow advanced, an audit trail exists. But the deeper question remains unresolved: did the authority granted earlier survive to the moment of execution?

Synthesised cognition and synthetic synchronization

AI systems do not merely automate tasks. They synthesise cognition. They compress evidence, context, uncertainty, and reasoning into action-ready outputs: summaries, recommendations, risk scores, rankings, generated reports, executive briefs, semantic dashboards, workflow suggestions, autonomous plans, and agentic execution proposals.

This can be valuable. Synthesised cognition can reduce noise, reveal patterns, improve consistency, accelerate review, and support better decision-making. But it becomes dangerous when it replaces reconstructable judgment.

A committee may approve the coherence of a generated summary rather than the evidence beneath it. A board may align around a generated risk narrative without knowing which assumptions were suppressed. A reviewer may approve a decision packet without understanding which evidence was decisive. A workflow may treat a generated recommendation as a decision when it is only a proposal.

AI also creates synthetic synchronization: the appearance of shared understanding when humans align around the same machine-generated abstraction without reconstructing the evidence, context, or authority chain beneath it.

The danger is not that AI creates coherence. Institutions need coherent artefacts to act. The danger is that coherence may be mistaken for legitimacy. A meeting can be aligned and wrong. A dashboard can be fluent and incomplete. A generated report can be plausible and unauthorised. An approval can be visible and hollow.

Execution Attribution Collapse

Execution Attribution Collapse occurs when a consequential action can be technically executed and procedurally logged, but the institution cannot reconstruct a defensible chain connecting authorised judgment to the evidence, interpretation, system transformations, permissions, and execution event that produced the outcome.

It is not the absence of logs. It is the absence of reconstructable authority.

Execution Attribution Collapse can occur while systems still function, approvals still exist, dashboards still show status, policies still appear active, humans still appear involved, and audit trails still record events. The organisation can show that a process occurred. It cannot prove that legitimate judgment survived through the process.

The collapse is most visible after failure, but it forms earlier. It forms when the operative interpretation moves into a system the institution cannot reconstruct, when approval is treated as timeless, when technical permission exceeds institutional permission, when evidence is compressed beyond contestability, or when accountability remains formally assigned to people who no longer had meaningful control.

This failure has four recurring separations:

• Cognition separates from authority.
• Authority separates from execution.
• Execution separates from evidence.
• Accountability separates from causality.

Existing controls are necessary but incomplete

The argument is not that existing governance is useless. Policies, approvals, human oversight, model-risk governance, logging, monitoring, IAM, privileged access management, change controls, segregation-of-duties controls, GRC tooling, and audit practices all remain necessary.

Execution Admissibility Architecture is not a replacement for IAM, policy engines, workflow tooling, GRC systems, audit practices, observability, model-risk governance, or operational resilience. It adds a runtime control question at the commit boundary: whether a specific proposed action is admissible to execute under current authority, evidence, context, constraints, and state.

The issue is that many existing controls prove that a process, role, system, or event existed. They may not prove that a specific action remained institutionally admissible at the moment it crossed the commit boundary.

Relationship to existing controls

Execution Admissibility Architecture does not replace IAM, privileged access management, workflow engines, policy-as-code, model-risk governance, observability, audit, operational resilience, or GRC tooling. These disciplines remain necessary and may provide important implementation substrates.

Arqua’s claim is narrower: execution-connected AI requires these controls to converge around a specific runtime question at the consequence boundary. Is this proposed action institutionally admissible now, given current authority, evidence, context, constraints, state, and consequence conditions?

Identity and access controls can help establish who or what may act. Policy engines can evaluate rules. Workflow tools can sequence approvals. Logs can record events. Observability can detect behaviour. Audit can review outcomes. Execution Admissibility Architecture defines the missing control point where these signals are resolved into an admissibility determination before consequence binds.

Current governance frameworks increasingly recognise the need for lifecycle risk management, accountability, transparency, human oversight, monitoring, and logging. Arqua does not replace those obligations. It operationalises a specific missing control point: execution admissibility at T=0.

Execution admissibility at T=0

Execution admissibility is the determination that a proposed consequential action is permitted to execute at T=0, given resolved authority, constraints, state, context, and evidence.

In distributed systems, there may be multiple commit boundaries where consequence can bind. T=0 should be understood as the relevant commit boundary for a specific action pathway (for example, order submission, payment initiation, privilege grant, infrastructure change, or regulatory filing), not as one universal instant across the enterprise.

T=0 is the institutional commit boundary: the moment a proposed action becomes consequence-binding execution. This is where governance must become operational. Before T=0, the action is a proposal. At T=0, it either becomes admissible execution, escalates, refuses, or remains unresolved.

Execution admissibility asks a different question from conventional approval. Not: was this approved earlier? Not: can the system technically do this? Not: can the model explain its output? But: is this action allowed to bind consequence now?

At T=0, a consequence-binding action must be admissible across the canonical vector:

• authority
• evidence
• context
• constraints
• state
• consequence

Proportionality

Execution admissibility should be proportionate to consequence. Not every action requires the same level of runtime control. Low-consequence, reversible, or advisory actions may require lightweight evidence, monitoring, or logging. High-consequence, irreversible, regulated, financial, legal, safety-related, customer-impacting, employee-impacting, or infrastructure-changing actions require stronger admissibility controls.

The goal is not to block execution by default. The goal is to prevent consequence-bearing execution from proceeding where authority, evidence, state, context, or constraints cannot be established at the required level of assurance.

Execution admissibility is not governance as paperwork. It is governance as runtime architecture.

Execution admissibility should be proportionate to consequence. The admissibility burden should vary with the consequence class, reversibility of the action, uncertainty in the evidence or interpretation, and the risk of harm if execution proceeds under an invalid authority state.

The Execution Passport pattern

The runtime authority object can be explained publicly as an Execution Passport.

An Execution Passport is 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.

The passport metaphor matters because it separates possession from admission. A passport does not guarantee entry. It presents a claim for validation. The border authority checks the passport against identity, issuer, validity, destination, restrictions, current rules, revocation status, and conditions of entry.

The same logic applies to consequence-binding execution. The Execution Passport does not itself grant execution. It is not a generic approval token. It is not a blanket permission. It is not a product claim. It is an architectural pattern for making authority-state portable, checkable, expirable, revocable, escalatable, and reconstructable.

Because it carries authority claims and evidence references into execution pathways, the Execution Passport creates its own security and trust obligations. It must be protected against tampering, replay, unauthorised issuance, and inappropriate reuse across contexts, and it must support revocation, expiry, and reconstruction in ways that remain auditable.

SCIA Runtime is the validator. The commit boundary is the border. The evidence-at-execution record is the stamped travel record. The proposed action is admitted, refused, escalated, or held as insufficiently evidenced.

Security and trust note

Execution Passports introduce their own trust requirements. Any implementation must protect against forgery, replay, substitution, stale reuse, over-disclosure of sensitive evidence, side-channel leakage, and bypass of the commit boundary.

The passport should be treated as a verifiable authority-state claim, not a bearer permission. Where evidence is sensitive, implementations may use references, hashes, attestations, controlled evidence access, or evidence-minimisation patterns rather than carrying raw sensitive content directly.

What the Execution Passport must carry

The Execution Passport is a pattern, not a schema disclosure. At the architectural level, it should carry enough information for SCIA Runtime to determine whether execution is admissible at T=0 and enough evidence for the institution to reconstruct why the decision was permitted, refused, escalated, or left unresolved.

At a minimum, the public pattern includes:

• Decision reference
• Authority capacity
• Authorised scope
• Evidence basis
• Assumptions and conditions
• Policy and constraint basis
• Validity and expiry
• Consequence class
• Escalation requirement
• Reconstruction path

The purpose is not to encode every nuance of human judgment. The purpose is to capture the minimum authority conditions required to determine whether a downstream action remains within the scope of what was authorised.

Where those conditions cannot be established, execution should not proceed as though authority exists. The appropriate outcome may be refusal, escalation, re-resolution, or insufficient information.

SCIA Runtime and the commit boundary

Architecture of Record identifies where institutional consequence binds and where control must exist. SCIA Runtime evaluates whether proposed execution is admissible at those boundaries.

In the passport metaphor, SCIA Runtime is not the passport. It is the border authority. It validates the authority claim carried by the Execution Passport against current authority, evidence, context, constraints, state, and consequence conditions at T=0.

This produces typed outcomes rather than a single binary approval. A proposed action may be admissible, admissible with conditions, escalated, not admissible, or unresolved because required information is insufficient.

Decision systems propose. SCIA Runtime evaluates. The commit boundary admits or refuses. Consequence binds only when admissibility is resolved at T=0.

T=0 in distributed systems

T=0 should not be understood as a single universal instant across the whole enterprise. In distributed systems, consequence may bind through multiple commit boundaries: approval release, payment initiation, access change, contract formation, regulatory submission, infrastructure mutation, customer notification, entitlement change, or irreversible state transition.

Architecture of Record identifies those boundaries. SCIA Runtime evaluates admissibility wherever a proposed transition becomes consequence-bearing. A long-running workflow may therefore contain multiple T=0 points, each requiring its own authority, evidence, state, context, constraint, and consequence evaluation.

This avoids treating T=0 as an idealised single transaction. It treats T=0 as an architectural boundary class: the point at which a specific consequence becomes institutionally binding.

Governed asynchrony

The answer is not to eliminate asynchronous work. Modern institutions require parallel analysis, delegation, automation, independent review, delayed execution, and distributed human-machine cognition.

The goal is governed asynchrony: an architecture that permits distributed cognition while preserving the conditions required for legitimate action.

Governed asynchrony requires:

• Evidence continuity
• Context continuity
• Authority continuity
• Permission integrity
• Semantic coherence
• Consequence awareness
• Reconstructive capacity

Examples

Procurement: A committee approves a supplier. Later, procurement executes after vendor risk, contract value, or sanctions context has changed.

Cybersecurity: A security agent recommends remediation during an incident. Later, the agent executes under changed infrastructure conditions and disrupts production.

Finance: A human approves a packet, but the institution cannot prove the reviewer had reconstructable access to decisive evidence and uncertainty.

Infrastructure: An operations system initiates containment and triggers unintended consequence; commands are reconstructable, but legitimacy is not.

Board governance: A board approves an AI-generated strategic narrative; later the institution discovers suppressed uncertainty or stale assumptions.

How institutions should start

The practical starting point is not a full-enterprise transformation. It is one high-consequence workflow.

Select a workflow where AI, automation, or enterprise platforms can materially shape a consequence-bearing action: payment, claim, contract, entitlement, access change, infrastructure change, regulatory filing, procurement commitment, or customer-impacting decision.

Then ask:

• Where exactly does consequence bind?
• What is the T=0 commit boundary?
• What authority is assumed at that boundary?
• What evidence must be current at that boundary?
• What state, context, and constraints must hold?
• What happens if authority, evidence, or state cannot be proven?
• Can the institution reconstruct the admissibility basis after the fact?
• Does any system have technical permission to act where institutional authority has not been resolved?

This is the role of the Pre-Execution Pressure Test. It surfaces uncontrolled execution, implicit authority, stale approvals, evidence gaps, semantic divergence, and commit boundaries before consequence binds.

Core definitions

Execution Admissibility Architecture (EAA): The runtime architecture discipline that determines whether consequential enterprise actions are allowed to bind at T=0.

Architecture of Record (AoR): The architectural map of where consequence binds, where authority must exist, and where execution control must be located.

SCIA Runtime: The runtime reference architecture that re-resolves admissibility at the commit boundary using authority, evidence, context, constraints, and state.

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.

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.

Runtime authority object: The underlying machine-readable representation of the decision-state and authority-state conditions carried by the Execution Passport pattern.

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.

Authority Drift: Divergence between intended authority and effective authority as systems, teams, vendors, data, automation pathways, or runtime conditions change over time.

Authority decay: A time-sensitive form of Authority Drift in which an approval becomes stale as evidence, assumptions, state, risk, or consequence conditions change.

Synthesised cognition: Machine-mediated interpretation that compresses evidence, context, uncertainty, and reasoning into action-ready outputs.

Synthetic synchronization: The appearance of shared understanding created when humans align around the same machine-generated abstraction even if the underlying evidence, reasoning, or authority chain remains fragmented.

Execution Attribution Collapse: A condition in which execution remains technically functional 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.

Governed asynchrony: An architecture that permits distributed human-machine cognition while preserving evidence continuity, context continuity, authority continuity, permission integrity, semantic coherence, consequence awareness, and reconstructive capacity.

Boundary statement

This paper describes architectural concepts and diagnostic patterns. It does not constitute legal advice, regulatory assurance, compliance certification, audit opinion, system implementation, operational control, platform selection, or professional advice.

Arqua operates at the architecture and governance layer. It defines architecture-of-record boundaries for meaning, authority, accountability, and execution admissibility. Runtime behaviour, system execution, regulatory compliance, operational risk, and implementation decisions remain the responsibility of the deploying organisation and its chosen delivery partners.

The Execution Passport is presented as a public explanatory pattern for authority-state validation at T=0. It is not a product claim, implementation design, schema disclosure, software module, managed service, or compliance guarantee.

Reference context

This paper is intended to sit alongside, not replace, existing AI governance, risk, assurance, security, and management-system approaches. Its contribution is the execution-admissibility control point: the requirement to prove that a specific consequence-bearing action remains authorised at T=0.

Relevant reference context includes NIST AI Risk Management Framework, ISO/IEC 42001 AI management systems, EU AI Act high-risk AI requirements including logging and human oversight, OWASP GenAI and agentic application security work, and enterprise risk, model-risk, audit, identity, access, operational resilience, and change-control practices.

Arqua’s contribution is not to replace these disciplines, but to define the execution-admissibility control point where their signals must be resolved before consequence binds.

These frameworks define important obligations and practices. Arqua adds a runtime architecture question: when a proposed action is about to bind consequence, can the institution prove that authority, evidence, context, constraints, and state make execution admissible?

Appendix A. Short positioning version

Most organisations govern decisions. Very few govern execution.

AI-mediated systems widen the gap between the moment authority is granted and the moment consequence binds. A committee may approve one state of the world. An AI-enabled workflow may later execute against another. The audit trail may show approval, but the institution may not be able to prove that authority survived to execution.

Arqua calls this the Desynchronization of Authority.

The failure mode is Execution Attribution Collapse: process remains visible, systems remain functional, and logs remain available, but the institution cannot reconstruct a defensible chain from authorised judgment to consequence-binding execution.

The architectural answer is Execution Admissibility Architecture. AoR maps where consequence binds. SCIA Runtime evaluates admissibility at T=0. The Execution Passport carries the authority-state claim that must be validated before action is allowed to cross the commit boundary.

The defining question for execution-connected AI is no longer only: did someone approve this? It is: can we prove that authority survived to the moment of action?

Related Arqua pages

• Execution Admissibility Architecture
• Architecture of Record (AoR)
• SCIA Runtime Reference Architecture
• Artificial Intelligence and Execution Control
• Canonical Definitions — Execution Admissibility Architecture
• Structural Context Library
• Enterprise Bridges

Download the paper

The Desynchronization of Authority

Arqua Architecture Paper | Version 1.0 | May 2026

Download PDF

Suggested citation: Arqua, The Desynchronization of Authority: Why AI-mediated execution requires Execution Admissibility at T=0, Arqua Architecture Paper, 2026.

Use this paper to start a conversation

Start with one high-consequence workflow. Identify where consequence binds. Locate T=0. Determine what authority, evidence, state, context, and constraints must be proven before execution is allowed.

CTA

Start with one high-consequence decision. Identify where execution is currently uncontrolled.

© Arqua Pty Ltd. All rights reserved.