Maker-Checker Controls for Sensitive Workflows

Maker-checker is often reduced to a second button labelled Approve. That is not the control. The control is a set of invariants: one identity proposes a consequential change, a suitably authorised and independent identity reviews the same change, and the accepted effect occurs exactly once. Each invariant must survive direct API calls, broad roles, retries, imports, scheduled work and administrative tooling.

Begin with a threat and failure model

The control should address both malicious and ordinary failure. A maker may intentionally approve their own proposal through an alternate route. A reviewer may approve stale evidence. Two reviewers may race and trigger the effect twice. An administrator may hold every permission for support reasons. A queue may retry after the effect succeeded but before the acknowledgement returned. The design must state which of these it prevents, detects or deliberately accepts.

• Self-approval: the maker and checker resolve to the same human identity.
• Collusive approval: two distinct identities coordinate; maker-checker alone does not prevent this.
• Stale approval: the proposal or its evidence changes after review begins.
• Authority drift: the checker loses scope or approval authority before committing the decision.
• Duplicate effect: retries or concurrent approvals apply the protected action more than once.
• Bypass path: an import, bulk action or support endpoint reaches the final state without review.

Maker-checker reduces single-person error and abuse. It does not prove the underlying proposal is correct, prevent collusion or replace limits, reconciliation and monitoring. Treating it as a complete fraud control gives one mechanism more credit than it can carry.

Authority and independence are separate decisions

A permission answers whether an actor may approve this class of work in this scope and state. An identity comparison answers whether the actor is independent of the maker. Both must pass. Adding an approval role to a maker must not erase the identity rule, and removing a button from the interface must not be the only place either rule exists.

Compare stable human identities, not display names, roles or session labels. If service accounts or delegated administration can act for people, define whether they may participate and how the originating human is preserved. Two technical accounts controlled by one person do not provide meaningful independence.

Model proposal, review and effect separately

A proposal should describe an intended change without performing it. Review records a decision about a particular immutable version. Effect applies the accepted instruction. This separation makes rejection, withdrawal, correction and resubmission visible instead of overloading one mutable record with a status and a collection of overwritten fields.

A practical state model might include draft, submitted, approved, rejected, withdrawn, superseded, applying, applied and failed. Not every system needs every state, but the transition table should say who may enter each state, which fields become immutable and whether a new proposal is required after a material edit.

Synthetic example: a threshold-controlled change

Consider a fictional workflow in which a maker proposes changing a configurable limit from 5,000 to 7,500. The submitted proposal stores the old value, new value, scope, reason, maker identity and version digest. The checker sees that snapshot, not a live edit form. If the maker changes the proposal, the earlier submission becomes superseded and any pending decision becomes invalid.

At approval, the server reloads the proposal, verifies its state and version, confirms the checker still has authority for that scope, rejects the maker's identity, validates required evidence and checks that the current limit is still 5,000. The transaction records the decision and creates one durable effect instruction. If another change already moved the limit, approval fails with a conflict rather than applying a proposal against a world the checker did not review.

Bind evidence to the reviewed version

A filename, checkbox or mutable link does not prove what the checker saw. Evidence should have a stable identifier, integrity digest, lifecycle state and access rule. The approval record should reference the exact evidence version. Replacing evidence after submission should supersede the proposal or force a fresh review.

Do not copy sensitive evidence into a general audit event. Record its identifier, digest and access decision so reviewers can prove which artefact was considered without creating an additional uncontrolled copy. Retention for proposals, evidence and audit events may differ and should be set deliberately.

Re-evaluate at the protected transition

Submission captures intent; it does not reserve authority or freeze the world. At approval, recheck role, scope, expiry, relevant balances or limits, proposal version and target state inside the transaction that creates the effect. A check performed when the screen opened is already stale by the time the button is pressed.

The same rule applies to delayed execution. If approval creates work for a queue, decide which facts must be revalidated by the worker. Some approvals authorise a fixed instruction even if circumstances later change; others require the worker to stop if a limit, ownership or target state has moved. Document that boundary rather than letting retry behaviour decide it accidentally.

Make concurrent decisions and retries safe

Two checkers can open the same proposal. Only one decision should win. Use a conditional state transition or lock so approval succeeds only from the submitted version expected by the checker. The loser receives a clear already-decided response and does not repeat the effect.

Browsers, clients and queues retry. Tie the effect to a stable proposal or transition identifier and enforce uniqueness at the durable boundary. If an external system cannot participate in the same transaction, use an outbox or equivalent handoff with an idempotency key. Exactly-once transport is rarely available; idempotent effect handling is the practical requirement.

Trace every mutation path

The main interface is only one caller. Review direct APIs, imports, scheduled jobs, bulk actions, migrations, support tools and emergency procedures. A protected state should be unreachable unless the same transition service enforces the same invariants, or an explicitly documented exceptional path applies compensating controls.

• Who creates the proposal, and where is that identity recorded?
• Which current permission and scope authorise approval?
• How is human independence established across delegation and service accounts?
• Which fields and evidence become immutable at submission?
• What conditions are rechecked at approval and execution?
• What prevents a second decision or duplicate external effect?
• Which exceptional paths bypass normal review, and how are they detected and reconciled?

Test the control as a transition contract

• Maker with approval permission still cannot approve their own proposal.
• A different checker without the required scope is rejected.
• Changing a submitted field or evidence invalidates the pending review.
• Expired checker authority is rejected even if the page was opened earlier.
• Two concurrent approvals create one decision and one effect.
• Repeating the same request returns the existing result without duplicating the effect.
• Rejected and withdrawn proposals cannot be applied by an alternate endpoint.
• Audit records identify maker, checker, proposal version, evidence references and outcome.

Choose proportionate friction

Independent approval adds delay, staffing dependency and operational cost. Reserve it for actions whose error or abuse justifies that cost. Lower-risk changes may use limits, post-action review or sampling. Higher-risk changes may require multiple checkers, specialist authority or an execution delay. The control should scale with consequence and reversibility, not with how impressive the workflow looks.

A sound maker-checker design is deliberately boring: stable identities, immutable proposals, explicit transitions, current authorization, version-bound evidence and one durable effect. The absence of a dramatic mechanism is a strength when the rule can be explained, tested and audited without reconstructing hidden assumptions.