The biggest single failure mode in inspection management is not bad inspection — it is ungoverned inspection. An inspector fills in a form, hits submit, and the form becomes "evidence" with no review, no version control, no required-field enforcement, and no audit trail of how the form was authored. When the auditor later asks "why does this checklist ask about fire extinguisher pressure but not about extinguisher location?", the safety officer has no answer — the form was someone's Word document from three years ago and nobody remembers who approved it. SiteGuard was built to make this failure mode impossible. The inspection process is governed by a three-feature authoring cycle: Checklist Templates author the inspection with versions and required flags, Checklist Items capture the structured field response with status and files and validated data, and Response Review approves each submission with a named reviewer before it becomes audit-grade evidence. This article walks through the cycle, the versioning model, the required-flag enforcement, and the QC gate that turns field data into evidence that survives an ISO 45001:2018 stage-2 audit without follow-up questions.
Step 1: Checklist Templates author the inspection #
Checklist Templates is the manager-side authoring surface in SiteGuard Manager. The safety officer designs each template — typically one per inspection type, such as fall-protection inspection, fire-safety inspection, scaffolding inspection, hot-work permit inspection, confined-space entry inspection — with the items the inspection must cover. Each template carries two governance properties that distinguish SiteGuard from a form-builder. First, templates are versioned: every change to a template — adding an item, removing an item, toggling a required flag, modifying the conditional logic that branches items — is recorded against a new template version. When an inspector executes the checklist on SiteGuard Field, the response is stamped with the template version it was executed against. The auditor can therefore prove that a specific inspection followed the version of the checklist that was current on the inspection date, which is exactly what ISO 45001:2018 clause 7.5 (documented information) expects. Second, items can be flagged required: a required item cannot be skipped during execution, which prevents the common field failure of inspectors marking items "N/A" to avoid capturing evidence. Together, versioning and required-flags make the template a governed document, not a free-form form.
Step 2: Checklist Items capture the structured field response #
Checklist Items is the field-side execution surface. When the inspector opens a Dynamic Checklist on SiteGuard Field, the template is rendered as a sequence of items — each with its own status field, its own file attachment slot, and its own validated data entry. The status field is not free text; it is a constrained set of values (typically pass, fail, N/A-with-reason) configured in Platform Settings. The file attachment slot accepts Photo Evidence captured at the moment of inspection. The validated data entry enforces data types — a pressure reading must be numeric, a date must be a date, a signature must be a captured signature — so the response data is structured and queryable rather than free-form text the safety officer cannot aggregate. Required-flagged items cannot be skipped; the inspector must capture a status before the checklist can be submitted. Conditional items appear and disappear based on the rules defined in the template — if the inspector marks "edge protection damaged" as fail, a sub-list of items asking for photo evidence, immediate control, and whether work was stopped surfaces automatically. The inspector never sees the rules; they see only the items the rules surface, which is what makes the experience fast enough that inspection time drops materially versus the paper-and-PDF predecessors.
Step 3: Response Review is the QC gate #
Response Review is the manager-side QC gate that turns field data into audit-grade evidence. When an inspector submits a checklist response on SiteGuard Field, the response does not immediately become audit-grade; it queues against its parent plan in SiteGuard Manager, where a named reviewer — typically a safety officer or a senior inspector — sees the full response, the GPS Check-in stamp, the Photo Evidence attached, and any violations raised during the inspection. The reviewer approves, rejects with comments, or requests clarification. The response does not become audit-grade until approved, and the approval — with reviewer name, date, and outcome — is the documented information ISO 45001:2018 clause 9.1.1 expects to see. Without this gate, the platform has data; with it, the platform has evidence. The reviewer can also reject responses that look problematic — an inspector who marked every item as pass with no photo evidence, or an inspector who skipped every required item by claiming N/A — and send them back to the inspector for re-execution. This is the human-judgement layer that automated validation cannot replace, and it is what makes SiteGuard inspection evidence credible to a Saudi Civil Defense inspector or an ISO 45001 stage-2 auditor.
Versioning: why clause 7.5 documented information matters #
ISO 45001:2018 clause 7.5 requires organisations to control documented information so that it is identifiable, retrievable, and protected — and so that changes are version-controlled. For inspection checklists, this means the auditor must be able to prove that a specific inspection followed the version of the checklist that was current on the inspection date. SiteGuard handles this natively. Every Checklist Template change creates a new version. When an inspector executes the checklist, the response is stamped with the template version. When the auditor opens an inspection record from six months ago, SiteGuard Manager shows the template version that was current on that date, the items that were on that version, and the conditional logic that governed which items appeared — even if the template has since been updated. This is the difference between a governed inspection record and an uncontrolled Word document. For a Saudi contractor whose Civil Defense inspector asks "which version of the fall-protection checklist was in use when this inspection was done in March?", the answer is the versioned template record, not a guess. Platform Settings configures the Checklist Item types that govern what "status" means at your company, so the versioning model extends to the controlled vocabulary of inspection outcomes as well as the template structure.
Required-flag enforcement and conditional logic #
Required flags and conditional logic are the two enforcement mechanisms that prevent the most common field failure modes. A required flag on a checklist item means the inspector cannot submit the checklist without capturing a status for that item — they cannot mark it N/A without a reason, they cannot skip it, they cannot leave it blank. This eliminates the "inspector skipped every hard question" failure mode that plagues paper and PDF checklists. Conditional logic is the layered set of rules that decides which items appear during execution based on site, item, and answer conditions. Site-level conditions determine which template sections show up based on the site type. Item-level conditions determine which items appear within a section based on hazard presence. Answer-level conditions cascade: a fail on a critical item surfaces a sub-list asking for photo evidence, immediate control, and whether work was stopped. Together, required flags and conditional logic enforce that the inspector captures the evidence the template author intended, while still adapting the inspection to the site — which is the structural improvement that lets SiteGuard checklists produce audit-grade evidence in less time than a static PDF checklist takes to fill in.
How the three-feature cycle fits the rest of SiteGuard #
The three-feature authoring cycle does not run in isolation. Checklist Templates are configured in SiteGuard Manager against the Sites master data, so the template can branch on site type. Platform Settings configures the Checklist Item types that define what "status" means at your company, so the cycle inherits your controlled vocabulary. Daily Plan Management creates the plan that assigns the inspection to an inspector; Plan Approval approves the plan with a reviewer; Today's Plans surfaces the plan to the inspector on SiteGuard Field. The inspector checks in with GPS Check-in, executes the Dynamic Checklist (which renders the Checklist Template), captures Checklist Items with structured responses, attaches Photo Evidence, and raises Violations if any are observed. The submitted response queues in Response Review against its parent plan. Once approved, the response flows into Visit History as a completed visit and into Compliance Reporting as filterable evidence. Company Scope ensures the entire cycle runs within the right legal entity for multi-subsidiary holdings. Notifications push plan changes, submission events, and review outcomes back to the field, so the inspector knows the moment a response is approved or sent back. The cycle is one node in the broader SiteGuard workflow — but it is the node where field data becomes audit-grade evidence, which is why its governance matters more than any other feature in the platform.