1. The ship that took on passengers

James S. A. Corey’s The Expanse returns as the recalled work because the Canterbury and later the Rocinante are freight and passenger vessels that must keep their original crew safe while accommodating cargo and people who bring their own needs, schedules, and emergencies. The ship’s captain retains authority over anything that threatens the hull, life support, or trajectory. A hosted payload platform is similar: the bus is the ship, the payload is the passenger or cargo, and the captain’s authority is the operations concept.

This entry reads about hosted payload operations, scheduling, “do no harm,” and service models.

2. The operations contract

The ESSP Hosted Payload Interface Guide frames operations as a division of responsibility. The host spacecraft provides:

  • orbit, attitude, and pointing as specified;
  • power within agreed limits;
  • thermal environment within agreed bounds;
  • command and telemetry pathways;
  • scheduled downlink and data latency;
  • safety oversight and emergency response.

The payload provider provides:

  • an instrument that fits the interface;
  • command sequences that stay within constraints;
  • operational requests scheduled in advance;
  • fault detection and safe-mode behavior;
  • data products and mission reporting.

The host is the final authority. If a payload command conflicts with spacecraft safety, orbital constraints, or another payload’s operations, the host wins. This is not hostility; it is the only way a multi-payload platform can survive.

3. Scheduling and shared resources

A hosted payload rarely operates continuously. Power, thermal, data rate, and pointing are shared, so operations are scheduled.

The SatNow article describes a typical cycle:

  • The payload team submits an operations request: when the payload wants power, what attitude it needs, how much data it will generate, and how long the activity lasts.
  • The host operations team checks the request against the spacecraft state, power budget, thermal prediction, communication windows, and other payload schedules.
  • The approved request becomes a command sequence loaded into the onboard schedule.
  • During execution, the host monitors the payload’s current, temperature, and telemetry. Anomalies trigger safe-mode or shutdown.
  • Data is stored onboard and downlinked according to priority and bandwidth.

The desktop complicates this because it is autonomous. Ground is not continuously in the loop, so the scheduler must run onboard with enough policy to resolve conflicts without asking Earth every minute. That policy is itself part of the interface.

4. “Do no harm”

The ESSP guide repeats the phrase “do no harm” until it becomes a design philosophy. It means several things:

  • A payload failure must not propagate to the host bus.
  • A payload must not draw more power than allocated, even transiently.
  • A payload must not emit RF or conducted noise that degrades host communications or navigation.
  • A payload must not command or physically interfere with host safety-critical functions.
  • A payload must survive its own failures without requiring heroic intervention from the host.

Implementation includes electrical isolation, current limiting, command validation, thermal shutdowns, and predefined safe states. The payload may be required to demonstrate fault containment during integration testing. A payload that cannot show it will fail quietly may not be hosted.

5. Service models

Hosted payload programs have evolved several service models, which the desktop can learn from:

  • Port only: the host provides a mechanical mounting location, power, and data; the payload team does almost everything else. This is closest to CubeSat hosting.
  • Managed payload: the host operations team runs the payload on behalf of the customer, using the payload team’s command dictionary and constraints. The customer receives data products.
  • Risk-shared payload: the host and payload team share integration, launch, and operations risk. Cost is lower but control is shared.
  • Dedicated ride: the host is essentially built around the payload, as in some ESPA Grande missions. The interface is still standardized but the mission is payload-driven.
  • Payload-as-a-service: emerging commercial models where the customer buys observation time, compute cycles, or experimental slots rather than designing a payload at all.

For the desktop, the natural starting point is a mix of “port only” and “managed payload.” A sophisticated customer brings a qualified instrument and operates it through a published interface. A less sophisticated customer buys a managed slot and receives data.

6. Operational authority and the desktop

The desktop’s autonomy raises a specific question: who is the operations authority when ground contact is intermittent? The answer is layered:

  • Ground defines policy, constraints, and priorities.
  • The onboard scheduler resolves routine conflicts.
  • Safety-critical decisions remain with the onboard fault management system, which can override both payload and scheduler.
  • Ground is notified as soon as possible after any autonomous action.

This is the same posture the desktop uses for propulsion, power, and attitude: autonomy within policy, with notification and override. Payload operations should not be an exception.

7. What this changes

  • Hosted payload operations are a shared-resource scheduling problem with safety as the hard constraint.
  • “Do no harm” is enforced by electrical, thermal, command, and operational containment.
  • Service models range from bare port rental to fully managed payload operations.
  • The desktop’s autonomy requires an onboard scheduler and policy engine, not just a ground operations team.
  • The next entry will close the payload reading arc with a contemplation.