AI-generated editorial illustration by China Made & Tech. It depicts no real aircraft, passenger, operator, location, certificate, flight, or safety result.
By China Made & Tech Team. Independent English field guide to China’s niche hardware brands, hidden champions, founders, factory towns, and supplier clusters.
The most expensive mistake in reading the China drone industry is to turn every flying machine into the same question. A camera drone, a mapping platform, an agricultural aircraft, a docked inspection system, and a passenger eVTOL may share batteries, motors, sensors, radio links and Chinese suppliers. They do not share one decision file. Treating them as a single contest between “DJI” and “the rest” makes the category feel simple, but it hides the point at which a hardware comparison stops answering the question.
China’s own public framework starts with distinctions, not a national capability slogan. The country’s Interim Regulations on the Management of Unmanned Aircraft Flights, effective on January 1, 2024, define unmanned aircraft and divide them into micro, light, small, medium, and large categories by performance. The same rule draws a different airworthiness boundary for medium and large civil systems than for micro, light, and small ones. That does not tell a reader whether a particular aircraft can fly a particular mission. It does establish the right instinct: “drone” is not a sufficiently precise evidence category.
This guide maps the China drone industry through four connected systems:
- The aircraft and its exact configuration.
- The mission system: payload, crew, workflow, and the people or process on the ground.
- The control layer: controller, data link, software, cloud, integrations, and exit path.
- The operating and aviation-record layer: who operates, where, under which conditions, and what a named document actually covers.
The map is deliberately more useful than a market-share chart. It explains why DJI can be central to the category without becoming the answer to every enterprise decision, and why a passenger eVTOL document trail should be read as a series of specific records rather than a proof that “flying cars are here.” The final section turns the map into a programme file that a buyer, operator, analyst, or serious enthusiast can actually open.
Editorial systems map. It is a reading framework, not an approval path or an operational determination.
The China drone industry is connected, but it is not one product category
The category is genuinely connected. Shenzhen-style hardware supply chains make it possible for an aircraft maker to draw on motor, battery, camera, radio, controller, enclosure, software, and manufacturing capabilities that are close together in time and distance. A global reader sees the result as a compact product: a drone in a case, an enterprise bundle, or an eVTOL video. The industrial reality is closer to a chain of hand-offs.
At the first hand-off, a design becomes a physical aircraft. At the second, the aircraft becomes a mission tool through a payload, a pilot or remote crew, a workflow, and an expected output. At the third, the mission becomes a control-and-data problem. At the fourth, an operator tries to place that system into real airspace, a customer environment, and an applicable record of permissions, operating rules, insurance, or approvals.
Those stages depend on one another, but they do not prove one another. A stable aircraft does not prove that a survey output can be accepted by a customer. A good camera does not establish that a route, controller, or cloud workflow fits a sensitive site. A government record for a named model does not transfer to another model, operator, city, configuration, or year. A strong domestic hardware ecosystem does not decide a foreign customer’s policy, insurance, import, or data-governance boundary.
That is why a flat list of “Chinese drone companies” is usually a poor buying tool. It puts platform makers, component suppliers, enterprise software, agricultural operators, flight-service firms, low-altitude infrastructure projects, and passenger-aircraft programmes in the same row. The result answers an identity question—who exists—but avoids the harder question: which part of the system is responsible for the outcome I care about?
For a photographer, the aircraft and camera may dominate. For an infrastructure operator, route repeatability, payload, controller permissions, image handling, and maintenance response may matter more. For a farm, the operating team, crop plan, chemical procedure, weather, and local conditions can outweigh the airframe’s headline specification. For an aerial-mobility programme, design, production, airworthiness, operations, landing-site arrangements, and the role of the remote team are different evidence objects again.
This is not an argument that China is uniquely complicated. Aviation is layered everywhere. China matters because the category brings consumer-scale hardware, enterprise automation, industrial applications, low-altitude policy language, and passenger eVTOL ambition into the same public conversation. The four-system map prevents that conversation from becoming a single, unsupported “China leads” or “China risks” conclusion.
System one: start with the aircraft, but do not stop with the airframe
An aircraft file begins with the ordinary questions that broad industry coverage tends to skip: exact manufacturer, model, hardware revision, payload, batteries, controller, radio equipment, firmware, and intended mission. The point is not to create paperwork for its own sake. Each of those elements can change the actual object being evaluated.
The Chinese regulation makes this tangible. It defines unmanned aircraft as aircraft without an onboard pilot and with their own power system, then divides them into five performance-based categories. It says activities involving medium and large civil unmanned-aircraft systems require airworthiness permission, while micro, light, and small systems do not require that permission but remain subject to product-quality laws and mandatory standards. Those category and airworthiness distinctions are a useful starting map, not a classification result for any individual product.
The immediate implication is modest but important. An analyst cannot infer the relevant rule set from a marketing label such as “enterprise drone,” “agricultural drone,” “heavy lift,” or “flying car.” Those labels describe a commercial idea, a mission, or a category aspiration. They do not substitute for the technical information that places a real system in a defined class, nor do they identify every condition that applies after the system is deployed.
This is also where comparison culture can mislead. Two aircraft may appear close on flight time, camera resolution, payload capacity, or price. Yet they can have different controller options, approved payload combinations, repair arrangements, update behaviour, flight-log handling, or regional product versions. A model comparison is therefore most useful when it treats the aircraft as the beginning of the file. It becomes less useful when it treats the body in the case as the entire programme.
The distinction is especially valuable when an organization comes to China through a famous brand. DJI’s global dominance story explains why the company has become the reference point for so many buyers. But the reference point can become a blind spot. “Can another aircraft match DJI?” is often shorthand for several different questions: Can it carry the same payload? Can it reproduce the same mapping or inspection output? Can the team use the same controller routines? Can it be repaired through an acceptable channel? Can it operate under the same customer restrictions? Does it leave the same data trail? Those are not one test.
An aircraft-level file should therefore have a clean boundary. Record what the aircraft is. Record which configuration is being quoted. Record what is supplied versus optional. Record which firmware and control components are assumed. Record what the manufacturer says the system is intended to do. Then stop. The aircraft file should not quietly claim that the system can perform a regulated flight, a safety-critical inspection, a passenger service, or a sensitive-data workflow. Those claims belong to later files.
Why configuration is more important than the category name
The word “configuration” sounds narrow, but it often contains the decisions that determine whether a procurement programme remains flexible. A platform may be paired with different cameras, thermal sensors, LiDAR, spraying equipment, loudspeakers, lighting units, relays, storage options, controllers, docks, or software tiers. A buyer who asks only for a model name may receive an answer that is technically true and commercially useless.
The right mental move is to replace “Which drone?” with “Which documented system, in which configuration, for which job?” That wording does not slow a project down. It exposes the interfaces that otherwise emerge after a purchase order: an incompatible payload, a missed subscription, a controller that does not fit a restricted network, a service route that covers a different region, or a feature that exists only in a later software release.
This is also where China’s manufacturing depth becomes a benefit and a diligence challenge at the same time. Dense component and contract-manufacturing capabilities can create fast iteration and broad accessory ecosystems. They can also produce rapidly changing model families, similar-looking products, and complicated lines between a manufacturer’s standard offering, an integrator’s bundle, and an end user’s custom workflow. The reader should treat speed of iteration as an invitation to request an exact bill of materials and revision history, not as a universal quality signal.
System two: the mission system is where an aircraft becomes useful
An airframe has no business value in isolation. It acquires value when it captures something, moves something, observes something, applies something, maps something, or supports a response process. That mission system includes the aircraft, but it also includes the payload, the remote crew or field team, the controller, route plan, operating procedures, data output, and the person or system expected to act on the result.
China’s public material provides a concise way to see this. In the special conditions for the EH216-S project, the Civil Aviation Administration of China (CAAC) defines the named unmanned-aircraft system as the aircraft together with related ground control, mission payload, and command-and-control link. That project-specific system definition does not create a universal technical standard for every brand. It does capture the practical truth that the aerial vehicle is only one part of the technical object.
For enterprise teams, this is often the moment when procurement crosses into operations design. A road or power-line inspection programme may need repeatable routes, image review, annotations, asset IDs, exception handling, a link to an existing work-order system, and a clear person accountable for the final decision. A public-safety or emergency-response programme may need dispatch logic, communications, authority to act, retained footage, mutual-aid procedures, and a method for stopping work when conditions change. A mapping programme may need ground-control methods, deliverable definitions, accuracy validation, storage controls, and a customer who accepts the output.
In each case, a drone can be technically excellent and operationally incomplete. That is not a criticism of the platform. It is a reminder that the mission owns the success condition. An aircraft vendor can supply a tool; the operator and customer still need to define what a finished job looks like, what evidence proves it, and what happens when the system produces an ambiguous or unusable result.
DJI is a useful example precisely because its enterprise proposition reaches beyond the airframe. DJI describes FlightHub 2 as a cloud-based management platform with remote control, scheduling, route management, and third-party integration. That is a company description, not an independent finding about every deployment. Its significance is structural: it shows why the buyer may be choosing an operating workflow as well as a camera and a flight controller.
The practical question is not whether that workflow is inherently good or bad. It is whether the organization knows which parts of its own process become tied to it. A mature workflow can reduce manual hand-offs and help a team standardize planning, dispatch, collection, review, and reporting. It can also make a later switch harder if routes, permissions, historical records, integrations, staff habits, and decision rules have all become specific to one environment. DJI’s workflow-and-AI buyer file examines that gravity in more detail; this guide supplies the wider map for interpreting it.
Editorial mission-system map. A connected workflow can be valuable, but it does not establish the suitability of any named deployment.
The payload is not an accessory; it is part of the claim
Buyers often treat payloads as a shopping-list add-on. In a mission system, the payload is part of the statement being made. A visible-light camera supports a different output from a thermal sensor. A mapping camera and a LiDAR unit create different data products. A sprayer adds chemical, application, and operating-process questions that do not exist for a photography flight. A loudspeaker or spotlight may turn a platform into a communications tool with a different customer, public-interest, and procedure context.
That does not mean every payload needs an aviation dissertation. It means that the useful procurement line is not “drone plus accessories.” It is “named aircraft plus named payload plus named workflow plus a defined output.” Once that line is clear, a technical team can ask the questions that matter: Who owns the calibration or configuration? What does a software update touch? What files are generated? Which system receives them? Who can see, change, export, or delete them? What is the acceptance criterion when the work is done?
The same discipline helps when comparing Chinese suppliers other than DJI. The Autel Robotics dossier is a good example of why “DJI alternative” is not a completed decision. A brand, a product lifecycle, a support route, a seller, a controller, and an applicable customer rule can all be different. The four-system map prevents a reader from substituting a brand label for those facts.
System three: control, data, and workflows may be the real switching cost
The control layer is easy to ignore because it is less visible than an aircraft. It includes the ground controller, command link, user accounts, permissions, route libraries, flight logs, live video, media storage, cloud or local services, APIs, analysis tools, and the rules by which people or automated systems act on the information. It is where a product becomes an operating environment.
This layer matters even when a programme has no sensitive-data requirement. A survey team still needs to know how imagery moves from field collection to deliverable. An inspection team still needs to know which route version was flown and who can alter it. A fleet manager still needs to know who is permitted to dispatch an aircraft, change a configuration, or download a record. An organization that wants a fallback option still needs to know whether it can retain its history and reproduce essential work outside the original vendor’s stack.
None of those questions assume wrongdoing by a manufacturer. They are normal system-design questions. The risk is not “cloud” by itself, or “China” by itself, or even “vendor lock-in” by itself. The risk is making a dependency invisible until a programme is large enough that changing it becomes expensive. An enterprise drone is frequently a small aircraft, a field device, a data-collection tool, a user-management system, and a business-process application in one programme.
That is why an on-premises, local-control, or secure-workflow claim should be read at configuration level. It can refer to very different boundaries: where a service is deployed, which application traffic is allowed, which files remain local, what device operating system still does, who holds administrator rights, which integrations exist, and what a remote team can do. A buyer should map those boundaries before treating any deployment choice as a complete answer. The Matrice 400 local-control file takes that narrower question further for one named enterprise context.
The useful planning document is a control-path diagram. Start at the aircraft and draw every hand-off: aircraft to controller; controller to local storage or network; network to a vendor, customer, or integrator service; service to an analyst, dispatcher, or automated rule; and finally the result back into a work order, report, alarm, or decision. Mark which links are optional, which are required, and which can be replaced. The diagram need not claim that a system is compliant or non-compliant. It simply turns an invisible dependency into something a team can test and govern.
A programme should have an exit path before it needs one
An exit path is often mistaken for a declaration of distrust. It is better understood as ordinary operational resilience. If a supplier changes a product line, a service plan, a policy, an integration, or a regional offering, what remains usable? Can routes be exported in a usable format? Can mission histories be retained? Can a customer receive the files they need? Can controllers and payloads be reassigned? Can personnel move to another system without rebuilding every procedure from memory?
The answer will vary. Some operations reasonably value a tightly integrated workflow because it creates predictable training and fewer manual steps. Others need modularity because the customer, security environment, or technical stack changes frequently. The important point is to decide consciously. “The aircraft worked in the demonstration” is not the same as “the programme can survive a change in supplier, software, or policy.”
China’s drone ecosystem is especially good at making this distinction visible because products can move quickly from a standalone aircraft to an integrated dock, controller, payload, software, and service environment. That can be a genuine capability. It also means a reader should inspect the interfaces before comparing headline specifications. The deeper manufacturing context matters here: China’s industrial-cluster system can help explain why hardware and accessory ecosystems form quickly, but it cannot replace the exact workflow file for an individual programme.
System four: operation begins after the product page ends
The operating layer is where the biggest category errors appear. An aircraft may be sold, registered, technically capable, and familiar to the team, yet none of those facts alone decides whether a particular flight can happen in a particular place for a particular purpose. The relevant questions are about people, location, timing, airspace, rules, customer permissions, weather, risk management, insurance, and the programme’s own procedures.
CAAC’s 2023 regulatory-service notice says the civil-UAS UOM platform went online on January 1, 2024. It states that owners must complete real-name registration as required, that applicable airspace can be queried through the platform, and that specified flight-activity applications can be filed there. The same notice also lists exceptions and additional materials for certain activities, including some relay, dangerous-goods, dropping-item, crowd-overflight, moving-vehicle, distributed-operation, and swarm contexts.
The point is not to turn this page into a legal manual. The notice itself is dated, summarized, and tied to a regulatory implementation context. The point is to show why the operating layer exists. Registration is not a generic “check the box.” An airspace query is not a product feature. An application path is not an assurance that a flight will be authorised. An exception is not a broad freedom to operate. Each is a signal that the programme must identify the live authority, the mission, and the conditions that apply now.
For a corporate buyer, that changes the internal conversation. The aircraft file may be owned by procurement or engineering. The mission system may be owned by the operations team. The control path may involve IT, security, and data governance. The operating file may require a named operator, site owner, local team, insurer, and customer. If those people never meet until after the order arrives, the project is likely to discover its real constraints at the most expensive time.
This is also why a site demonstration can be misleading. A demonstration may prove that an aircraft can lift off, transmit video, or capture an image under the conditions of that event. It may not prove the repeatability of a recurring operation, the availability of trained personnel, the ability to obtain an appropriate authorisation, the integration of the output into the customer’s workflow, or the durability of the support arrangement. A proof of technology is not automatically a proof of programme.
Give each system an owner before the programme starts
One reason drone projects drift is that everybody assumes somebody else owns the next layer. Procurement owns the quote, so it assumes operations will settle the use case. Operations owns the pilot roster, so it assumes IT will settle the data path. IT can approve a network pattern, so it assumes the site manager has confirmed the operating conditions. A vendor may help with a product demonstration, so the customer assumes the proposed mission has been designed. None of those assumptions is necessarily unreasonable; together they leave the interfaces unowned.
A small programme can avoid that trap with a short responsibility map. One person should own the physical configuration and the supplier record. One should own the mission definition and acceptance criteria. One should own the controller, accounts, records, and integrations. One should own the operational decision path: site, timing, operator, current authority information, and stop conditions. The same person can hold more than one role in a small team, but the decisions should still be named.
This is not a substitute for specialist advice, and it does not create legal responsibility where none exists. It is a way to prevent a category error from becoming a project-management error. When the people responsible for the four systems review the same programme file, they can discover a conflict before it reaches the field: a required payload changes the actual configuration; a planned route needs a different output; a customer cannot accept the proposed data path; a site condition invalidates the original operating assumption; or a change in supplier support alters the resilience plan.
The four-system map is useful precisely because it makes those disagreements productive. Instead of arguing in general terms about whether a Chinese drone is “approved,” “secure,” or “enterprise-ready,” the team can locate the open question and give it to the right owner. That creates a better programme and a more honest use of the industry context.
The same distinction should shape how readers interpret Chinese low-altitude-economy discussion. Public enthusiasm, new facilities, pilot projects, or trade-show displays can be signals about industrial attention and experimentation. They are not a substitute for the operating file. A useful analysis asks: Which aircraft? Which mission? Which location? Which operator? Which authority or customer process? Which document is being cited? What happened after the demonstration? The questions may feel less exciting than a flying-car headline. They are more likely to predict whether the programme can repeat safely and economically.
Why eVTOL is an aviation-record problem, not just a bigger drone
Passenger eVTOL is where the four-system map becomes most valuable. It is tempting to place an autonomous passenger aircraft at the far end of a drone continuum: same motors, larger batteries, more sensors, more software, then a seat. That story is technologically suggestive and operationally inadequate. The presence of passengers changes the consequence of every hand-off, and the record must be read at a different level of specificity.
The public EH216-S record makes the difference visible without requiring a forecast. CAAC issued special conditions for the EH216-S project dated February 9, 2022. In a later CAAC regional record, the authority says the EH216-S received a type certificate on October 12, then records a production licence, PC0076A-ZN, issued on March 28, 2024. The same account says the first aircraft produced to the approved type design received a standard airworthiness certificate. That documented sequence is more informative than the shortcut “China approved a flying car.”
It shows separate questions being handled through separate records. Special conditions describe a project-specific certification basis. A type certificate concerns the approved type design in that process. A production licence concerns the manufacturer’s production system. A standard airworthiness certificate in the cited record concerns a particular aircraft built to the approved design. Those documents should not be collapsed into a single badge called “ready.”
| Named record in the EH216-S public trail | What it helps establish | What it does not establish |
|---|---|---|
| Special conditions dated February 9, 2022 | A project-specific basis for the named certification work | A generic eVTOL rulebook or operating permission |
| Type certificate referenced by CAAC | A documented type-design stage for the named project | Production capacity, a service launch, or another aircraft’s status |
| Production licence PC0076A-ZN | A named production-system record for the cited manufacturer | Passenger demand, airline-style operations, or a competitor’s manufacturing status |
| Standard airworthiness certificate for the first conforming aircraft | A specific-aircraft record described by CAAC | A sector-wide safety outcome or a standing right to run a commercial service |
An international comparison reinforces the principle while making its jurisdictional boundary clear. The U.S. Federal Aviation Administration describes its powered-lift framework as considering design, production, airworthiness, and operation, and it discusses a separate operator-certification framework. The FAA’s advanced-air-mobility explanation is not Chinese law and should not be used to infer a Chinese requirement. It is useful because it shows that aviation authorities can treat those layers as distinct evidence questions rather than one technical achievement.
For eVTOL readers, the disciplined question is therefore not “Has China solved flying cars?” It is: What exact aircraft and configuration are being discussed? What is the named intended operation? What design, production, airworthiness, operator, landing-site, airspace, communication, maintenance, emergency, and passenger-service record is available? Which claims belong to the manufacturer, which belong to an authority, and which remain future-looking? Those questions leave room for genuine technical progress without turning progress into a completed commercial conclusion.
What China’s manufacturing system can explain—and what it cannot
There is a real industrial story behind the four-system map. China’s electronics and manufacturing ecosystems can compress the distance between a component idea, a prototype, an accessory bundle, a pilot deployment, and a product revision. That helps explain why drone companies can create broad product families, why suppliers and integrators cluster around compatible components, and why hardware, payload, and software developments often arrive together.
But the manufacturing story has a boundary. It can explain how a system becomes easier or faster to build. It cannot, by itself, establish whether the system is the right choice for a customer. A customer may have a restricted network, a domestic-preference rule, a data policy, a local service requirement, an insurer’s condition, a union or workforce agreement, a mapping standard, a public-safety procedure, or a procurement rule that changes the answer. None of those constraints disappears because a platform has a deep supplier base.
The same caution applies to price. Lower hardware cost can create a useful option, especially in a field programme where losses, payload variety, or fleet scale matter. Yet an aircraft price is only one part of the programme’s cost. Add batteries, payloads, software, training, spares, repairs, travel, insurance, data storage, customer integration, compliance work, and downtime. A cheaper aircraft can be the more expensive system if it produces a workflow that the organization cannot support. A more expensive aircraft can be the worse choice if it locks the programme into functions it does not need.
That is why a China drone industry guide should not end with a national ranking. The reader’s advantage comes from understanding the manufacturing mechanism while preserving their own decision boundary. An ecosystem can offer fast iteration, component depth, and a wide range of platforms. It cannot decide the acceptance criteria for the final mission. The organization that defines those criteria first is better placed to use China’s hardware ecosystem on its own terms.
The exact programme file: move from industry story to decision evidence
Once the reader sees the four systems, the next step is not to collect more headlines. It is to open one programme file. That file should be small enough to use, specific enough to challenge, and owned by people who can update it when the programme changes.
Start with the object. Name the manufacturer, legal seller, exact aircraft, payload, controller, battery, firmware, and software version. Add the commercial terms that can change what is actually delivered: support tier, subscription, warranty counterparty, repair location, spare-parts route, and update policy. This is the aircraft-and-control file, not yet the approval file.
Then define the mission. Write down the task, location, operating team, customer, desired output, acceptance test, and failure condition. If the project is inspection, define what counts as a usable inspection result. If it is mapping, define the deliverable and who accepts it. If it is response or security work, define authority, escalation, storage, and review procedures. If it involves passengers, the mission should be even more explicit about the intended operation and the records that apply to it.
Editorial inquiry map. It helps organize questions for a named programme; it is not legal, safety, insurance, or procurement advice.
Draw the control path next. Identify where the route comes from, where the aircraft sends media and telemetry, where records are stored, who administers user accounts, what is integrated with a customer system, and what is retained if the service changes. Ask what is optional, what is required, and what can be exported. This is often the place where a procurement choice becomes a governance choice.
Only then open the operating file. Identify the owner and operator, the proposed location and time, the relevant current authority records, the site owner’s requirements, customer restrictions, insurance requirements, and the people accountable for go/no-go decisions. This guide cannot tell a reader what those requirements are for their mission. It can tell them not to treat an aircraft brochure, old certificate, or broad industry article as a substitute for them.
Finally, add a change log. The programme file should be revisited when a firmware update arrives, a payload changes, an operator changes, a new customer appears, a site moves, a cloud workflow is added, a certificate date changes, or a policy restriction becomes relevant. The most resilient programme is not one that predicts every change. It is one that makes its dependencies visible enough to notice when a change matters.
The resulting question is much sharper than “Are Chinese drones good?” It becomes: Does this named aircraft-plus-mission-plus-control-plus-operation system have the evidence required for this named use? That is the question a serious buyer can answer, and it is the question that makes the wider China drone industry legible.
Frequently asked questions
What is the best way to understand China’s drone industry?
Treat it as four connected systems: aircraft, mission, control layer, and operation. A country or brand overview can provide context, but an exact decision needs a named configuration, payload, workflow, operator, place, and current record set.
Does DJI’s position answer an enterprise-drone procurement question?
No. DJI may be a useful reference point because its products can include a broad aircraft-and-workflow environment, but a procurement decision still depends on the named model, payload, control path, service arrangement, customer restrictions, and intended operation. A famous brand is context, not an approval.
Are Chinese eVTOLs just larger drones?
No. The technologies can share components and automation ideas, but passenger aircraft raise distinct aviation, production, airworthiness, operating, and passenger-service questions. The EH216-S public record is useful because it shows separate document stages for one named project; it does not create a general eVTOL readiness verdict.
Do China’s drone rules decide whether I can fly a particular mission?
No. Public rules and service notices provide a framework, but the real answer depends on the exact aircraft, operator, mission, place, timing, local conditions, and current requirements. Check the live authority and qualified local advice before treating an industry page as an operational answer.
Method and limitations
This is a desk-research systems guide based on Chinese government and CAAC public records, a bounded DJI product description, and a jurisdiction-specific FAA comparison. It does not include aircraft testing, a factory visit, a cybersecurity assessment, an operator interview, a legal opinion, insurance advice, or a procurement approval. The page does not determine whether any aircraft, software service, operator, airspace, document, or passenger programme is safe, permitted, exportable, insurable, or suitable for a reader’s use.
Regulations, airspace information, product configurations, firmware, service terms, operator records, and customer restrictions can change. Before acting, recheck the exact source documents, live authority information, and the programme’s own technical, commercial, and operating evidence.