1. The burn that must not be wasted

Andy Weir’s The Martian returns as the recalled work because Mark Watney’s every course correction is planned within tight propellant and timing constraints. A pre-approved maneuver window is the orbital equivalent: the platform may burn, but only within bounds that ground has already accepted.

This entry wonders about command authorization policies and pre-approved maneuver windows.

2. What a pre-approved maneuver window contains

A pre-approved maneuver window is a policy object that defines when and how the platform may autonomously execute a maneuver. It might include:

  • Time bounds: the earliest and latest allowed execution time.
  • Orbital state bounds: acceptable current and predicted orbit parameters.
  • Delta-v bounds: maximum total impulse for the maneuver.
  • Attitude bounds: allowed pointing directions and slew limits.
  • Propellant reserve: minimum propellant that must remain after the burn.
  • Conjunction context: the object, miss distance, and probability that justify the maneuver.
  • Notification rules: when and how ground must be informed.
  • Override: how ground can cancel the window.

The window is signed by ground and loaded into the platform’s policy store. The platform may then plan and execute a maneuver that fits inside the window without requesting fresh authorization.

3. Authorization policies for different command classes

Not all commands deserve the same authorization. A reasonable classification for the desktop:

  • Class A — safety-critical: propulsion burns, safe-mode entry, power shedding, software update. Require multi-party or hardware-backed authorization.
  • Class B — operational: pointing changes, payload scheduling, communications configuration. Require single authenticated command with freshness check.
  • Class C — routine housekeeping: telemetry rate changes, minor parameter updates. Require authenticated command.
  • Class D — local autonomy: drag makeup within budget, thermal control, battery management. May be pre-authorized by policy and logged.

The desktop’s autonomous orbit maintenance falls mostly into Class D, with collision avoidance and deorbit in Class A.

4. Key lifecycle and compromise recovery

Keys do not last forever. The policy must define:

  • how long a pre-approved window remains valid;
  • how keys are rotated and how the platform handles rotation failure;
  • what happens when a ground-station key is revoked;
  • whether the platform can fall back to a previous key or enter a safe mode;
  • how emergency commands are authenticated when normal keys are unavailable.

A key compromise should not strand the platform. The design should allow revocation from any authorized ground station and recovery through a pre-defined key escrow or emergency procedure.

5. What limits this

  • Contact windows may not align with key rotation schedules.
  • Multiple ground stations with different keys create synchronization problems.
  • Customer payloads may need commands during a window when the platform has suspended command acceptance due to an anomaly.
  • Regulatory requirements may mandate notification before any maneuver, reducing the value of pre-approval.

6. What this changes

  • Pre-approved maneuver windows are the contract between ground oversight and autonomous action.
  • Command classification lets the desktop apply stronger authorization to safety-critical actions.
  • Key lifecycle management must be designed for intermittent connectivity and compromise recovery.
  • The next entry will ask what autonomous trust boundaries need from the desktop architecture.