Overview
The four-eyes principle is the operational practice of requiring two qualified people to verify high-risk work before it's accepted. In Mobaro, you implement it by combining state-based Checklist logic, validation requirements, and signature capture — letting one Checklist run handle both the assignee's work and the second-person verification, on a single Result with a complete audit trail. This article covers when the pattern is worth the operational overhead, how to design Checklists for it, and the trade-offs to watch for.
The mental model: Four-eyes isn't a Mobaro feature — it's a way of using Mobaro features. The state-based logic creates two phases on one Checklist. The validation requirement on the Schedule forces the reviewer phase to happen. The reviewer signature proves it did. Together they let one Result document a two-person verification.
When four-eyes is worth it
Four-eyes adds operational overhead — every check needs two qualified people on hand at the right time. The pattern earns that overhead when the cost of an error is severe enough to justify it. Common contexts:
Safety-critical inspections — restraint checks, brake systems, structural integrity. The cost of missing a defect is potentially catastrophic; the cost of a second pair of eyes is small in comparison.
Regulatory compliance — checks that auditors will scrutinize, where independent verification is part of the regulatory expectation.
High-value financial transactions — cash counts, vault access, certain F&B controls.
Incident response and root-cause analysis — situations where a single person's judgment shouldn't be the final word.
Pattern not worth four-eyes: routine operational checks where errors are recoverable and inexpensive, training contexts where one-on-one feedback is the goal (use state-based logic for that, but the framing is different), and any check where you can't reliably get two qualified people in the right place at the right time.
Design pattern: split assignee and reviewer responsibilities
A four-eyes Checklist has three logical zones:
Shared context (visible to both phases) — Location, timestamps, equipment IDs. Both people need to know what they're checking. No state-based logic on these.
Assignee zone (visible state ≠ awaiting validation) — the actual measurements, observations, and findings the first person captures.
Reviewer zone (visible state = awaiting validation) — the second person's verification questions, their independent observations, the supervisor signature.
The reviewer phase is intentionally light. The reviewer's job isn't to redo all the work — it's to verify what the assignee captured and add the second-person sign-off. If your reviewer zone is duplicating the assignee's questions, you're not saving any time over running two separate Checklists.
The reviewer signature
A signature question scoped to the reviewer phase is the canonical end-of-four-eyes step. It's the proof the reviewer was actually present and signed off — not just that the Schedule was configured to require validation.
Configure the signature as a question with state-based logic "Checklist is Equal to Awaiting validation" so it appears only during the reviewer phase. Make it required, so the validation flow can't be completed without it.
Best practice: Add a "reviewer name" text question alongside the signature, even though Mobaro tracks the User who validated. The visible name on the Result PDF is faster to read at audit time than checking the Compliance page Contributors section. Belt and suspenders for high-stakes records.
Worked examples
Example 1: Lap-bar restraint check on a coaster
Scenario: A coaster's daily pre-opening inspection includes a restraint integrity check. State guidelines and operator policy both require independent verification before the ride opens to guests.
Setup: Pre-opening Checklist on a Calendar Schedule that requires validation. Three zones — Shared (Train ID, inspection date, weather conditions, ambient temperature), Assignee (restraint engagement check on each car, lock-engaged measurement, hydraulic pressure reading, visual condition photo), Reviewer (independent verification of one randomly-selected car, supervisor sign-off, supervisor signature, supervisor name).
Result: Operator runs the inspection, supervisor verifies and signs. Final Result PDF shows both phases — at audit, anyone can see at a glance which technician did the work and which supervisor signed off, with timestamps and signatures.
Example 2: End-of-day cash count with manager sign-off
Scenario: A high-volume F&B location wants two-person sign-off on the daily cash deposit total to prevent both error and theft.
Setup: Cash count Checklist on the Schedule for end-of-day. Three zones — Shared (date, location, register IDs), Assignee/cashier (denomination breakdown, total, deposit slip number, photo of deposit bag seal), Reviewer/manager (independent total verification, deposit bag seal verification, manager signature).
Result: Cashier captures the count. Manager validates with their own count check and signs. Both signatures are on the Result, providing a clean record for the financial audit trail.
Example 3: Incident root-cause analysis
Scenario: A ride incident requires a documented root-cause analysis. Operator captures the immediate observations; safety committee reviewer adds independent assessment and corrective actions.
Setup: Incident Checklist on an Ad Hoc Slot triggered by the incident. Three zones — Shared (date/time, location, equipment involved, witness list), Assignee/on-site operator (immediate observations, photos, contemporaneous notes), Reviewer/safety committee (independent assessment, root-cause determination, corrective actions, committee chair signature).
Result: A single record captures both the on-site context and the formal review — both pieces are needed for incident reporting and regulatory submissions.
Anti-patterns to avoid
Watch out for these patterns, which break the four-eyes integrity:
Same User as assignee and reviewer — if one User holds both Roles and runs both phases, the four-eyes principle is fictional. Configure Roles so the User running the assignee phase can't also validate. The system won't enforce this for you — process discipline must.
Reviewer phase without a signature — without an explicit signature, all you have is "User X clicked Approve." The signature elevates this to "User X took responsibility." For audit-grade records, the difference matters.
Skipping the validation requirement on the Schedule — without it, Results are pre-approved and never enter awaiting-validation state. The reviewer-only questions never appear, even though they're configured. Easy to miss; verify by completing a test Result and checking that it queues for validation.
Reviewer rubber-stamping — if the reviewer always approves immediately without genuinely verifying, you have the appearance of four-eyes without the substance. Reviewer training, randomized re-checks, and deliberately calibrated reviewer questions (not just "did the assignee do it?" but "verify X yourself") all help.
Four-eyes everywhere — applying the pattern to routine, low-risk checks creates compliance theater without operational benefit. Reserve four-eyes for the cases where independent verification actually matters.
See also
Checklist state-based logic for in-app validation — for the underlying mechanics of the assignee/reviewer split.
The Compliance page in Result reports — for how the four-eyes flow surfaces in audit-grade Result PDFs.
Setting up Roles — for configuring Role separation between assignees and reviewers.
Frequently asked questions
Q: Can Mobaro enforce that the assignee and reviewer are different Users?
A: Not at the Schedule level. The constraint is enforced through Role configuration — if your assignee Role doesn't have validation authorization and your reviewer Role doesn't perform the original assignment, the same User can't fill both phases. Design your Roles to make this impossible by configuration rather than by policy.
Q: Does the reviewer need to be physically present?
A: That's a process question, not a Mobaro one. Mobaro tracks who validated and when; whether they were on-site or remote is up to your operational policy. For four-eyes principle in safety contexts, on-site presence is typically required by regulation; for financial four-eyes, remote verification with electronic signature may be acceptable.
Q: Can the assignee see what the reviewer wrote?
A: After validation, the final Result report shows both phases together. The assignee can see the reviewer's notes once the Result is in its final state. During validation (state = awaiting validation), the reviewer phase is in progress and not yet finalized.
Q: What if the reviewer disapproves? Does the assignee redo the original Checklist?
A: Disapproval is a final state on the original Result. If the work needs to be redone, schedule a new Slot (Ad Hoc, or wait for the next regular occurrence). The disapproved Result remains in the audit trail as a record of what was rejected.
Q: Can I require multiple reviewers (e.g., supervisor and safety officer)?
A: Native validation is single-reviewer. For multi-reviewer flows, options include: chained Checklists (one Schedule's completion triggers the next), or capturing additional sign-off questions in the reviewer phase (each requires their own signature). Chained Checklists are cleaner for true sequential approval; single-Checklist multi-signature works for parallel sign-off.