They asked better questions.

Not more questions. Better ones.

It wasn’t always obvious at the time, and I doubt many of them consciously followed the same process, but the pattern has become increasingly clear to me. The strongest operational decisions I’ve witnessed have almost always been preceded by four simple questions.

They’re not unique to aviation and they’re certainly not unique to UAS. In fact, I’d argue they apply to almost any complex activity where people, technology and uncertainty come together.

They’re also deceptively simple.

What do we believe?

How do we know?

What are we assuming?

What would change our mind?

On the surface, they sound almost too straightforward to be useful. In reality, I’ve found they expose weaknesses in an operation remarkably quickly.

The first question is usually the easiest.

What do we believe?

Every operation begins with beliefs. We believe the aircraft can achieve a particular endurance. We believe the command and control link is sufficiently robust. We believe the weather forecast is accurate enough to support the mission. We believe our procedures are appropriate, and we believe the people carrying them out understand them.

There’s nothing wrong with belief. In fact, planning would be impossible without it. The problem is that beliefs have a habit of becoming facts in our own minds long before they’ve earned that status.

That’s why the second question matters so much.

How do we know?

It’s surprising how often this question changes the conversation.

I’ve sat in meetings where everyone around the table was convinced a particular capability existed, only for somebody to ask how we actually knew. Suddenly the discussion changed from certainty to evidence. Instead of repeating assumptions, people began searching for demonstrations, test results, operational experience and observations that genuinely supported the claim.

Sometimes the evidence was there.

Sometimes it wasn’t.

And occasionally everyone realised they had simply inherited somebody else’s confidence.

That’s an uncomfortable moment, but it’s also an incredibly valuable one.

The third question is where things become even more interesting.

What are we assuming?

Every operation contains assumptions. They aren’t signs of poor planning; they’re an unavoidable consequence of working in uncertain environments. We assume radio performance will remain consistent. We assume GNSS coverage will be available. We assume operators will behave in predictable ways under pressure. We assume the environment won’t introduce something we’ve never encountered before.

The danger isn’t that assumptions exist.

The danger is that they slowly disappear into the background until nobody remembers they’re assumptions at all.

After enough successful flights, an assumption can quietly transform into “something we know”.

Except we don’t.

We simply haven’t challenged it recently.

I’ve come to think of assumptions as operational debt. Much like technical debt in engineering, they accumulate quietly while everything is working well. Most of the time they remain invisible, right up until the operation becomes more ambitious, more complex or moves into a new environment. Then suddenly that debt has to be repaid, often at exactly the moment you’d rather it didn’t.

The final question is probably my favourite because it says more about an organisation than almost anything else.

What would change our mind?

When I ask this during reviews or planning sessions, there’s often a pause.

Not because people don’t understand the question, but because they’ve never really considered it.

If our aircraft loses the command link under conditions we believed were well within its limits, would that change our understanding?

If a procedure that worked perfectly during rehearsals falls apart under operational pressure, would we rethink it?

If a regulator challenges an argument we’ve been confident about for months, are we prepared to revisit our thinking?

Or have we already decided we’re right?

To me, this is the point where testing and proving part company.

Testing accepts the possibility that our understanding is incomplete.

Proving begins with the assumption that we’ve already reached the answer.

One is driven by curiosity.

The other by confirmation.

The best operators I’ve worked alongside have always been willing to change their minds when the evidence demanded it. Not because they lacked confidence, but because they understood that confidence should follow evidence, not replace it.

Looking back over the articles I’ve written so far, I realise these four questions have been there all along.

The gap exists because belief and reality rarely align perfectly.

Evidence helps us understand what we actually know.

Assumptions explain why operations drift away from the plan.

Testing provides opportunities to change our minds before the real world does it for us.

Perhaps that’s why these four questions have become increasingly important to me. They aren’t really questions about aircraft or regulations.

They’re questions about thinking.

And if there’s one lesson the industry has taught me over the years, it’s that better operations rarely start with better answers.

They start with better questions.

—

The Four Questions

Before your next operation, test, design review or SORA, ask yourself:

1. What do we believe?

2. How do we know?

3. What are we assuming?

4. What would change our mind?

You might be surprised by the conversation that follows.

— Notes from the Gap

What often receives far less attention is the chain of assumptions that existed long before the problem appeared.

Every operation is built upon assumptions. That isn’t necessarily a flaw in the process; in many ways it’s unavoidable. We assume the aircraft will perform as expected, that the environment will remain within certain limits, that people will follow procedures, that communications will be available when needed, and that the data informing our decisions is accurate. Without assumptions, it would be impossible to plan anything at all.

The problem isn’t that assumptions exist. The problem is that they have a habit of becoming invisible.

The longer an assumption survives without challenge, the more it starts to feel like a fact. Eventually it becomes something that everybody “knows” and, perhaps more importantly, something that nobody feels the need to question. That’s usually where the trouble begins.

I’ve seen this happen repeatedly in testing programmes. A team develops confidence in a capability because it has worked consistently within a particular environment. Over time, that capability stops being viewed as an assumption and starts being treated as an established truth. Then the operation moves somewhere new, the environment changes, or the conditions become slightly more demanding. Suddenly the capability behaves differently and everyone is left wondering what changed.

Often, the answer is very little.

The aircraft hasn’t changed.

The technology hasn’t changed.

What changed was the context in which an assumption was being tested.

What looked like a proven capability was actually a context-dependent assumption that had survived long enough to be mistaken for a fact.

-Notes from the Gap

Evidence for a SORA.

Evidence for an Operational Safety Case.

Evidence for certification.

Evidence for a regulator.

Evidence for a customer.

Evidence for a test programme.

Everyone agrees it’s important, yet if you stop and ask people what they actually mean by evidence, the answers can vary wildly.

Some will point towards reports, spreadsheets, photographs, videos, flight logs, or test results. Others will describe successful demonstrations or completed trials. None of those answers are necessarily wrong, but I’ve increasingly come to believe that many of us spend a lot of time collecting things that look like evidence without ever asking whether they are actually helping us understand anything better.

The definition I keep coming back to is surprisingly simple:

Evidence is information that reduces uncertainty about a decision.

That might sound like a subtle distinction, but I think it changes almost everything.

For example, I often hear people talk about successful flights as though they are evidence in themselves. Sometimes they are. Sometimes they aren’t. The important question isn’t whether the aircraft flew successfully; it’s whether the flight reduced uncertainty about something we didn’t fully understand beforehand.

If I fly the same aircraft ten times, in the same conditions, with the same assumptions, and everything behaves exactly as expected, I will probably feel more confident by the end of it. The team will feel more confident. The customer may feel more confident. The programme manager will almost certainly feel more confident.

But confidence and evidence are not the same thing.

Confidence is a feeling.

Evidence is understanding.

That’s a distinction that often gets lost.

Those ten flights may have increased everyone’s confidence while contributing very little new evidence. If nothing was learned, no assumptions were challenged, and no uncertainties were reduced, then all we have really done is repeat what we already believed.

That doesn’t mean the flights were worthless. Building confidence has value. The problem comes when we start mistaking confidence for understanding.

Interestingly, some of the most valuable evidence I’ve ever seen has come from things not going to plan.

A communications issue appears where nobody expected it.

A procedure works perfectly during rehearsal but becomes awkward under operational pressure.

An aircraft behaves differently in a new environment despite having performed flawlessly elsewhere.

Nobody enjoys discovering those things in the moment. They can be frustrating, expensive, and occasionally embarrassing. Yet they are often the points at which genuine learning takes place.

The operation understands something afterwards that it didn’t understand before.

Uncertainty has been reduced.

Evidence has been created.

That’s one of the reasons I often find failure more interesting than success.

Success tends to confirm what we already think we know.

Failure has a habit of exposing what we don’t.

The challenge is that organisations naturally reward confidence. Customers like successful demonstrations. Programmes like positive results. Teams enjoy proving that things work. It’s understandable. Success feels good.

But if the objective of testing is simply to prove that we’re right, we can miss some of the most valuable learning opportunities available to us.

Good testing isn’t really about proving ourselves right.

It’s about becoming less wrong.

The more I work in testing, operations, assurance, and regulation, the more I see evidence as a progression rather than a single event.

It usually starts with an assumption.

We believe something to be true. Perhaps we believe an aircraft can achieve a certain performance level, that a procedure will work in a particular situation, or that an operation can be conducted safely within a given environment.

At that point, there is very little evidence. There is mostly belief.

Then we begin to observe. We watch the system, the people, and the environment interact. Some observations support the assumption. Others challenge it.

Next comes testing. We deliberately create opportunities to explore the uncertainty. We place assumptions under pressure and see how they respond.

As testing expands across different scenarios, environments, and conditions, our understanding begins to mature. Eventually, the evidence becomes operational. The capability isn’t simply demonstrated once; it consistently behaves as expected in the real world.

Only then can we start talking about proven capability with any real confidence.

Ironically, confidence arrives naturally when evidence is strong. Problems arise when we try to achieve confidence without first building evidence.

This way of thinking becomes particularly important once regulation enters the picture.

Many operators assume regulators are primarily interested in documentation. In reality, documentation is often just the vehicle used to communicate understanding.

What regulators are really trying to determine is whether the operation appears credible, understood, and controlled. Strong evidence helps answer those questions. Confidence alone does not.

A beautifully written document supported by weak evidence remains weak. Equally, a simple document supported by strong evidence can be remarkably persuasive.

The same principle applies whether we’re talking about a SORA, an Operational Safety Case, a certification activity, or a flight test programme. The quality of the evidence behind the claims will always matter more than the elegance of the wording used to describe them.

Perhaps that’s why operational maturity and evidence are so closely linked.

Mature operations tend to understand their limitations. They understand their assumptions. They know where uncertainty still exists and where it has already been reduced. Immature operations often struggle to make that distinction.

One of the most useful questions I’ve learned to ask during testing is surprisingly simple:

What uncertainty are we trying to reduce?

If nobody can answer that question, there is a good chance we’re collecting activity rather than evidence.

And there is a difference.

The longer I spend around operations, testing, and approvals, the more convinced I become that our objective should never be to prove ourselves right. Our objective should be to improve our understanding.

Every meaningful piece of evidence reduces uncertainty.

Every reduction in uncertainty improves the quality of our decisions.

And better decisions ultimately lead to better operations.

That’s what evidence is really for.

Not confidence.

Understanding.

Confidence is a feeling. Evidence is understanding.

— Notes from the Gap

Write the paperwork.

Complete the process.

Answer the questions.

Submit the application.

But most problems appear much earlier than that.

Usually, before a regulator sees a single page.

The operation itself often isn’t mature enough yet.

The assumptions haven’t been tested properly.

The environment isn’t fully understood.

The procedures exist, but they haven’t really been exercised under pressure.

Sometimes the aircraft configuration is still changing while the operational concept is already being written around it.

That creates friction later.

Not because regulators are trying to stop things moving forward, but because the operation underneath the paperwork still has unanswered questions.

Good operational approvals usually come from operational maturity first.

Not from writing better documents.

The strongest applications are normally the ones where the operator already understands how the operation behaves in practice.

The documentation then becomes a reflection of that understanding, rather than an attempt to create it.

That’s an important difference.

Especially in more complex operations where assumptions can become embedded very early and survive far longer than they should.

The reality is that most operational permissions are not really assessing paperwork.

They are assessing whether the operation behind the paperwork appears credible, understandable, and controlled.

Those are not the same thing.

And people usually discover the gap between them later than they would like.

Operational maturity is probably one of the least discussed parts of the industry.

But it sits underneath almost everything.

— Notes from the gap

Plan it.

Get permission.

Turn up.

Fly.

That works up to a point.

But it doesn’t help when things start to drift away from what was expected.

A more useful way to think about operations is to break them into three parts:

1. What you think will happen

This is the plan.

The documentation.

The assumptions about how the aircraft, environment, and people will behave.

It’s necessary. But it’s never complete.

2. What actually happens

This is the operation in motion.

The environment changes.

Small decisions get made.

Things don’t quite line up with the plan.

This is where most of the work sits, even if it’s not written down anywhere.

3. How you respond to the gap

This is the part that’s usually missing.

The difference between what was expected and what is happening.

And how that difference is managed without losing control of the operation.

Most issues don’t come from a lack of planning.

They come from not recognising and managing that gap properly.

Operators who do this well don’t rely on perfect plans.

They expect things to move away from the plan, and they build the operation in a way that can handle it.

It’s a simple way of looking at things, but it changes how you approach everything from testing through to permissions.

Especially when the operation starts to scale.

I’ll build on this and break each part down properly over time.

If you’re working in this space, this is where most of the useful detail sits.

-Notes from the Gap

Photo courtesy of ARACE…many thanks

https://araceuas.com

It’s not dramatic. Nothing fails. Nothing obvious goes wrong.

But you realise the plan you walked in with isn’t going to hold up.

It might be something small.

The environment behaves differently than expected.

The aircraft doesn’t respond quite how it did before.

The comms aren’t as clean as they looked on paper.

Or the sequence of events just doesn’t flow the way it was designed.

On paper, the test plan made sense.

Clear steps. Logical progression. Defined outcomes.

But reality isn’t linear.

It doesn’t care about sequencing or structure.

It exposes the assumptions built into the plan, usually earlier than expected.

This is the point where testing either becomes useful, or starts drifting.

The easy option is to force things back towards the plan.

Adjust slightly. Ignore the small gaps. Keep moving forward as if everything still aligns.

That’s where a lot of value is lost.

The better option is to recognise what’s actually happening and adapt to it.

Not by throwing the plan away, but by understanding what the plan didn’t account for.

That’s where the real learning sits.

Good testing isn’t about proving that the plan was correct.

It’s about exposing where it wasn’t.

And being able to adjust without losing control of the operation.

That moment is easy to miss if you’re only focused on getting through the test.

But once you start looking for it, it shows up in almost every operation.

If this is useful, subscribe. I’ll keep writing about how these things actually play out in practice.

It doesn’t.

Most operations are already failing long before take-off. It just isn’t obvious yet.

Plans look solid. Documentation is in place. Risk assessments are complete. Everything appears to line up.

But the reality is usually different.

The plan often doesn’t match the environment.

The assumptions haven’t been tested.

And the operation itself hasn’t been thought through in a way that survives real-world pressure.

This shows up quickly once things start moving.

Small issues appear early. They get worked around. Then more follow.

By the time the aircraft is actually doing something useful, the operation is already being held together by decisions that were never part of the original plan.

That’s where most risk actually sits.

Not in the obvious failure points, but in the gap between what was designed and what is actually happening.

The operators that manage this well don’t rely on perfect plans.

They expect that gap to exist, and they design for it.

They think through how the operation behaves when things don’t go as expected, not just when everything goes right.

It’s a small shift, but it changes everything.

If you’re planning operations, it’s worth asking one question early:

What happens when this doesn’t go the way we expect?

That’s usually where the real work starts.

If this is useful, subscribe. I’ll be sharing more of these real-world lessons.