Two people review before the action runs
Some actions need more than one pair of eyes — refunds above a threshold, vendor bank changes, account deletions, production deploys. Latch enforces two-person review at the system level. The person who prepared the case cannot approve it. No forwarded emails. No Slack threads. The system blocks it.
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
The restriction is in the system, not in a process document. The maker cannot approve. The checker cannot prepare. The system blocks violations before they happen and records the attempt.
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.
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.
Questions about two-person review
Common questions from teams evaluating how two-person approval works inside the 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 be the person who approves and executes the action. Latch enforces this at the system level, not through policy documents.
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, and can revise and resubmit. Both the rejected attempt and the resubmission stay visible in the case history — which is exactly what auditors want to see.
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. Four-eyes is the principle. Segregation of duties is the broader design constraint. 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.
See how two-person review would work on one of your sensitive actions
Pick an action — a refund, a vendor change, an account deletion, a deploy — and see how the prepare-review-execute-record cycle works on one case.