Safety and compliance
Safety settings reference
Operating mode, the flight-release gate, the site-conditions currency window and the daily digest — and exactly what each one changes.
Four settings on Safety, then Settings decide who approves what and when a clearance is blocked rather than flagged. They apply to the whole organisation. The tab needs the Manage safety permission; without it the tab is not shown at all.
Screenshot pending
Navigate to Safety > Settings signed in as a user holding Manage safety. Change the Release gate switch to Enforced without saving, so the UNSAVED CHANGES label and the enabled Save policy button both appear. Capture the whole tab: the four-tile readout band (Operating Mode, Release Gate, Conditions Currency, Daily Digest), the Clearance policy panel with both rows, the Evidence and digest panel with both rows, and the footer strip showing PROFILE PDRA01, EVALUATOR pdra01.v4, DIGEST and the Save policy button.
The four readouts show the draft, not the saved policy
The band across the top — Operating Mode, Release Gate, Conditions Currency and Daily Digest — reflects the settings as you have currently edited them, before you save. Switching the gate on shows the consequence in the band immediately; the organisation is unaffected until you press Save policy.
An UNSAVED CHANGES label appears beside the button whenever the draft differs from the saved record, and Save policy stays disabled until something has actually changed. The footer also prints the fixed facts: PROFILE PDRA01 and EVALUATOR pdra01.v4.
Operating mode
The How this organisation operates select. Three values, each with a one-line consequence printed beneath it.
- Solo — one accountable person. “Notices and forms are issued in one step and recorded as self-issued, signed by you. Use this when one person is the whole safety organisation.”
- Team — someone else reviews. “Documents are submitted for review and approved by whoever you assign. Self-review is available if you turn it on in the review policy.”
- Regulated — never self-review. “Documents always require a second person to approve them, and accepting a check that needs confirmation requires Safety override authority.”
| Operating mode | Self-review | One-step self-issue | Accept a Confirm to proceed finding |
|---|---|---|---|
| Solo | Always allowed | Available | The releasing pilot accepts their own |
| Team | Only if Self review is switched on in the form review policy. Off by default | Not available | The releasing pilot accepts their own |
| Regulated | Never allowed | Not available | Requires the Approve flight-release overrides permission |
Two notes on that table. In Solo and Regulated, the organisation-level Self review switch on the form review policy is ignored — the mode decides outright, and the switch reports what the server enforces rather than offering a choice that would not be honoured. And the Regulated description above calls the permission “Safety override authority”; the permission you actually switch on for a role is labelled Approve flight-release overrides.
One-step self-issue in Solo mode still creates a review request, still requires a valid saved signature, and is marked as self-issued in the trail. See Publish a controlled document.
Enforcement mode: the release gate
The Enforce the flight-release gate switch. The description states the rule: “When enabled, an operation with a blocking check cannot be cleared without a named user holding Safety override authority recording an expiring justification for that check. Checks that only need confirming are unaffected.”
| Release gate | A blocking check in the clearance dialog | Ticking Commence take-off or Start mission if safe to proceed |
|---|---|---|
| Advisory | Can be cleared without an override. The decision is recorded as a continuation, needs a written operational reason, and is audited at warning severity | Always permitted |
| Enforced | Cannot be cleared. The dialog button reads Blocked by N checks and is disabled until every blocker carries a per-check override from someone holding Approve flight-release overrides | Refused unless the job holds a valid current clearance |
The take-off column is the only place the gate reaches outside the clearance dialog. Ticking either of those two items on the Take-off checklist in the on-site survey is treated as starting the operation, and under Enforced it is refused when the job has no valid current clearance — including when the clearance exists but has regressed, been invalidated, or had its override expire. Every other item on that checklist is unaffected, and recording post-flight evidence is never gated.
Changing this setting is audited at warning severity, with the summary naming both the old and new mode. It is not retroactive: a clearance recorded under Advisory is still judged under Advisory, so switching the organisation to Enforced does not invalidate decisions already taken.
Site conditions currency
The Site conditions currency input, in whole hours. The description explains why there is only one: “How long an airspace, NOTAM and weather capture stays current. All three come from the same pre-flight capture, so they share one window. Going past it is advisory — it never stops a flight on its own.”
Underneath, three separate values are stored — a survey window, a weather window and a NOTAM window. The panel writes your single figure to all three, and the evaluator uses the shortest of them. If the three ever differ (from an older configuration), the panel displays the shortest.
The input accepts 1 to 24 hours. The server caps the survey window at 168 hours and the weather and NOTAM windows at 24 hours each. Out of the box the effective window is 2 hours.
Going past the window sets PDRA01_SITE_CONDITIONS_CURRENT to Advisory. It never becomes a blocker at any setting, and because advisory findings are excluded from clearance invalidation, a capture going stale does not invalidate a clearance already recorded. See Readiness checks.
Daily safety digest
Two controls under Daily safety digest: an Hour select from 00:00 to 23:00, and a Timezone text field. The description: “The digest is queued during this organisation-local hour. Use an IANA timezone such as Europe/London.”
The timezone must be a valid IANA identifier — Europe/London, not GMT or +00:00 — and is rejected if it is not. The digest job runs hourly and sends to each organisation when the hour matches its setting, so the digest arrives during that hour rather than exactly on it. The footer strip prints the combination back as DIGEST 08:00 Europe/London.
Saving
Press Save policy. A toast confirms with “Safety settings updated”. If nothing changed, the mutation is a no-op and no audit entry is written.
Last reviewed 28 July 2026 · verified against 18e3cb4