1. The filter that did not fit

Jim Lovell and Jeffrey Kluger’s Lost Moon returns as the recalled work because the Apollo 13 crisis turned, at one point, on an interface problem: the command module’s square CO2 canisters would not fit the lunar module’s round receptacles. The two systems were individually qualified, but their interface had never been tested because the mission plan did not require it. When the plan changed, the crew had hours to invent, build, and test an adapter with materials found on board. The desktop cannot afford that improvisation with a customer payload. The integration test exists to discover square-peg-round-hole problems before launch, not after.

This entry asks why payload integration and operation verification matters.

2. Why reading and wondering are not enough

Entries 693 through 696 established that the desktop will host payloads through a standardized interface. Entries 697 through 700 established that the platform will manage those payloads autonomously within policy. Both arcs are necessary but not sufficient. A document is not a payload. A scheduler is not an operation. The test closes the gap between what the interface says and what the hardware does.

The test must answer three questions:

  • Does the payload physically and electrically integrate with the desktop without harm?
  • Does the platform correctly command, power, monitor, and safe the payload?
  • Does the autonomous scheduler operate the payload safely under realistic constraints?

3. What happens without the test

The history of spacecraft integration is full of small failures that became large because they were found late:

  • A connector pinout error that shorts the bus at power-on.
  • A thermal model that ignores heat coupling between payload and host, leading to an overtemp.
  • A command sequence that is valid in isolation but triggers a fault when the bus is in safe mode.
  • A payload that draws inrush current during a scheduled operation and resets the flight computer.
  • A customer expectation that “on demand” means real time, when the orbit and power budget mean hours of delay.

Each of these is cheaper to find in a test than in orbit.

4. What the test protects

The payload integration and operation test protects:

  • The desktop: from payload-induced faults that could disable the platform.
  • The customer: from discovering after launch that their instrument cannot operate as intended.
  • The operator: from being surprised by autonomous decisions that were never exercised on the ground.
  • The business: from the cost and reputation damage of an on-orbit failure.

5. What this changes

  • The payload/customer operations phase needs a closing test arc, not just reading and wondering.
  • The test must cover physical integration, electrical behavior, command and telemetry paths, and autonomous scheduling.
  • The next entry will define the test matrix: what configurations and conditions to exercise.