1. The desert and the plan

Frank Herbert’s Dune is about a planet that teaches its inhabitants that plans fail. The desert is too powerful, too unpredictable, too thirsty for certainty. The people who survive are not the ones with the best plan. They are the ones who can adapt when the plan breaks. The desktop lives in a desert of its own: launch slips, component failures, regulatory surprises, market shifts, and orbital mechanics that do not care about intentions.

Entry 304 closed the team and organization arc. This entry opens the uncertainty and resilience arc.

2. The kinds of uncertainty

Not all uncertainty is the same. Some can be quantified, like the probability of a component failure. Some cannot, like the future price of launch or the emergence of a competitor. The desktop faces:

  • Technical uncertainty: will the design work in orbit?
  • Schedule uncertainty: when will the first unit fly?
  • Cost uncertainty: how much will development really cost?
  • Market uncertainty: who will pay and for what?
  • Regulatory uncertainty: what rules will apply in five years?
  • Environmental uncertainty: solar weather, debris, collision risk.

Each kind requires a different response.

3. Uncertainty is not the enemy

A programme that tries to eliminate all uncertainty will never move. The goal is not certainty. The goal is to be robust enough to survive the surprises and flexible enough to benefit from them when possible. This is the difference between fragile, robust, and antifragile systems.

The desktop should aim to be at least robust and, where possible, antifragile: designed so that some stresses make it better.

4. Where uncertainty lives

Uncertainty concentrates at interfaces and assumptions:

  • New technologies with no flight heritage.
  • Suppliers with no space track record.
  • Customers who have not yet committed.
  • Regulators who have not yet ruled.
  • Orbits that have not been occupied before.

These are the places to watch and the places to design for optionality.

5. The humility of the plan

Every plan is a guess dressed as a schedule. The useful plan is one that knows it is a guess and includes feedback loops: reviews, tests, customer conversations, and decision gates. The desktop’s plan should be treated as a hypothesis to be tested, not a prophecy to be fulfilled.

What this changes

  • Uncertainty is recognized as a permanent condition, not a temporary problem.
  • Technical, schedule, cost, market, regulatory, and environmental uncertainties are tracked separately.
  • The goal is robustness and, where possible, antifragility.
  • Interfaces and assumptions are where uncertainty concentrates.
  • The plan is a hypothesis with feedback loops, not a prophecy.
  • The next entry will cover optionality and modularity as risk controls.