1. The order that had to be translated into a burn

James S. A. Corey’s The Expanse returns as the recalled work because ships in that universe constantly receive requests from passengers, cargo owners, and fleet command that must be translated into burns, attitude changes, and resource allocations. The crew’s job is to say “yes,” “yes if,” or “no, because the reactor is already committed.” A desktop that hosts customer payloads does the same translation, except the crew is a scheduler and the answers must be explainable.

This entry wonders about customer tasking.

2. What a tasking request looks like

A customer task is a request for the platform to do something on their behalf. Examples for the desktop:

  • “Take an image of this ground location at this local time tomorrow.”
  • “Run this compute job for two hours during the next eclipse.”
  • “Power my sensor during the communications pass over this ground station.”
  • “Print this part when thermal conditions allow.”
  • “Store this data and forward it when the next high-rate link is available.”

Each request has parameters: time window, priority, pointing target, power and thermal needs, data product, and deadline. The platform must decide whether it can be satisfied and at what cost to other tasks.

3. How the platform should answer

The answer to a tasking request should not be binary. A useful platform returns one of:

  • Accepted: the task is scheduled and will execute as requested.
  • Accepted with modification: the task will execute at a different time, with different pointing, or with reduced resolution because of constraints.
  • Deferred: the task is valid but cannot be scheduled in the requested window; the platform proposes alternatives.
  • Rejected: the task violates safety, policy, or physical constraints.
  • Requires approval: the task is possible but exceeds the customer’s pre-authorized authority or budget.

The customer should receive not just the answer but the reason: power budget exhausted, thermal limit, pointing conflict, downlink queue full, or policy constraint.

4. Authority and precedence

Not all customers are equal, and not all tasks are equal. The platform needs a precedence model:

  • Platform safety overrides everything.
  • Regulatory or emergency tasks take precedence over routine commercial tasks.
  • Pre-booked slots are honored unless displaced by safety or higher-priority tasks.
  • Best-effort tasks fill the gaps and are the first to be deferred.
  • Customer tier may affect priority, but only within policy, not at the expense of safety.

The desktop’s autonomy posture applies here too: the platform can resolve routine conflicts using policy, but unusual or high-stakes decisions may require ground confirmation.

5. What could go wrong

  • A customer submits a task that looks harmless but creates a thermal or power emergency when combined with other tasks.
  • A deferred task is forgotten because the scheduler has no mechanism to retry or notify.
  • A priority dispute between customers cannot be resolved without human intervention.
  • A task is accepted but the data product is lost because storage was full or downlink failed.
  • Customers design their payloads assuming immediate tasking, not understanding orbital and resource constraints.

6. What this changes

  • Customer tasking is a negotiation, not a command.
  • The platform needs a clear, published precedence and rejection policy.
  • Customers need visibility into constraints, not just outcomes.
  • The next entry will wonder what autonomous payload management and customer tasking need from the desktop specifically.