1. The scheduler that answered yes, no, and later

Robert A. Heinlein’s The Moon Is a Harsh Mistress returns one last time for this arc because Mike’s most useful quality is not his speed but his judgment: he knows which decisions he can make and which ones need a human. The desktop’s autonomous payload manager should be built the same way. It does not replace the operator; it handles the routine and escalates the exceptional.

This entry closes the autonomous payload management and customer tasking wondering arc.

2. What was learned

Entries 697 through 699 wondered about autonomous payload management, customer tasking, and what the capability needs from the desktop. The wondering gives the desktop four constraints:

  • Autonomy compresses the request-to-execution loop. Customers should not need a ground pass for every payload operation.
  • Tasking is a negotiation. The platform answers with accepted, modified, deferred, rejected, or approval-required, and explains why.
  • Policy bounds the autonomy. Safety, platform health, regulatory requirements, and customer precedence define what the platform can decide on its own.
  • Capability rests on sensing, models, and authority. Without state estimation, prediction, and delegated authority, scheduling is either blind or timid.

3. What was decided

The desktop will adopt autonomous payload management as a policy-bounded scheduling service with customer negotiation and ground override. This means:

  • Customers submit tasking requests with windows, priorities, constraints, and expected resource use.
  • The onboard scheduler evaluates each request against power, thermal, attitude, data, and policy constraints.
  • The platform returns an answer with a reason: accepted, modified, deferred, rejected, or approval-required.
  • The scheduler resolves routine conflicts using published precedence rules.
  • Safety-critical or policy-uncertain decisions are escalated to ground.
  • All scheduling decisions, executions, and anomalies are logged and reported.
  • Ground can update policy, override schedules, and safing any payload.

4. Interaction with earlier arcs

The autonomous payload management arc connects directly to:

  • the payload reading arc: interface standards define what payloads the platform can host and what constraints they impose;
  • the power arc: power budgeting and dynamic power trading enable payload scheduling;
  • the thermal arc: thermal models determine when payloads can operate;
  • the GNC arc: attitude and pointing constraints shape task feasibility;
  • the cybersecurity arc: payload command paths must be authenticated and bounded;
  • the autonomous trust boundaries arc: payload operations are governed by the same authority model as maneuvers and power decisions.

5. What remains open

The exact tasking language, scheduling algorithm, customer API, and precedence rules depend on the first payloads and service model. The wondering arc has set the strategy; detailed design comes when the first customer payload is defined.

6. What this changes

  • The autonomous payload management and customer tasking wondering arc is closed.
  • The desktop inherits a policy-bounded payload scheduling capability.
  • The next arc will design a test for payload integration and operation verification.