The Desynchronization of Authority

Arqua Architecture Paper

Version 1.0 | May 2026

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.

Table of contents

1. A concrete failure scenario
2. The central thesis
3. Scope: execution-connected AI
4. The meeting-to-runtime gap
5. AI compresses the time available to repair authority gaps
6. Synthesised cognition and synthetic synchronization
7. Execution Attribution Collapse
8. Existing controls are necessary but incomplete
9. Execution admissibility at T=0
10. The Execution Passport pattern
11. What the Execution Passport must carry
12. SCIA Runtime and the commit boundary
13. Governed asynchrony
14. Examples
15. How institutions should start
16. Core definitions
17. Boundary statement
18. Reference context
19. Appendix A. Short positioning version

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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

CTA

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

© Arqua Pty Ltd. All rights reserved.