← All playbooks
Standards & compliance18 min read

Running SORA 2.5 to a SAIL II approval

Assemble a SORA 2.5 package a regulator can review, while keeping a hard boundary between calculated evidence and accountable human judgement.

Use this playbook to turn a proposed operation into a reviewable SORA work package. It is a working sequence, not a substitute for the current JARUS publication, national guidance, or an authority decision.

Frame the ConOps and operational volume

Start with the purpose of the operation, aircraft, crew, command-and-control path, contingency behavior, and the people or infrastructure exposed below it. Draw the flight geography, contingency volume, and ground-risk buffer as separate objects. Record the source, author, timestamp, and coordinate reference for every imported geometry.

Do not begin by selecting a desired SAIL. Begin with the operation you can actually conduct. A reviewer should be able to trace every later mitigation back to a stated hazard or operating constraint.

Exit record: approved ConOps revision, named accountable owner, frozen operational volume, and a list of unresolved assumptions.

Establish intrinsic ground risk honestly

Classify the operating environment and population exposure using the methodology and edition accepted by the relevant authority. Attach the datasets, survey dates, and uncertainty notes used to support the classification.

Only claim a lower ground risk when the operation genuinely changes: reduce the exposed area, change the operating time or location, or introduce an accepted mitigation with evidence. A text note that says “low density” is not a mitigation.

Operator check: reopen the map at the stated time window and confirm that the evidence still describes the intended operation.

Determine air risk and residual ARC

Describe the encounter environment, adjacent airspace, traffic information sources, and strategic mitigations. Separate what the platform observes from what is inferred. A blank surveillance area is an unknown area, not proof of an empty sky.

Record the initial ARC, each strategic mitigation, its evidence, and the residual ARC. If an authority supplies a local classification or procedure, preserve that decision as a referenced artifact rather than overwriting the original assessment.

Read SAIL and assign OSOs

Use the resulting ground and air risk to derive the SAIL using the configured SORA version. Then review every Operational Safety Objective at the required robustness. Assign an owner, evidence target, and due date; “compliant” without an artifact is not a completed OSO.

Keep organizational evidence, aircraft evidence, and operation-specific evidence distinguishable. Reusable material may be referenced across assessments, but the assessment must pin the exact version used.

Run the advisory preflight gate

The go/no-go surface checks the frozen assessment against current operational inputs such as approval state, weather limits, airspace constraints, crew readiness, aircraft state, and unresolved findings. It produces a recommendation and reasons.

It must not authorize or activate the operation. The human decision records the actor, time, assessment revision, acknowledged warnings, and any authority reference. A changed route, aircraft, risk input, or material constraint invalidates the stale result and requires another run.

Assemble and review the submission pack

Export the ConOps, maps, risk steps, OSO matrix, evidence index, approvals, and change history as one versioned package. Verify the export offline and confirm that every link resolves inside the package.

Before submission, run a hostile-reader review: can someone who did not build the operation understand each conclusion, reproduce each calculation, and identify every human judgement? Record findings and close them against a new package revision rather than editing the issued artifact.

Completion checklist

  • The operation and volume are frozen to a named revision.
  • Ground and air classifications cite their evidence and uncertainty.
  • Every mitigation has an owner and accepted proof.
  • Every required OSO has an artifact or an explicit open finding.
  • The advisory gate is separated from authorization.
  • The exported package verifies offline and carries a content hash.