Authority Pattern Library · Architecture
AA-02 · Foundational Authority Constraint
When authority changes but execution continues
A system may continue to perform an operation according to its technical configuration after the authority for that operation has expired, been withdrawn or changed. Technical correctness and current institutional permission are different questions.
The concern is whether the institution can give effect to a legitimate hold, refusal or changed delegation before the relevant commitment. It is not a claim that every system needs an instantaneous stop or that every completed action can be reversed.
Recognise the boundary
A queued instruction may outlive its approval. A workflow may resume using earlier conditions. A credential may remain valid after a person's business delegation changes. Examine the exact operation, applicable authority, timing and available controls.
A risk is established by evidence about that relationship, not by automation speed or the presence of escalation alone.
Preserve effective intervention
Identify where a change of authority can affect preparation, submission and commitment. The available response depends on the actual system and institutional obligations. Human procedures, native application controls and composed enforcement may provide adequate intervention.
Where commitment has already occurred, stopping future work, correcting state and addressing the consequence are distinct activities. A pause cannot retroactively erase an operation.
Evidence and learning
Preserve when the authority changed, what participants knew, which operations were pending and what actually happened. Later review can support correction without treating a historical approval as indefinitely current.
Explore in context
- Dual Sovereignty Boundary — Operating Context — separate intelligence and execution authorities.
- Authority and Automation in Real-Time Payments — payment states and commitment.
- Non-Action as a Valid Control Outcome — hold, refusal and escalation.
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.