Authority Pattern Library · Architecture
AA-19 · Core Authority Failure
Understanding a situation does not itself grant permission
Context can help an organisation understand what is happening. Its usefulness depends on representation, provenance, accepted standing and qualification for the purpose at hand. Even context that is reliable and relevant does not, by itself, authorise a consequential action.
An AI-generated recommendation may be well supported while the proposed action falls outside a delegation, requires additional consent or depends on a condition that has changed. Conversely, an authorised agent may execute an action when the applicable controls and conditions are satisfied. The distinction concerns responsibilities and evidence, not a universal prohibition on AI execution.
Keep three questions separate
- What can be relied upon here? Identify the information, its source, uncertainty, applicability and qualification for the intended use.
- What is permitted here? Establish the mandate, decision rights, limits, obligations and conditions for the specific action.
- What actually happened? Preserve execution evidence and examine the observed outcome, including effects that differ from the intention.
These questions may be answered through interleaved human and system activity. They are not a mandatory linear workflow. A recommendation, approval and execution record should nevertheless remain distinguishable so that one is not silently substituted for another.
Recognise context-to-action collapse
The pattern arises when information or a recommendation acquires decision-making force without the required authority being established. Examples include treating a generated summary as an accepted determination, allowing a prepared transaction to bypass an approval condition, or relying on context that became stale before execution.
Human participation needs an intelligible purpose: what the person reviewed, what judgement they contributed, what they were empowered to decide and what action their decision covered. A nominal approval does not resolve those questions.
Architectural response
Architecture-led Enterprise Intelligence connects qualified understanding, authority, meaningful human participation, consequential action and execution evidence. Observed outcomes can then inform governed revision of the information, interpretation and controls.
The SCIA Runtime Reference Architecture is a reference architecture for considering these responsibilities. It is not evidence of a deployed enforcement service. Native platforms, composed services, customer or partner controls and human processes may meet them.
Related patterns and contexts
- Explanation Is Not Authority — why an explanation does not establish permission.
- Authority and Automation in Real-Time Payments — the real-time payments context.
- Dual Sovereignty Boundary — Operating Context — responsibilities across distinct authority domains.
Architecture and scope
The Architecture of Record (AoR) records accepted standing, applicability, obligations and boundaries. Execution Admissibility Architecture describes how authority and other applicable conditions relate to consequential action. These responsibilities may be met through existing systems, human controls or composed services; they do not require an Arqua runtime.
This is an explanatory architectural pattern, not an organisational assessment, deployment claim, assurance opinion or legal advice.
© Arqua Pty Ltd. All rights reserved.