Policies, in plain language

The consortium governs itself through agreed policies. Here are the two most important ones for newcomers, summarized, with links to the official text.

Policy · Effective April 8, 2026

Operational Prioritization

When two flights would conflict, which one yields? The consortium adopted two priority levels so that time-critical, life-safety missions aren't blocked by routine commercial flights.

This came out of a task force with the FAA, NASA, and industry. They recommended starting simple (two levels) and collecting data to validate how prioritization affects the airspace before adding complexity.

High Priority

Life-safety, time-critical

Reserved for missions where immediate response is essential for human safety:

  • Responding to a 911 call where safety of life is at stake
  • Active search-and-rescue
  • Delivering blood, plasma, AEDs, or Narcan when life is at stake
  • Disaster response where safety of life is at stake
  • Drone-as-first-responder (DFR) missions
Standard Priority

Everything else

All routine operations that don't meet the life-dependent bar:

  • Standard package delivery
  • Infrastructure inspection
  • Photography and data collection
  • Training missions (even for public-safety operators)
  • Routine delivery of basic medical supplies
How it behaves in the air. When a high-priority operation overlaps another, providers notify the affected operator per the ASTM standard, and accepted, standard priority flights must re-plan. Currently, no one is required to re-plan if in-flight. And at every level, two equal-priority flights are never allowed to conflict.

Qualifying to fly high priority

An operator can't just self-declare. To use high priority, you:

No standard document fits? You can propose an alternative artifact with a rationale for the Operations Committee to review. Once your ticket is accepted, you may use high priority for all applicable missions.

Read the full prioritization policy →
Policy · Effective August 27, 2024

DSS Pooling & Governance

The Discovery & Synchronization Service (DSS) is the shared backbone that lets providers find and sync with each other's operations. This policy keeps it robust and makes clear who owns what.

Predictable, yet flexible

Give providers and regulators predictability around the DSS pool, while allowing the flexibility to use other instances to keep the network robust.

Clear ownership

Every DSS instance is tied to a provider who keeps technical and governance responsibility for its performance.

Monitored over time

Pool performance is watched continuously, with governance and technical requirements adjusted to address safety or performance issues.

The essentials

Severity. A failure of a whole DSS instance is treated as a Severity 2 event. A single node failing within an instance does not, by itself, trigger SLA resolution.

Read the full DSS governance policy →

Policies can change, by consensus

Any affected stakeholder can propose a change through the Issue Resolution process in the governance agreement (Annex C, Section 7(h)), including new priority levels or changes to who qualifies. That's the consortium's commitment to evolving with real operational learnings.