Two people review before the action runs
Many teams say they have dual control when what they actually have is a forwarded email. Maker-checker is the pattern that closes it: refunds above a threshold, vendor bank-detail changes, account deletions, and production deploys all need a second person in a different role. Latch Workflow enforces that separation in the system, on infrastructure you run.
The operator who prepared the ticket - or the case, if you work in a regulated function - cannot approve it. The block is recorded, and the approval evidence stays with the action result.
prepare - review - execute - prove
The operator builds the case: adds notes, attaches evidence, selects the action, and moves it to review. They cannot execute.
A different person in the required role sees the full case context, the proposed action, and the evidence. They approve, reject, or send back for revision.
The action runs through the plugin. The request, the result, the maker identity, and the checker identity all write back to the case timeline.
If the maker tries to approve their own case, the attempt is blocked and recorded. This is not a warning. The system will not proceed.
System-enforced, not policy-enforced
Segregation of duties is a role rule the system holds, not a line in a process document. The maker cannot approve their own case. The system blocks the attempt before it runs and records it.
The checker reviews from the case, not from a forwarded email
The reviewer sees the issue, the evidence, the operator notes, the AI classification, and the proposed action in one place. Independent review works when the reviewer has the full picture.
Every step answers the auditor question
Who prepared it. Who reviewed it. Whether anyone was blocked. What changed in the downstream system. The case holds the full chain of evidence, not a reconstructed narrative.
Use two-person review where a single mistake costs the most
Not every action needs two reviewers. But when money is moving, customer data is changing, or a system state is hard to reverse, a second pair of eyes is the difference between a controlled process and an expensive mistake.
Dual control on infrastructure you already own
A control is only as good as the record behind it, and that record has to sit somewhere the team can defend. Latch is self-hosted: on-premise, in a private cloud, or air-gapped. Case data, reviewer identity, and the models that suggest what to check stay inside the boundary.
A cloud help desk can add an approval step. It cannot add one without a copy of the case leaving the network. Maker-checker is one gate inside a wider ticketing system with approval workflows.
Maker-checker enforces the boundary. It does not replace judgment.
The system guarantees that the right number of independent people reviewed the action. It does not guarantee they made the right decision. That is still the team's job. What Latch adds is the structure that makes the review happen, the evidence that makes it informed, and the record that makes it provable.
Enforces role separation. Blocks self-approval. Records every step. Writes the result back to the case.
Replace the checker's judgment. Automate the review decision. Guarantee the right outcome. Remove the need for domain knowledge.
AI can surface context, flag anomalies, and suggest what to check. The human reviewer still decides. The decision is recorded regardless of whether AI was involved.
Follow the control path from intake to evidence
These pages work together: intake shapes the ticket, approvals gate sensitive actions, maker-checker enforces independence, security controls the deployment boundary, and auditability preserves the proof.
Route sensitive actions through role checks and approval gates before they run.
Keep decisions, blocked attempts, approvals, and action results on the same record.
Deploy where ticket data, identity, and the AI models you choose stay inside your environment.
Bring email, forms, alerts, and system events into one ticket queue before actions begin.
Questions about dual control and two-person review
Common questions from teams evaluating how maker-checker works inside a ticket or case workflow.
How is this different from an approval workflow?
An approval workflow asks "should this proceed?" Maker-checker asks "did someone independent verify the work before it proceeds?" The distinction matters because maker-checker enforces role separation: the person who prepares the case cannot also approve and execute the action. Latch enforces that in the system, not in a policy document.
What happens if the checker rejects the action?
The rejection is recorded on the case with the reason. The maker sees what was rejected and why, then can revise and resubmit. Both the rejected attempt and the resubmission stay visible in the case history, which is exactly what a later review needs.
Can the same person be both maker and checker?
No. Latch enforces role separation at the system level. If the person who prepared the case tries to approve their own work, the action is blocked and the attempt is recorded. This is not a policy reminder. It is a hard constraint.
Does every workflow need maker-checker?
No. Some workflows need a single operator with the right role to act. Others need full dual control. Latch lets teams define which actions require independent review and which do not, so the control model fits the risk, not the other way around.
How does this relate to four-eyes and segregation of duties?
Maker-checker is the operational pattern. The four-eyes principle is the rule behind it: two sets of eyes on anything consequential. Segregation of duties is the broader design constraint that keeps preparation, review, and execution in different hands. Latch enforces all three through the same mechanism: role-based restrictions on who can prepare, who can review, and who can execute, all recorded on the case.
Is a second signature enough?
A second signature is only useful when the reviewer has the case context and the system enforces independence. Latch keeps the request, evidence, approval decision, blocked attempts, and execution result on the same case so two-person review leaves usable proof.
Where does the approval record live?
In your deployment. Latch is self-hosted, so the maker identity, the checker identity, the blocked attempts, and the downstream result are written to a database you run on-premise, in your private cloud, or air-gapped. Dual control evidence does not sit in a vendor tenant you cannot inspect.
See how maker-checker would work on one of your sensitive actions
Pick an action: a refund, a vendor change, an account deletion, or a deploy. Follow the prepare-review-execute-record cycle end to end on one case.