1. The computer that needed sensors, models, and authority

Robert A. Heinlein’s The Moon Is a Harsh Mistress returns one last time for this arc because Mike’s autonomy depends on three things: he can sense the state of Luna’s systems, he has models of how they behave, and he has authority to act within defined bounds. Without any one of those, his autonomy collapses into either paralysis or dangerous overreach. The desktop’s autonomous payload manager needs the same triplet.

This entry wonders what autonomous payload management needs from the desktop.

2. Sensing and state estimation

The platform cannot manage what it cannot measure. It needs:

  • Payload state: on, off, standby, fault, temperature, current, data buffer level.
  • Bus state: battery state of charge, solar array output, power distribution loads, thermal radiator temperature, attitude, orbit.
  • Environment state: eclipse status, sun angle, ground station visibility, communication link margin, conjunction warnings.
  • Task state: pending, scheduled, executing, completed, deferred, rejected, aborted.

These measurements do not need to be perfect, but they must be current enough for decisions. A payload scheduler working with stale battery data is a hazard.

3. Models and prediction

Sensing the present is not enough; the platform must predict the consequences of a schedule:

  • Power model: will this sequence of payload operations discharge the battery below the safety reserve?
  • Thermal model: will the payload and bus temperatures stay within limits during and after the operation?
  • Attitude model: can the requested pointing be achieved while maintaining solar power and communications?
  • Data model: will the generated data fit in storage and be downlinked before the next high-rate collection?
  • Propulsion model: if a payload operation requires a pointing change or orbit adjust, is propellant available?

The models can be simple at first — lookup tables and worst-case margins — but they must exist.

4. Policy and authority

The platform must know what it is allowed to do without asking:

  • Which payloads can be powered on or off automatically?
  • Under what conditions can a customer task be accepted, modified, deferred, or rejected?
  • Which conflicts can the platform resolve on its own, and which require ground decision?
  • What is the minimum battery, propellant, and thermal margin that must be preserved?
  • What notification and logging is required for each autonomous action?

Policy is the boundary between autonomy and insubordination. It must be defined by the operator, loaded from ground, and enforced onboard.

5. Execution and feedback

Finally, the platform needs the ability to act and to report:

  • Switch payload power, send commands, and change data routes.
  • Abort or modify an operation if a safety limit is approached.
  • Log every decision, command, and anomaly.
  • Notify ground and customers of schedule changes and execution results.
  • Accept updated policy, schedules, and emergency overrides from ground.

6. What this changes

  • Autonomous payload management is not a single algorithm but a system capability built on sensing, modeling, policy, and execution.
  • The desktop already has many of the needed pieces from earlier arcs: power management, thermal management, attitude control, communications, and fault protection.
  • The new work is mostly integration and policy: building a scheduler that uses those pieces safely.
  • The next entry will close the autonomous payload management wondering arc.