One drone traffic service can draw a route. The difficult part begins when another service draws a route through the same volume of sky.

On 6 October 2026, the UK Civil Aviation Authority opened a consultation on the information-sharing functions it believes could support uncrewed aircraft operating beyond visual line of sight at scale. The subject sounds like a bowl of aviation alphabet soup: CISP, DSS, UTM, ATM and SWIM. Underneath the acronyms is a very practical question. If several digital services help manage different drones, how do they discover one another, exchange current plans and receive authoritative information from conventional air traffic services?

The CAA’s consultation page says the proposal is provisional and asks for evidence on safety, resilience, competition, scalability, interoperability and affordability. It closes on 30 November 2026. This is not a new operating rule, an approval for routine BVLOS flights or the selection of a national technology supplier.

The problem is coordination, not drawing more icons

Low-volume drone operations can often be managed with bespoke procedures, limited operating areas and direct coordination. That approach becomes harder to sustain when many operators use different Uncrewed Aircraft System Traffic Management service providers, or UTMSPs, while conventional air traffic services remain responsible for the surrounding airspace.

In CAP3314, the 40-page consultation document, the CAA lists the risks it is trying to address: coordination failures between independent actors, limited interoperability, incomplete situational awareness, inconsistent access to authoritative information and barriers to operations that cross different airspace environments.

Those are proposed problem statements, not evidence that every present-day operation suffers from them. The consultation is testing whether new information-sharing requirements and functions are a proportionate response.

Three kinds of data have to meet

The CAA divides the information problem into three categories.

1. Flight intent shared between drone traffic services. When different UTMSPs manage aircraft in the same airspace, each needs enough information about the others’ planned operations to coordinate and deconflict them strategically.
2. Air traffic data shared with drone traffic services. The organisation providing air traffic services may hold surveillance and real-time airspace-management information that a UTMSP needs in order to operate in that airspace.
3. Other common operational data. Terrain is the consultation’s example, although the exact datasets are still to be determined as policy develops.

This separation matters because the data does not all come from one owner. A drone service may know the intended four-dimensional volume of its client’s operation. An air navigation service provider may hold radar-derived traffic information or a live airspace restriction. A geospatial provider may hold terrain data. Treating all three as one generic “airspace feed” would hide who is authoritative for what, how fresh the information is and who must correct it.

DSS is meant to help services find one another

For the first category, the CAA proposes a Discovery and Synchronisation Service, or DSS, wherever multiple UTMSPs operate in the same airspace. The initial purpose is strategic deconfliction: each provider should be able to discover other providers whose planned operations may overlap and then exchange the necessary intent information.

The proposed design is decentralised. CAP3314 says each UTMSP would be responsible for facilitating DSS functionality for the traffic it manages. At a high level, the service would share the spatial and temporal bounds of an operation—the planned volume plus time—and a contact URL for the provider that holds further detail. The CAA proposes trialling an approach based on ASTM F3548-21, an existing interoperability standard.

That is an important correction to the mental picture of a single national map containing every drone’s complete plan. The current proposal is closer to distributed discovery: enough shared information to identify a potential interaction and locate the relevant service, with further exchange between providers. The CAA is consulting on this architecture; it has not mandated a finished deployment.

CISP is a function, not necessarily one platform

The Common Information Service Provider, or CISP, addresses the second category. The consultation describes it as the bridge through which an organisation providing air traffic services makes appropriate ATM and air navigation data available to the UTMSPs operating in the same airspace.

The initial minimum dataset could include surveillance information, such as radar-derived information about crewed aircraft, and airspace-management information, such as restrictions, notifications and changes affecting use of the airspace. The CAA proposes that the organisation responsible for providing air traffic services in that volume of airspace should be responsible for making the data available.

But “CISP” does not mean the regulator has chosen one company, one product or one national database. CAP3314 repeatedly frames CISP as a function. The responsible air traffic service organisation might provide it directly or arrange for another organisation to do so on its behalf. The obligation the CAA is exploring is to make authoritative information available, not to buy a platform with a particular label.

The architecture changes with the airspace

The proposal is risk-based rather than identical everywhere. The CAA’s scenarios vary according to two questions: is an air traffic service being provided in the airspace, and is one UTMSP operating there or are several?

In the consultation model, CISP functionality becomes relevant where air traffic services are being delivered, because those services hold information the drone traffic providers need. DSS becomes relevant where multiple UTMSPs must coordinate with one another. The CAA even asks whether DSS is unnecessary when only one UTMSP is present, inviting evidence for cases where it might still be useful or should remain mandatory.

This is a proposal about system conditions, not a promise that any app will automatically make a flight lawful. Registration, operational authorisation, airspace permission, local restrictions and the pilot’s own responsibilities remain separate questions.

The hard questions are deliberately still open

The consultation is most useful where it does not pretend the engineering choice is settled.

Who may see which data?

More sharing can improve coordination, but unrestricted access could expose emergency-service activity, law-enforcement operations, commercially sensitive plans or personal data. The CAA proposes limiting information to authorised users with an operational need and asks what should be protected, how access should be controlled and what cyber-security safeguards are required.

Who is responsible when information is late or wrong?

CAP3314 allocates proposed responsibilities: UTMSPs would share flight intent and use relevant airspace data; air traffic service organisations would make their authoritative data available; the CAA may need to license and oversee the actors. The document does not yet turn that outline into final liability, performance or enforcement rules.

A practical implementation will need measurable answers about latency, availability, provenance, versioning, degraded modes and recovery. That sentence is an editorial inference from the proposed data flows, not a set of requirements already adopted by the CAA.

Who pays, and does the design preserve competition?

A centralised service may simplify some interfaces but concentrate operational and commercial power. A federated design may improve redundancy and market access while increasing integration and assurance work. A hybrid can inherit strengths—and complications—from both. The CAA asks for evidence on development, integration, oversight, resilience, ongoing operation and cost allocation rather than asserting that one model is automatically cheapest.

SWIM is the wider information fabric

CAP3314 places the proposed CISP and DSS functions within System Wide Information Management, or SWIM: a service-oriented environment in which aviation stakeholders publish, discover and consume assured information. A separate CAA SWIM consultation, open until 6 January 2027, is asking how common governance, standards and trust arrangements should develop across crewed and uncrewed aviation.

The distinction is useful. DSS is about discovery and synchronisation among drone traffic services. CISP is about making relevant air traffic information available to those services. SWIM is the broader information-management environment intended to help different aviation systems describe and exchange data consistently.

What operators and technology buyers should watch

Most recreational pilots do not need to choose a DSS implementation. Yet the consultation offers a good checklist for any claim that a drone traffic platform is “ready to scale”:

• Authority: Who created each dataset, and is that organisation authoritative for it?
• Freshness: When was the information generated, received and last updated?
• Interoperability: Can the service exchange intent and constraints with competing providers, or only with itself?
• Access control: Who can retrieve sensitive operational details, and what is visible to everyone else?
• Failure behaviour: What happens when a data source, network link or service becomes unavailable?
• Responsibility: Who must detect, report and correct an error?

These questions do not imply that every platform currently fails them. They are the evidence questions that follow from a system built on shared, time-sensitive data.

The consultation is a blueprint for questions, not an operational switch

The immediate event is modest: the regulator is asking for evidence before making policy or legislative decisions. No provider has been appointed. No specific delivery model, procurement, licensing framework or new law has been selected through this document.

That restraint is exactly why CAP3314 is worth reading. It moves the discussion beyond the idea that drone scale is achieved by putting more aircraft in the air. The real challenge is agreeing which information must move, who vouches for it, who may receive it and what the system does when the data or connection cannot be trusted.

The next meaningful evidence will come from consultation responses, trials, standards work and any later policy or legislative proposal. Until then, CISP and DSS are not permissions to fly. They are the UK’s current proposal for how the invisible conversation between traffic services might work.

Scope note: This article analyses UK CAA consultation documents current on 15 October 2026. It does not provide legal advice, report independent system testing or state that the proposed CISP/DSS model has been adopted.