Overview
Every Result report Mobaro generates ends with a Compliance page — a structured summary of who did the work, when, against which Schedule, what deviations occurred, and what validation flow the Result went through. It's the audit-trail companion to the Checklist answers themselves: anyone reading a Result PDF months later can answer the question "is this trustworthy as a record?" without having to log in to Mobaro to investigate. The page can be hidden via the Report Template if you don't need it; for any compliance-sensitive operation, leave it on.
The mental model: Checklist answers tell you what was checked. The Compliance page tells you that the check is real — by whom, against which version of the Checklist, with what deviations, and through what review flow. Both are needed for an audit-grade record.
The five sections
The Compliance page contains up to five sections. Some sections may not appear if the underlying feature isn't configured for the Schedule (for example, no Validation section if validation isn't required).
General information
The header section. Contains:
Checklist revision ID — a system-generated identifier for the version of the Checklist used. Every time a Checklist is edited, a new revision ID is generated. This pins the Result to a specific definition.
Result revision ID — a system-generated identifier for this specific Result. Updated when the Result is edited (for example, by a reviewer adding answers or comments).
Revision timestamp — when the latest revision was made.
Why this matters: if the Checklist is edited after a Result is captured, the Result keeps its original revision ID. You can prove which Checklist version was active when the work was done.
Scheduling
Where this Result came from. Contains:
Schedule type (Calendar, Continuous, Ad Hoc).
Schedule name and ID.
Time configuration (scheduled time, deviation window, when the Result was actually completed).
Deviations
A list of any compliance deviations registered on this Result — for example, a Result completed outside its deviation window, or answers triggering compliance rules. If there are no deviations, this section either doesn't appear or shows zero. If deviations exist, each is listed with type and any operator-supplied comment about why the deviation occurred.
Validation
The validation flow this Result went through, if validation is required by the Schedule. Includes:
The validation state (pre-approved, awaiting validation, approved, disapproved).
Reviewer name(s) and timestamps.
Comments and attachments captured during review.
For a deeper treatment of state-based validation logic, see Checklist state-based logic for in-app validation.
Contributors
Every User who touched the Result, with role:
The assignee who completed the Checklist.
Any reviewer(s) who validated.
Any User who edited the Result post-completion.
Why revision IDs matter
The two revision IDs in General information are the most easily overlooked piece of the Compliance page, and the most useful for audits.
Checklist revision ID: When you change a Checklist (add a question, remove one, edit phrasing), Mobaro generates a new revision. The Results captured before the change keep their original revision ID — they're tied to the old version. The Compliance page lets you prove which Checklist definition was in effect when this work was done.
Result revision ID: Each time a Result is touched after completion (a reviewer edits an answer, a comment is added), the Result revision ID updates. The Compliance page captures the latest. If you download a Result PDF today and another one in three months, comparing Result revision IDs tells you whether anything has changed.
Best practice: For high-compliance operations (regulatory inspections, safety audits), download Result PDFs to a long-term archive at the time the Result is finalized. The Result revision ID at download time is your "as of" reference; if anyone edits the Result later, your archived PDF still shows the original.
Hiding the Compliance page
For Result types where the Compliance page isn't useful (informal logs, customer-facing reports), hide it on the Report Template:
1. Open the relevant Report Template
Go to Report Templates in the Mobaro Backend.
2. Tick "Hide Compliance page"
In the Report Template settings, find and enable the Hide Compliance page option.
3. Save the Template
Reports generated using this Template will no longer include the Compliance page.
Heads-up: Hiding the Compliance page only affects the PDF output. The underlying compliance data (revision IDs, deviations, validation flow, contributors) is still captured and visible in the web Backend. Hiding only changes what's printed — not what's tracked.
Compliance signals in the activity feed
When viewing a Result on the web Backend (rather than as a PDF), compliance signals also appear in the activity feed:
Validation flow at the top — who validated, when, with what outcome.
Deviation indicator — a yellow warning sign appears when the Result has any deviations, with the count and category listed beneath. Operator comments explaining the deviation appear inline.
Worked examples
Example 1: Audit response using revision IDs
Scenario: A regulatory auditor asks for the safety inspection records for a coaster from the previous operating season. Some of those Checklists have since been edited.
Setup: Operations exports the relevant Result PDFs from the archive. Each PDF includes the Compliance page with the original Checklist revision IDs.
Result: The auditor can verify exactly which Checklist version was used for each inspection — the revision IDs prove the Checklist hasn't been retroactively modified to alter the record.
Example 2: Hiding the page for guest-facing reports
Scenario: A park sends Result reports to event organizers as part of the venue rental contract. Internal compliance metadata (revision IDs, contributor details) isn't useful to them.
Setup: A separate Report Template is used for guest-facing reports with Hide Compliance page enabled.
Result: Internal staff still see the Compliance page on their own reports; guest-facing reports are clean.
See also
Report selection guide — picking the right Report Template for the job — for choosing which Report Template applies in which situation.
Checklist state-based logic for in-app validation — for the validation flow that produces the Validation section content.
Frequently asked questions
Q: Can I customize which sections appear on the Compliance page?
A: Not section-by-section — the Compliance page is all-or-nothing via the Hide Compliance page Template setting. Sections that aren't applicable (e.g., Validation when validation isn't required) are automatically omitted.
Q: Do revision IDs change when I just view a Result?
A: No — viewing doesn't trigger a revision. Only edits (answer changes, comments added, validation actions) generate new Result revision IDs.
Q: Where do revision IDs come from?
A: They're system-generated and intended as opaque identifiers (not human-readable timestamps or sequence numbers). Their purpose is uniqueness for the audit trail.
Q: If I hide the Compliance page, do I lose the data?
A: No. Hiding only suppresses the page in PDF output. The underlying data (revision IDs, deviations, validation, contributors) is still captured and visible in the web Backend.
Q: Does the Compliance page appear in CSV/Excel report exports?
A: It's a PDF-specific feature. Tabular exports include the underlying fields (revision IDs, contributors, deviations) as columns rather than as a structured page.