The Sun Has Declined the Meeting

The Sun has never attended a stakeholder meeting.

This is inconvenient, because we are putting rather a lot of stakeholders in orbit.

On 3 February 2022, SpaceX launched forty-nine Starlink satellites into low staging orbits. Thirty-eight reentered the atmosphere within days after encountering unexpectedly high atmospheric drag. The geomagnetic storms involved were classified as minor.[1]

“Minor” becomes a less comforting adjective when you own the equipment.

The upper atmosphere had expanded, increasing the density of the gas the satellites were flying through. Operators attempted to reduce drag, but most of that launch’s spacecraft could not recover sufficiently to raise their orbits. The researchers’ prescription was practical: better atmospheric models, better measurements, and better information reaching the people making operational decisions.[1]

The Sun remained unavailable for the incident review.

That episode was a lesson in understanding the environment. As more decisions become automated, it also gives us a reason to examine what happens when the environment changes after a plan has been approved.

Who can change the plan? Which permissions still apply? What should happen when the person who approved it is temporarily unreachable?

In a study reported on 7 October, the European Union Space Surveillance and Tracking system and the US Traffic Coordination System for Space compared their collision warnings. Their outputs differed substantially because they used different inputs and rules for publishing notices. When they used similar operational data supplied by spacecraft operators, the outputs converged. The researchers called for more information sharing, including planned maneuvers.[2]

Two respectable dashboards can disagree for respectable reasons. Unfortunately, the spacecraft do not pause while we reconcile the reports.

Reliable information is essential. So is knowing how a decision made from that information becomes an action. An operator may authorize a plan, another system may translate it into commands, and a later check may discover that the conditions supporting the approval have changed.

The handoff deserves attention. Each participant can complete its assigned task while the permission that started the process quietly becomes outdated.

At this point, a software founder is at risk of announcing that space needs permissions, followed by a diagram with his company in the middle.

Reading the documentation can be an unpleasant interruption.

Yamcs, an existing mission control system, already checks command privileges, supports queues in which operators review commands, and evaluates telemetry conditions before transmission. Quindar offers automated mission operations with access controls across mission stakeholders. Space engineers have spent considerable effort on these problems.[3][4]

Any new product has to earn its place alongside that work.

The question I find interesting is whether an operator’s precise grant of authority can travel reliably through a chain of tools and organizations. Can each system understand what was permitted, recognize when that permission no longer applies, and enforce the limits at the point of action?

A useful answer would have to improve a real operational handoff. Giving an existing approval button a more ambitious name would be a modest contribution to spaceflight.

I’m calling this sketch the Orbital Authority Protocol, or OAP.

The idea is a shared way to express a bounded grant of authority and check it as a request moves between systems. A signed, machine-readable grant would identify who delegated permission, what it covers, and the conditions under which it remains valid. It would also specify how permission expires or is withdrawn. Records of the checks and the eventual outcome would let the participants reconstruct what happened.

Consider a hypothetical imaging task. A satellite operator permits schedules from an external planning agent to be released automatically for one spacecraft during a particular pass. The grant includes an operator-defined power budget and a time window. It covers imaging tasks; maneuver commands require separate authority.

The agent proposes a schedule. Before the schedule is released, newer telemetry shows that the required power reserve is no longer available. The execution system checks the current conditions and holds the request under the operator’s rules.

The agent supplies an eloquent explanation of why the photograph would nevertheless be valuable. This can be preserved for the literature department. It does not change the power budget.

That is the behavior we would want to test: permission with a clear scope, checked where it matters, with an understandable account of the result.

There are difficult details. A command may be approved well before it executes. A spacecraft may be out of contact when a permission is withdrawn. Doing nothing can itself be dangerous. Mission engineers would need to define what the system can do locally, how long delegated authority remains valid, and what fallback behavior applies when fresh information is unavailable.

An authorization check cannot establish that a maneuver is physically safe. A valid signature can authenticate the grant; its contents still need sound engineering and reliable inputs. Existing mission safeguards remain essential.

The first test could fit within one operator’s workflow. It should be possible to demonstrate value before asking everyone in orbit to adopt the same protocol. Otherwise, the first deliverable is a committee, and the spacecraft already have somewhere to be.

A recent development in AI offers a useful parallel. Anthropic’s policy update, announced on 8 October and taking effect on 12 November, adds requirements when Claude controls potentially injurious hardware autonomously. A qualified operator must be able to observe and stop the equipment, and the equipment must be able to hold a safe state if Claude disconnects.[5]

That requirement has to become actual behavior somewhere in the system. Someone must implement the stop mechanism and determine what a safe state means for that equipment.

The same practical question sits beneath OAP: where does the rule become an enforced limit? A policy document can describe the boundary. The machinery needs a way to respect it.

At Humbleaf, we are building software for defining and checking authority before agents and automated workflows take consequential actions. Our work includes policy decisions, approvals, and signed records of those decisions. That gives me a professional interest in asking awkward questions about who authorized things.

The reader may wish to enter this interest into the minutes.

OAP is a research proposal. Humbleaf has no orbital deployment. We are exploring whether the authority problems we work on in software also appear at particular handoffs in space operations, and whether a shared approach could help.

To learn that, we need examples from people who operate spacecraft: a permission that becomes difficult to track, an automation that requires too much manual supervision, or a handoff where existing systems do not quite agree. We also need to hear where the proposed solution is already routine.

I would like to begin with one real workflow and the people responsible for it. They should be able to challenge the assumptions before we build anything around them.

There is plenty of room for ambition after that. The immediate question is small enough to answer: when the next command is ready, does the authority behind it still hold?

The Sun will continue without waiting for the minutes.