Authority Before Action as a Structural Constraint

Authority Pattern Library · Architecture

Authority must remain applicable to the action

An earlier decision, a useful explanation or a technically permitted operation does not by itself establish authority for every later action. For a consequence-bearing action, the relevant authority, purpose, scope and conditions must remain applicable when the institution becomes committed.

This pattern concerns a possible separation between declared authority and the action it is meant to govern. It does not presume that an organisation lacks effective controls.

AA-01 · Foundational Authority Constraint

Recognise the condition

An approval may refer to one proposal while the executed operation has changed. A delegation may have expired. Evidence or operating conditions may have changed while work was queued. The practical question is:

Can the institution establish why this particular action may proceed under the authority and conditions that apply now?

Escalation, discretion and review can be legitimate parts of that answer. Their presence alone does not demonstrate failure. The concern arises when they substitute for a missing or untraceable authority relationship without an accepted basis.

Connect understanding with authority

Represent the subject, proposed action and relevant version clearly. Preserve the sources and evidence supporting the interpretation. Establish what understanding may be relied upon for the declared purpose, including material limitations.

These responsibilities support judgement. They do not silently grant permission to execute. The applicable enterprise process establishes authority, delegation, required human participation and the conditions under which action may proceed.

Meaningful human participation requires an appropriate role, relevant information and a practical opportunity to challenge or change the proposal. A recorded acknowledgement alone does not establish those conditions.

Locate the actual commitment

Preparation, approval, execution and observed outcome are distinct facts. Identify the point at which the selected operation creates a binding commitment or changes consequence-relevant state.

Existing application controls, workflow rules, human procedures or composed technical controls may adequately govern that boundary. Where purpose, proposal, authority or material circumstances change, establish which checks must be repeated. Where the basis remains insufficient, hold, refusal or escalation may be appropriate.

Preserve evidence and learn

Architecture of Record records accepted standing, applicability, obligations and relevant boundaries. Institutional Memory preserves the supporting history. Evidence should connect the proposal, applicable authority, participation, actual operation and observed result.

A successful operation does not prove that its intended outcome occurred. Later learning can inform a governed revision without rewriting what was known or authorised at the original decision.

Relationship to execution admissibility

Execution Admissibility Architecture explains the architectural responsibility for evaluating proposed consequence-bearing execution. SCIA Runtime Reference Architecture describes a runtime reference architecture within that responsibility.

Neither reference establishes a deployed control in a particular organisation. No additional Arqua runtime is required where existing arrangements demonstrably satisfy the applicable responsibility.

Explore the pattern in context

• Banking & Financial Services — sector overview.
• Banking — Payments & Lending - Context Library — a bounded banking context.
• Authority and Automation in Real-Time Payments — payment preparation, release and result.

Related patterns

• Decision–Execution Decoupling — decision and execution can occur separately.
• Authority Drift — authority can change over time.
• Authority Without Traceability — preserve how authority was established.
• Non-Action as a Valid Control Outcome — non-action can be a legitimate outcome.

Scope

This is an explanatory architectural pattern, not an assessment of an organisation, proof of compliance or a claim that authority is the sole cause of operational failure.

© Arqua Pty Ltd. All rights reserved.