Regulatory Statement

1. Platform scope and purpose

FlightDocket is a regulatory evidence and operational governance platform for UAS operators. It is designed to support compliance with SACAA Part 101 RPAS operations conducted under a UAS Operator Certificate (UASOC) and supports preparation of structured risk assessments aligned with JARUS SORA methodology for submission to the applicable aviation authority under Part 108.

2. What FlightDocket is not

FlightDocket is not a SACAA system, is not an ICAO-accredited system, is not a JARUS-endorsed tool, and is not an ECCAIRS-certified reporting gateway. The platform does not constitute, replace, or grant any regulatory approval, certification, or authorisation. It is not a regulator. References to regulatory frameworks on the platform or on this website describe the frameworks the platform is structured against, not a claim of accreditation or endorsement by those bodies.

3. Authority model

Every mission on the platform is governed by a two-party authority model:

• FlightDocket issues advisory. The platform runs automated assessments, issues recommendations, records evidence, monitors credentials, and retains the audit trail.
• The tenant operator authorises. The tenant-appointed approver reviews the assessment package, records their reason, and authorises under their own UASOC. Authorisation is a deliberate human act with a multi-factor signature.

Advisory is never authorisation. Authority never transfers to the platform. Until the appointed approver records an affirmative decision, no mission advances. There is no auto-approval, no platform override, and no exception.

4. Part 108 specific-category pathway

For operations outside the standard Part 101 modes in the operator's UASOC, regulatory authority cannot be granted internally. FlightDocket runs a structured JARUS SORA v2.5 ten-step risk assessment, prepares a Part 108 dossier, and the operator submits the dossier to the applicable aviation authority. The aviation authority authorises (or refuses) the specific-category operation. Once authorised, missions are flown under the regulator's authorisation and still generate ordinary Flight Operations Manuals under the platform's normal mission workflow.

FlightDocket does not self-authorise Part 108 operations, does not grant Part 108 authorisation, and does not replace any function of the applicable aviation authority.

5. Out of scope

Part 102 specific-authorisation operations and Part 127 commercial air services / ATC coordination are outside current platform scope. These operational categories may be added in future releases; until then, operators requiring Part 102 or Part 127 pathways must rely on their own compliance arrangements.

6. Automation and human decisions

Where the platform applies automation to support mission preparation — environmental and terrain assessment, post-flight review, structural review, narrative validation — every output is treated as advisory input to a human decision. Automation never issues a regulatory authorisation, never bypasses a policy gate, and never sits on the critical path for mission approval. The operator's appointed approver reviews the data and decides. Every automated output is versioned and retained in the evidence archive so the exact input-to-output state is reproducible on review. If an automated service is unavailable, the mission pipeline falls back to deterministic policy rules and continues to operate; no approval depends on automation being available.

7. Evidence retention and integrity

Evidence records are stored using versioned, access-controlled, and retention-governed storage with cryptographic integrity controls, designed to support long-term evidentiary requirements (including multi-year retention). Mission artefacts are SHA-256 hashed at point of capture, stored in an append-only archive, and retrievable by the operator for disclosure to regulators, insurers, boards, or auditors.

Evidence retention and integrity controls are designed to support audit and regulatory review. Interpretation and acceptance of such evidence remain the responsibility of the reviewing authority.

8. Audit trail

All actions, records, and changes are logged with time, user identity, and context to provide a traceable audit trail supporting internal review, external audit, and regulatory inspection. Audit logs are append-only and designed to preserve historical state for review.

9. Access control and identity

Access to platform functions is controlled through role-based access control (RBAC), multi-factor authentication (mandatory on every account), and secure identity management practices. Sensitive operations and administrative access are additionally protected using certificate-based controls. Multi-factor authentication is not optional and cannot be disabled at the tenant or user level.

10. Scoring, trust levels, and decision-support outputs

Operational quality scoring, trust-level progression, and similar risk and compliance indicators are provided as decision-support tools for internal platform behaviour (queue priority, SLA targets, auto-approval of qualifying sorties within the operator's own UASOC). They do not constitute regulatory determinations and are subject to operator and auditor verification. Final regulatory authority and approval remain with the applicable aviation authority.

11. Regulatory and standards framework

The platform's assessment pipeline, evidence model, and audit reports are structured against the following frameworks:

• SACAA CAR/CATS Part 101 — RPAS commercial operations in South Africa
• TGM Part 101 Operations Manual — current edition
• Air Services Licensing Act 115 of 1990
• ICAO Annex 19 — Safety Management, and Doc 9859 Ed.4
• JARUS SORA v2.5 — specific-category risk model (forward design, used for Part 108 dossier preparation)
• ECCAIRS — occurrence taxonomy and E5X export format
• Protection of Personal Information Act 4 of 2013 (POPIA) — for personal data handling (see our Privacy Policy)

Alignment with a framework is not endorsement or accreditation by the body that owns the framework. See Section 2.

12. Auditor-safe summary

13. System-level claims

System-level claims on the FlightDocket website and within the platform describe the platform's design principles and operational intent. They are not warranties of regulatory outcome. Where this statement and any other page, document, or statement on the FlightDocket platform conflict, this statement governs.

14. Changes to this statement

We review this statement at least annually and whenever changes to the platform, the regulatory environment, or the frameworks referenced above materially affect the scope or operation of the platform. Material changes are notified to active tenants at least thirty (30) days before they take effect. The current version of this statement is always published at flightdocket.com/legal/regulatory.html.

15. Publisher and contact