Maker / Checker Separation¶
Role partition — instantiates Checks-and-Balances Architecture
A role design separating the actor who creates or initiates an action from the actor who verifies or approves it.
Maker / Checker Separation is a role design: it draws a permanent line so that whoever creates or initiates an action is never the same party who verifies or approves it. It is not a runtime step and not a body — it is the assignment of duties that sits underneath both. Its defining move is to make self-approval structurally impossible by splitting a single job into two incompatible roles: the maker proposes, drafts, enters, or initiates; the checker independently confirms it before it takes effect. Where a workflow enforces that two approvals happen and an oversight body reviews decisions after the fact, this mechanism decides, at design time, which duties may never rest in the same hands. It answers a question the others assume already answered: given everything this role does, what must be carved off so the actor cannot both make and bless the same consequential move?
Example¶
In a company's accounts-payable department, the clerk who sets up a new vendor in the system — name, bank account, payment terms — used to be the same person who could approve payments to that vendor. That single combination is how fraudulent-vendor schemes work: create a fake supplier, then pay it. Maker / checker separation redesigns the roles. The AP clerk (the maker) can create and edit vendor records and enter invoices, but the system will not let that same clerk approve a payment to a vendor they set up. A separate approver (the checker), in a different role with no ability to create vendors, must verify each new payee against supporting documents before any payment posts. The two roles are defined so that no one person can walk a fabricated vendor all the way from creation to payout. The separation lives in the permission design, not in anyone's diligence — the maker simply cannot reach the approve button for their own entry.
How it works¶
- Map the action into its distinct powers. Break a job down to the underlying moves — initiate, enter, edit, verify, approve, execute — rather than treating the role as one indivisible bundle.
- Identify the incompatible pairings. Find the combinations where holding both lets one actor complete a consequential action unobserved: create-and-approve, enter-and-post, request-and-authorize.
- Assign the incompatible duties to different roles. Give the maker the initiating powers and the checker the verifying powers, and define each role by what it cannot do as much as by what it can.
- Enforce the split in the system, not the culture. Wire the separation into permissions and access controls so the maker is technically unable to approve their own work, rather than trusting people to abstain.
Tuning parameters¶
- Granularity of the split — how finely duties are divided. Fine separation closes more self-completion loops but multiplies roles and handoffs; coarse separation is simpler but leaves dangerous bundles intact.
- Which actions are covered — every transaction, or only high-risk ones. Universal separation is safest and costliest; a risk-scoped split concentrates the effort where a self-approved error would hurt.
- Checker competence bar — whether the checker must be able to genuinely re-judge the maker's work or merely confirm it was done. A checker who cannot evaluate the substance is separation on paper only.
- Segregation depth — whether separation covers just approval or extends to reconciliation, custody, and record-keeping, the fuller set of duties classic control theory keeps apart.
- Enforcement layer — policy, supervisory review, or hard system permissions. Only the last makes the split difficult to quietly override.
When it helps, and when it misleads¶
Its strength is that it kills self-review at the root — the source failure the archetype targets — by making it structurally impossible for one actor to both originate and authorize the same action. This is the classic accounting principle of segregation of duties: no single person should control a transaction end to end, because concentration of incompatible duties is the precondition for both undetected error and fraud.[n1] Because the separation is designed into roles and permissions, it holds without depending on anyone's honesty in the moment.
Its honest limitation is that separation is static structure, not live behavior: two properly separated roles can still fail if the checker rubber-stamps, if maker and checker collude, or if the roles are separate on the org chart but staffed by people who defer to each other completely. The classic misuse is cosmetic separation — relabeling one person's two hats as two roles while the same individual, or a fully deferential subordinate, holds both. And a split so aggressive that it fragments a simple task across five approvers buys process cost without adding real judgment. The discipline that keeps it honest is enforcing the split in system permissions rather than policy, requiring the checker to be genuinely able to re-judge the work, and scoping the separation to the pairings that actually enable self-completion.
How it implements the components¶
power_map— its first step decomposes a job into distinct powers (initiate, verify, approve, execute), the small-scale power map that reveals which duties are incompatible.separated_function— it is the separation: it splits the make and the check into two roles that cannot both live in one actor.checking_actor— it constitutes the checker as a distinct role with standing to withhold approval of the maker's work.review_power— it grants the checker the power to verify, confirm, or reject the maker's action before it takes effect.
It designs the roles; it does not run the sequenced approval pipeline those roles plug into — that is Dual Approval — nor guarantee the checker's independence at appointment and budget, which is a job for Independent Review and Audit Committee, nor provide a standing forum to reverse decisions, which is the Oversight Board.
Related¶
- Instantiates: Checks-and-Balances Architecture — it is the role partition that makes an actor structurally unable to both create and approve the same consequential action.
- Sibling mechanisms: Oversight Board · Independent Review · Dual Approval · Audit Committee · Veto Authority · Compliance Review · Red-Team Challenge
Editorial Notes¶
Form Classification¶
Form family: Organization, Role & Governance
Rationale: Maker / Checker Separation operates as a durable role, body, institution, program, service, or pooled-capacity arrangement because it a role design separating the actor who creates or initiates an action from the actor who verifies or approves it.
Independent corroboration: The frozen evidence defines Maker / Checker Separation as 'A role design separating the actor who creates or initiates an action from the actor who verifies or approves it', so its operative form is Organization, Role & Governance.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Accounting & Auditing
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Maker-checker separation descends directly from accounting internal control and segregation-of-duties practice.
Related originating lineages:
- Law & Governance — Authorization, accountability, and anti-fraud requirements materially establish enforceable role separation.
- Organizational & Management Science — Organization design translates segregation of duties into stable permissions and roles.
Review resolution: Both independent reviews assign primary provenance to accounting_auditing. The queued secondary differences (alternate_origin_disagreement) are reconciled by retaining law_governance, organizational_management only as formative or independently established lineage(s), not merely as application domains. origin_mode=cross_disciplinary_synthesis records the provenance relationship, while domain_reach=multi_domain separately records applicability breadth. confidence=high preserves the more cautious assessment, and encyclopedia_synthesis=false records whether either reviewer identified a corpus-specific synthesis.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The pairing with Dual Approval is deliberate and load-bearing. Maker / checker separation defines the roles; dual approval runs the workflow that routes an action through them. Separation without a workflow is a design no system enforces; a workflow without separation routes an action to two slots that one actor can fill twice. Each is hollow without the other, which is why real systems ship them together.
[n1] Segregation of duties (also separation of duties) — the internal-control principle that the responsibilities for authorizing, recording, and holding custody of assets in a transaction should rest with different people, so that no single individual can both perpetrate and conceal an error or fraud. Maker / checker is its smallest, most common instance: the initiator and the approver must differ. ↩