Dual Approval¶
Authorization workflow — instantiates Checks-and-Balances Architecture
A workflow requiring two distinct approvals before a high-risk action can proceed.
Dual Approval is the runtime workflow that holds a high-risk action in a pending state until two separate approvals are recorded, then releases it. It is the plumbing, not the principle: where a role design decides who the two approvers are and a decision-right defines what a block means, dual approval is the machinery that actually routes the request — puts it in a queue, sends it to the first approver, waits, sends it to the second, and lets it execute only when both have signed off. Its defining contribution is the sequenced, stateful pipeline with a hard gate at the end: the action literally cannot fire until both approvals exist in the record, and either approver's refusal sends it back rather than through. It turns a checking arrangement into an enforced sequence of steps that a request must pass through, with the block wired into the workflow itself rather than depending on anyone remembering to intervene.
Example¶
A manufacturing company's procurement system routes purchase orders. Small orders flow straight through, but any capital-expenditure request above $50,000 enters a dual-approval workflow. The requesting manager submits it, and the system moves it into a pending state — the vendor cannot be committed, no PO number issues. It routes first to the divisional budget owner, who checks it against the department's remaining capital budget, and then to a finance controller, who checks it against company cash policy and the vendor's standing. Only when both approvals land does the system release the PO and notify the vendor. If either approver rejects or requests changes, the workflow bounces the request back to the manager with the reason attached, and the clock and the trail reset. A finance controller reviewing the audit log a quarter later can see, for every large purchase, exactly who approved it, in what order, and when — because the workflow recorded each step as it happened, not as an afterthought.
How it works¶
- Gate on a trigger. A rule (amount, risk class, action type) decides which requests enter the two-approval pipeline and which flow straight through; most traffic should not touch it.
- Hold in a pending state. The action is inert until released — no side effects, no commitment — so nothing partial happens while approvals are outstanding.
- Route in sequence and wait. The request moves to each approver in turn; the workflow tracks whose turn it is, what is still outstanding, and how long it has waited.
- Release only on a complete set; bounce on refusal. Execution fires only when both approvals are recorded; any refusal returns the request with its reason rather than letting it proceed.
- Log every transition. Each submission, approval, refusal, and release is written to the record as it occurs, so the trail is a by-product of the flow, not a reconstruction.
Tuning parameters¶
- Trigger threshold — what pulls an action into dual approval versus straight-through. Too low and everything jams; too high and dangerous actions slip under the bar — and requesters learn to split one action into two to stay beneath it.
- Sequence vs. parallel — whether the two approvals happen in order (budget then finance) or simultaneously. Sequential adds latency but lets a first rejection save the second approver's time.
- Timeout behavior — what happens when an approval stalls: auto-escalate, auto-reject, or wait indefinitely. Aggressive timeouts keep work moving but can force premature decisions.
- Break-glass path — whether a single approver may push an action through in a genuine emergency, and what after-the-fact review that triggers. A loose exception quietly dissolves the whole gate.
- Delegation rules — whether an approver may hand their authority to a deputy, and whether the two delegates can collapse back onto one person.
When it helps, and when it misleads¶
Its strength is that it makes the check automatic and stateful: the block is enforced by the workflow, not by anyone's vigilance, and the record is generated as the action moves rather than assembled later. That makes it cheap to run at volume and hard to skip — a high-risk action simply cannot execute without two approvals on file.
Its signature failure is rubber-stamping born of diffusion of responsibility: when two people must approve, each can assume the other did the real checking, so both click through and the second approval adds nothing but latency.[n1] The workflow faithfully records two approvals that never involved two acts of scrutiny. It is also gamed by action-splitting (dividing one $80,000 purchase into two $45,000 ones to duck the threshold) and hollowed out by a permissive break-glass path that becomes the normal path. And a workflow can only enforce that two distinct approver slots were filled; whether those slots hold genuinely independent judgment is a question of role design it cannot answer. The discipline that keeps it real is a threshold set where it can't be trivially split around, a break-glass exception that is rare and always reviewed, and approver roles whose independence is guaranteed elsewhere.
How it implements the components¶
coordination_interface— it is the coordination machinery: the queue, the pending state, the sequenced routing, and the wait-for-both logic that carries a request between two approvers.veto_or_remedy_rule— either approver's refusal is a wired-in block that returns the action for revision instead of letting it proceed; approval-of-both is the release condition.accountability_record— every submission, approval, refusal, and release is logged as it happens, so each gated action carries a complete, contemporaneous approval trail.
It routes and gates; it does not design which roles the two approvers occupy or guarantee they are genuinely separate — that is Maker / Checker Separation — nor secure the reviewers' independence from the reviewed party, which is Independent Review, nor provide a standing body to hear disputes, which is the Oversight Board.
Related¶
- Instantiates: Checks-and-Balances Architecture — it is the enforced two-approval pipeline that stops a high-risk action from proceeding on one authorization.
- Consumes: Maker / Checker Separation — the workflow's two approver slots are only a real check if the roles filling them are separated; dual approval executes the gate that role design defines.
- Sibling mechanisms: Oversight Board · Independent Review · Maker / Checker Separation · Audit Committee · Veto Authority · Compliance Review · Red-Team Challenge
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Dual Approval operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it a workflow requiring two distinct approvals before a high-risk action can proceed.
Independent corroboration: The frozen evidence defines Dual Approval as 'A workflow requiring two distinct approvals before a high-risk action can proceed', so its operative form is Decision, Gate & Allocation.
Nearest alternative: Protocol, Workflow & Routine — The workflow's central result is a bounded release disposition that remains pending until both approvals arrive.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Accounting & Auditing
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Internal-control practice cohered dual authorization and segregation of duties so one actor cannot initiate and approve a high-risk transaction.
Related originating lineages:
- Law & Governance — Public and corporate governance developed concurrence requirements for consequential acts.
- Organizational & Management Science — Delegation-of-authority workflows institutionalized two distinct approvers and escalation.
- Security Studies & Intelligence Analysis — Security authorization independently standardized two-person gates against single-actor error, coercion, and malfeasance.
Review resolution: Accounting is primary because dual authorization and segregation of duties made the workflow routine; legal concurrence, organizational authority, and security two-person integrity are independently convergent lineages.
Attribution caveat: Financial internal controls and legal concurrence rules are parallel institutional lineages.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Diffusion of responsibility — the social-psychological tendency for individuals to feel and exert less personal responsibility when others are present who could also act. In a two-approver gate it produces the paradox that adding a second reviewer can lower each one's diligence, because each assumes the other is doing the careful check. ↩