Authority Pattern Library · Architecture
AA-05 · Foundational Authority Constraint
Hold, refusal and escalation can be legitimate outcomes
A proposed action may lack sufficient evidence, current authority or required conditions. In that situation, a governed process may hold, refuse or escalate the proposal rather than treat uncertainty as permission.
Non-action is not automatically safe or correct. Delay, omission and refusal can themselves create consequences, including where an institution has an obligation to act.
Make the outcome specific
Distinguish a temporary hold awaiting evidence, a refusal of the selected proposal and an escalation to an appropriate authority. Identify the reason, scope, responsible participant and conditions for reconsideration.
A system that merely stops responding has not necessarily produced a controlled outcome. The institution may need to know what remains pending and which obligations continue.
Preserve the ability to reconsider
A later retry or resumed workflow should not silently assume that the original proposal and authority remain unchanged. Establish which conditions must be checked again and which evidence supports renewed consideration.
A hold may preserve options before commitment; it does not guarantee reversibility, prevent every harm or erase an operation already performed.
Meaningful participation
Where resolution depends on a person, provide relevant information and a practical ability to influence the next step. Escalation is useful only within an applicable responsibility and response arrangement.
Existing human procedures, application controls and workflow may supply these capabilities without an additional Arqua runtime.
Evidence and learning
Record the proposal, reason for non-action, authority basis, resulting state and later disposition. Outcomes can inform revised rules or evidence requirements without retroactively changing the original decision.
Explore next
- Authority Before Action as a Structural Constraint — authority before action.
- Execution Sovereignty Failure — changes in authority during execution.
- Caution Is Not Governance — caution and governance.
Architecture and scope
Architecture of Record (AoR) records accepted standing, applicability and obligations. Execution Admissibility Architecture explains execution admissibility. Their publication does not demonstrate an implemented control or a requirement for a particular runtime.
This is an explanatory pattern, not an organisational assessment, issued Profile, legal opinion, compliance determination or implementation assurance.
© Arqua Pty Ltd. All rights reserved.