Configuration Baselines Are the Discipline BVLOS Autonomy Needs Before Scale

BVLOS Autonomy Programs Need Configuration Baselines Before They Scale

Autonomous aircraft programs tend to talk about capability.

How far can the aircraft fly? How much payload can it carry? How well does the detect-and-avoid stack perform? How many routes can the operator supervise? How much of the mission can the system execute without human intervention?

Those are important questions.

But as unmanned aircraft programs move toward beyond visual line of sight operations, there is another question that deserves more attention:

Which exact system are we approving, operating, and learning from?

That sounds simple until the program begins to scale. The aircraft hardware changes. The autonomy software changes. The sensor package changes. The control station changes. The route library changes. The communications provider changes. The operator procedures change. The training material changes. The maintenance interval changes. The ground risk profile changes. The supporting data service changes.

Each change may be reasonable on its own. Together, they can quietly separate the fielded system from the evidence used to justify it.

That is why BVLOS autonomy programs need configuration baselines before they scale.

A configuration baseline is not paperwork for its own sake. It is the controlled definition of the system that connects engineering evidence, operational approval, safety claims, training, maintenance, cybersecurity, and field performance. In aerospace terms, it helps leadership answer a hard question with discipline: are we still operating the system we believe we verified?

BVLOS Makes Configuration Control A Safety Issue

The FAA's BVLOS direction points toward a more normalized framework for routine drone operations, including operational authorizations, aircraft requirements, separation, security, reporting, and recordkeeping. The FAA has also described proposed Part 108 as a path for more scalable low-altitude UAS operations, with different expectations for lower-risk permits and higher-risk certificates.

That shift matters because BVLOS is not just visual line of sight with a longer route. It changes the safety architecture.

The operator may not be watching the aircraft directly. The system may depend on onboard autonomy, detect-and-avoid functions, command-and-control links, remote identification, lighting, route constraints, fleet supervision, third-party services, and defined operating procedures. Certified operators may need a stronger management structure, training program, and safety management discipline than a small one-aircraft operation.

In that environment, configuration control becomes more than an engineering hygiene topic.

It becomes part of the safety case.

If the aircraft flew the demonstration with one software version but enters routine service with another, leadership needs to know what changed. If a route was evaluated with one sensor configuration but fielded with a different payload, the safety assumptions need review. If a detect-and-avoid function depends on a service interface, the version and performance assumptions behind that interface matter. If operators are trained on one alerting philosophy but the software update changes alert timing, human factors evidence may no longer apply cleanly.

The issue is not that change is bad. Autonomous systems must improve. The issue is unmanaged change.

The Baseline Has To Cover The Whole Operating System

A weak configuration baseline only tracks aircraft serial numbers and software versions.

A serious BVLOS baseline covers the operational system.

At minimum, the program should know the approved baseline for:

• aircraft hardware configuration
• autonomy software version
• flight control software version
• sensor package and calibration state
• command-and-control equipment
• ground control station release
• mission planning tools
• route library and geofencing data
• detect-and-avoid configuration
• remote ID and lighting configuration
• communications provider or link architecture
• operator procedures
• training baseline
• maintenance requirements
• cybersecurity controls
• data recording and telemetry requirements

That list can feel heavy. In practice, it prevents confusion.

When an anomaly occurs, the team should not spend days discovering which software release was flying, which route file was loaded, whether the aircraft had the new sensor firmware, or whether the operator was following the latest procedure. The baseline should already make that visible.

When a route expansion is proposed, leadership should know whether the current aircraft, software, training, and telemetry baseline match the evidence from earlier testing.

When a supplier changes a component, the program should know which verification credit is affected.

That is the difference between scaling an aircraft and scaling an operation.

Software Updates Can Expire Old Confidence

Autonomy makes software change especially important.

In a conventional system, a software update may improve usability, fix bugs, or add functions. In an autonomous UAS, a software update can change how the aircraft detects, decides, prioritizes, alerts, reroutes, degrades, or recovers.

That means the update can affect the behavior the safety case depends on.

A change to obstacle logic may affect route clearance. A change to alert thresholds may affect operator response. A change to contingency sequencing may affect lost-link behavior. A change to perception filtering may affect detect-and-avoid performance. A change to mission planning may affect energy reserves. A change to data logging may affect post-event reconstruction.

None of those changes should move into BVLOS operations on a vague statement that the latest version is better.

The program needs a disciplined release gate:

• What changed?
• Which requirements are affected?
• Which hazards are affected?
• Which evidence still applies?
• Which evidence must be repeated?
• Which operator procedures or training material must be updated?
• Which telemetry should be monitored after release?
• What is the rollback plan?

This is where configuration management and verification strategy meet. A program that cannot connect software change to safety evidence is not ready for routine autonomous operations at scale.

Routes Are Configuration Items Too

Drone programs often treat aircraft and software as configuration-controlled assets but treat routes as operational details.

For BVLOS, that is risky.

A route is part of the system. It defines terrain, obstacles, population exposure, communications coverage, emergency landing options, airspace constraints, launch and recovery geometry, local procedures, and contingency planning. A route can make a mature aircraft look safe, or it can expose gaps the aircraft was never designed to handle.

That means a BVLOS route library should be controlled with the same seriousness as software.

Each approved route should have:

• a version-controlled route file
• defined operating limits
• ground risk assumptions
• airspace assumptions
• communications assumptions
• contingency landing or recovery logic
• known hazards
• required aircraft and sensor baseline
• required crew or supervision model
• approval history
• telemetry review triggers

If a route changes, the baseline changes.

If construction adds a new obstacle, the baseline changes. If communications coverage degrades, the baseline changes. If the operation shifts from one aircraft type to another, the baseline changes. If the mission moves from daytime to night, the baseline changes.

BVLOS route management is not just mapping. It is engineering configuration control applied to geography.

Human Factors Belong In The Baseline

Autonomy does not remove people from the system. It changes their role.

In BVLOS operations, the human may supervise multiple aircraft, monitor alerts, approve reroutes, coordinate with field personnel, intervene during degraded states, or decide when to stop an operation. That human role depends on interfaces, training, procedures, staffing, fatigue management, alert design, and authority boundaries.

Those elements should be baselined.

If the user interface changes, the human factors evidence may need review. If alert priority changes, training may need revision. If one operator begins supervising more aircraft, workload assumptions change. If a new procedure changes decision timing, the safety case changes.

A strong program does not treat human factors as a soft add-on after the engineering is complete. It treats the operator model as part of the system architecture.

The baseline should answer:

• Who is responsible for which decision?
• What information does the operator see?
• What authority does the automation hold?
• When does authority shift back to the human?
• How much time does the human have to act?
• What training version supports the current operation?
• What evidence shows the operator can perform under expected workload?

If those answers are not configuration-controlled, the program may be scaling on informal assumptions.

Cybersecurity Is Part Of Configuration Discipline

The FAA's BVLOS materials emphasize security alongside operational and aircraft requirements. That is appropriate because connected unmanned systems create new surfaces for risk.

Autonomous UAS operations can involve aircraft software, ground control systems, cloud tools, route databases, identity systems, communications links, telemetry pipelines, maintenance laptops, supplier updates, and operational dashboards.

Every one of those interfaces can become a configuration issue.

The program should know which software is authorized, which devices can connect, which data paths are approved, which credentials are active, which supplier packages are trusted, and which logs are required for review. Cybersecurity cannot be a separate checklist that floats outside the operational baseline.

For BVLOS autonomy, a cybersecurity change can become an operational safety change.

If a telemetry pipeline changes, monitoring assumptions may change. If an access control process changes, maintenance risk may change. If a supplier update process changes, software assurance may change. If a cloud dependency changes, mission continuity assumptions may change.

Configuration discipline gives cybersecurity a place in the real operating system instead of leaving it as a policy binder.

Telemetry Should Confirm The Baseline Is Holding

Once operations begin, telemetry should do more than populate dashboards.

It should help confirm whether the approved baseline is behaving as expected.

A mature telemetry program can show recurring route degradation, link quality patterns, repeated operator interventions, software-specific anomaly trends, maintenance-driven performance drift, sensor health changes, or contingency triggers that cluster around a particular configuration.

That creates a powerful feedback loop.

The baseline defines what is approved. Telemetry shows what is happening. Anomaly review identifies whether the baseline still supports the operation. Change control decides whether the system needs a new release, new training, new procedures, new route limits, or new verification work.

Without that loop, telemetry becomes passive monitoring. With it, telemetry becomes continuing assurance.

The Leadership Lesson

BVLOS autonomy will not scale on aircraft performance alone.

It will scale when program leaders can connect capability to configuration, configuration to evidence, evidence to operational limits, and field performance back to engineering action.

That is the real value of a configuration baseline.

It protects the organization from stale confidence. It forces software releases, route changes, operator procedures, cybersecurity controls, and safety evidence into one management structure. It helps leaders decide when a change is minor, when it needs regression testing, when it affects training, and when it should stop a route expansion.

For autonomous UAS programs, the baseline is not bureaucracy.

It is the operating definition of trust.

Before a BVLOS program asks how many aircraft it can scale to, it should answer a more basic question first:

Do we know exactly what system we are scaling?

Sources

• FAA, "Beyond Visual Line of Sight (BVLOS)": https://www.faa.gov/newsroom/beyond-visual-line-sight-bvlos
• FAA, "Beyond Visual Line of Sight (BVLOS) Fact Sheet": https://www.faa.gov/newsroom/fact_sheets/Fact_Sheet_BVLOS.pdf
• FAA, "Package Delivery by Drone (Part 135)": https://www.faa.gov/uas/advanced_operations/package_delivery_drone
• FAA, "2026 Aviation Safety Oversight and Certification Workforce Plan": https://www.faa.gov/sites/faa.gov/files/2026-AVS-Workforce-Plan.pdf