Programmable Settlement for Commercial Space Assets
Audience:
Space asset operators, mission architects, chief engineers, and technical leadership
Purpose:
To examine the operational and economic risks of closed orbital compute and coordination systems as compute, autonomy, and inter-satellite connectivity become core to constellation operations.
Executive Summary
Orbital compute and software-defined payloads are becoming programmable. Settlement remains contractual and post-facto.
Today, services can be taskable by API, but monetized by invoice. Execution is deterministic at the software layer, yet economic reconciliation depends on interpretation, reporting, and dispute. As autonomy and machine-mediated tasking increase, this mismatch introduces friction: delayed revenue, ambiguity under contention, and underwriting decisions based on representations rather than verifiable execution history.
This memorandum examines how binding financial settlement directly to cryptographically constrained execution, referred to here as payment-to-execution, aligns economic incentives with operational reality.
1. The Structural Gap in Commercial Space Settlement
Commercial space services are increasingly defined by programmable capabilities: compute cycles, relay windows, imaging tasking, inference jobs, and priority scheduling rights. These capabilities are orchestrated through software-defined systems that can enforce policy deterministically at execution time.
Settlement, however, has not evolved at the same pace.
Today’s model typically involves:
Contract negotiation defining high-level service obligations
Operational tasking via API or control interface
Post-facto metering and reporting
Manual billing cycles and reconciliation
SLA interpretation in the event of contention or degraded performance
This separation between execution and settlement introduces ambiguity precisely where clarity is most valuable.
During nominal operations, this model is tolerable. During contention; when compute, bandwidth, or thermal margin are scarce, ambiguity increases. Operators must interpret whether a task was delayed due to prioritization, congestion, platform arbitration, or external dependency. Customers must trust operator-provided records. Insurers must rely on attestations rather than deterministic proof.
In degraded conditions, this ambiguity compounds. When links are intermittent, clocks drift, or control paths are impaired, post-facto reconstruction of execution order becomes increasingly difficult. Yet it is precisely in these conditions that economic and contractual consequences matter most.
The result is a structural inefficiency:
Execution is deterministic at the software layer.
Settlement remains interpretive at the contractual layer.
As programmable payloads proliferate and machine-mediated tasking increases, this mismatch becomes more visible. The bottleneck is no longer compute capability. It is economic coordination.
The number of active satellites in orbit has increased sharply over the past decade, with proliferated LEO constellations driving sustained growth in on-orbit assets [10]. As satellite density and service diversity increase, coordination frequency and arbitration complexity scale accordingly.
2. The Limits of Payment-to-Access
The industry is not unaware of programmable settlement. APIs can already be monetized. Usage-based billing models are mature in cloud infrastructure, telecommunications, and data services. Machine-readable payment rails and programmatic authorization mechanisms exist.
HTTP includes a status code reserved for payment gating. The 402 “Payment Required” status code exists as a defined semantic in the HTTP standard, even if it has historically lacked a universal convention [2]. More recently, protocols such as L402 have demonstrated practical request-time payment gating by combining HTTP 402 flows with Lightning payments and bearer credentials designed for distributed authorization [3][4].
However, payment-to-access does not guarantee execution.
When payment is tied only to endpoint access, the internal execution environment remains opaque. The customer gains the right to submit a request, but not deterministic visibility into how that request is arbitrated under contention, scheduled relative to competing workloads, or degraded during constrained conditions.
This distinction is subtle but economically significant.
2.1 Opaque Arbitration in Cloud Infrastructure
In cloud environments, APIs are frequently billed per call, per compute-second, or per request. Customers pay deterministically for access to an interface. Yet the underlying scheduling, throttling, and priority enforcement logic is proprietary.
During congestion events, workloads may be rate-limited, deprioritized, or queued. Customers can observe performance degradation but cannot inspect the arbitration logic that produced it. They accept execution outcomes as a function of platform-defined rules.
Payment granted access. It did not guarantee bounded execution behavior.
2.2 Ambiguity in Satellite Service Delivery
A similar pattern exists in commercial space services.
An imaging customer may pay for a tasking window. A relay customer may pay for bandwidth allocation. A hosted payload user may pay for compute time or priority scheduling. The transaction grants access to the service request mechanism.
But under contention (when crosslinks saturate, thermal margins tighten, or competing tasks emerge) internal arbitration determines which tasks execute first, which are deferred, and which are partially fulfilled.
Commercial ground segment services already differentiate access modes under contention. AWS Ground Station explicitly offers both On-Demand and Reserved scheduling, describing Reserved as providing improved scheduling compared to On-Demand [6]. The Ground Station FAQs further describe that On-Demand contacts can be scheduled within a defined window, while Reserved scheduling depends on the customer’s reservation commitments [7].
This illustrates a broader pattern. Settlement and priority can be offered programmatically, but without bounded and auditable execution policy, arbitration remains platform-defined.
If that arbitration logic is not cryptographically bounded and auditable, settlement remains interpretive. The operator reports what occurred. The customer evaluates performance relative to contractual expectations. Insurers evaluate the operator’s record. In each case, the execution path is reconstructed after the fact.
Payment-to-access accelerates billing. It does not eliminate ambiguity.
2.3 The Structural Gap
As programmable payloads and machine-mediated tasking increase, the number of short-duration, high-frequency capability invocations will grow. Micro-capabilities (seconds of compute, brief relay bursts, narrow priority windows) cannot efficiently be reconciled through interpretive settlement.
When payment unlocks access, but execution remains governed by opaque arbitration, the economic model inherits the same structural risks as traditional contracts:
Dispute under congestion
Ambiguity under degraded operations
Reliance on operator trust rather than deterministic proof
The gap is not in payment rails. It is in binding settlement to the bounded execution of a defined capability.
3. Payment-to-Execution: Architectural Overview
The limitation of payment-to-access models is not in the payment rail. It is in the absence of deterministic linkage between economic settlement and bounded execution behavior.
Payment-to-execution addresses this gap by binding financial settlement directly to a cryptographically constrained capability invocation.
The core principle is straightforward:
Settlement is triggered by execution of a defined capability under defined policy constraints, not merely by access to an interface.
This requires five architectural components.
3.1 Capability Defined by the Operator
The operator defines discrete, programmable capabilities that may be exposed externally. These may include:
A bounded compute invocation
A relay window with defined bandwidth and duration
A sensor tasking event
A priority scheduling window
A software-defined payload function
Each capability is explicitly specified in terms of:
Resource scope such as time, compute, bandwidth, or power
Operational constraints
Identity requirements
Failure behavior
The operator remains authoritative over capability definitions. No external platform dictates task structure.
3.2 Execution Bounded by Policy
When a capability is invoked, execution is constrained by a cryptographically enforceable policy envelope.
The policy specifies:
What may execute
Under what limits
For how long
Under what priority conditions
Under what degraded-mode behavior
This policy is not interpretive contract language. It is machine-readable and enforceable within the execution environment.
Under contention, arbitration occurs within defined boundaries rather than opaque internal logic. The execution path is bound before invocation.
3.3 Payment Tied to the Bounded Execution
Rather than unlocking general access, payment is bound to the invocation of a specific capability instance.
The settlement instrument references:
The capability identifier
The policy envelope
The invoking identity
The resource limits
Payment therefore authorizes a defined execution event, not an open-ended interface session.
This shifts the economic trigger from API access granted to capability executed within defined constraints.
3.4 Verifiable Receipt Returned
Upon execution, the system generates a verifiable receipt that attests:
That the defined capability was invoked
That execution remained within policy bounds
That resource limits were respected
That execution completed, failed, or was partially fulfilled under defined conditions
This receipt is cryptographically bound to the capability definition and invocation context.
Importantly, this receipt is not a platform-controlled internal log. It is structured so that it can be independently verified by counterparties or auditors without requiring trust in opaque arbitration logic.
3.5 Settlement Triggered by Execution Event
Economic settlement is triggered by the execution event itself.
If execution completes within defined policy bounds, settlement finalizes.
If execution fails according to predefined criteria, settlement may not finalize or may follow alternate logic defined in the policy envelope.
This mirrors established patterns in distributed systems where state transitions are triggered by deterministic events rather than discretionary reconciliation.
Execution and settlement flow
The economic model mirrors operational reality:
No execution, no settlement
Bounded execution, bounded settlement
Partial execution, deterministic outcome
This alignment removes interpretive gaps between what was run and what was billed.
3.6 Structural Distinction
This model is not an argument for speculative markets or novel financial instruments.
It is an architectural refinement.
Settlement is coupled to deterministic capability execution.
As payloads become software-defined and autonomy increases, the ability to express economic relationships in the same deterministic terms as operational constraints becomes increasingly important.
Payment rails may vary. Identity models may vary. Implementation details may evolve. The invariant principle is that settlement must be cryptographically and operationally coupled to bounded execution, not merely to interface access.
4. Why Hosted Payload Aggregators Benefit First
Hosted payload aggregators sit at a structural junction. They coordinate spacecraft resources, integrate third-party payloads, mediate customer access, and assume operational risk across multiple counterparties.
As capabilities become software-defined and increasingly programmable, aggregators face both opportunity and exposure. Payment-to-execution models align most directly with their economic and operational position.
4.1 Reduced Dispute Surface
In traditional service models, dispute arises at the boundary between what was promised and what was delivered.
Under congestion, degraded communications, or competing task priorities, questions emerge:
Was the task accepted?
Was it executed within the contracted window?
Was priority honored?
Were resource limits respected?
Absent deterministic records tied directly to the invocation policy, resolution depends on log interpretation and contractual interpretation.
Payment-to-execution reduces this ambiguity.
Each invocation produces:
An explicit execution record
Resource accounting tied directly to the policy envelope
A verifiable audit trail linking settlement to a bounded execution event
The aggregator is no longer reconciling invoices against narrative explanations. Settlement is cryptographically coupled to defined execution behavior.
This reduces dispute frequency and narrows the interpretive surface when disputes do occur.
4.2 Micro-Capability Monetization
Traditional contract structures are poorly suited to high-frequency, short-duration services.
Examples include:
Short compute bursts measured in seconds
Relay bursts across constrained windows
Temporary priority elevation during congestion
Single inference jobs executed in orbit
These services are operationally feasible but contractually inefficient. Drafting, negotiating, and reconciling bespoke agreements for small, frequent capability invocations does not scale.
Payment-to-execution enables bounded, policy-defined micro-capabilities to be monetized directly.
Instead of negotiating a broad service agreement, the aggregator exposes defined capability primitives. Each invocation is economically settled at execution time.
This expands revenue surface area without increasing contractual complexity. It allows aggregators to experiment with new service tiers and dynamic pricing models without restructuring entire agreements.
Importantly, this does not eliminate commercial negotiation. It reduces the marginal friction of invoking discrete capabilities once a relationship exists.
4.3 Improved Underwriting Posture
Insurers and financial counterparties evaluate operators based on risk visibility and historical performance.
Today, underwriting often depends on:
Operator-provided service reports
SLA documentation
Historical uptime and anomaly records
Contractual controls
The space insurance market has experienced periods of heightened caution following concentrated losses, with underwriters tightening technical review and adjusting pricing in response to claim experience [8].
Separately, insurers have noted that the surge in satellite count has not translated into proportional premium volume, in part because many smaller satellites are not insured, which complicates risk pooling and historical comparability across mission classes [9]. In this environment, mechanisms that produce structured, verifiable execution histories can improve underwriting clarity and reduce reliance on post-incident interpretation.
This produces:
Verifiable service histories
Explicit records of resource consumption under policy constraints
Clear differentiation between nominal execution and degraded-mode behavior
From an underwriting perspective, this reduces moral hazard. Economic settlement is not triggered by assertion. It is triggered by bounded execution.
Over time, aggregators operating under payment-to-execution models can demonstrate a machine-verifiable record of service behavior. This improves actuarial modeling and strengthens the operator’s credibility in risk discussions.
For aggregators serving regulated or government customers, the ability to present auditable, cryptographically verifiable execution records may become a differentiator in procurement evaluations.
5. Degraded Mode Behavior and Settlement Integrity
Space systems are defined not only by how they operate nominally, but by how they behave under stress.
Links drop. Clocks drift. Crosslinks saturate. Thermal margins tighten. Control paths degrade. In these conditions, arbitration logic determines which tasks execute, which are deferred, and which are dropped.
In closed coordination systems, this arbitration is opaque. Execution behavior may change dynamically in response to congestion or recovery policies that are not inspectable by the operator. Under degraded conditions, economic consequences follow from decisions the operator cannot independently audit.
Settlement integrity becomes fragile precisely when operational integrity is most critical.
Payment-to-execution architectures approach this differently.
5.1 Bounded and Inspectable Policy
When execution is constrained by a cryptographically defined policy envelope, degraded-mode behavior is not left to opaque internal arbitration. It is governed by predefined rules attached to the capability itself.
The policy can specify:
What constitutes successful execution
What constitutes partial execution
Under what conditions execution is deferred
Under what conditions settlement is withheld
This does not eliminate degraded behavior. It makes it bounded and inspectable.
Economic outcomes follow predefined logic rather than interpretive reconstruction after the fact.
5.2 Settlement Remains Local to the Operator
In payment-to-execution models, settlement logic does not require continuous availability of an external control plane.
Capability definitions, policy envelopes, and execution receipts can be validated locally by the operator’s infrastructure. Settlement is triggered by the execution event as recorded within that bounded environment.
This reduces reliance on external coordination layers during recovery events.
Under degraded communications, the satellite or ground node may be isolated. Execution policy remains enforceable. Settlement logic remains coherent. Economic reconciliation does not depend on the availability of a centralized arbitration service.
5.3 No Mandatory Intermediary
Closed coordination systems often centralize both task arbitration and economic settlement. Over time, this creates a dependency on a platform-defined control plane.
Payment-to-execution models do not require a mandatory intermediary in the execution path. Capability definition, invocation, and receipt verification can occur directly between counterparties within defined trust boundaries.
Interoperability may exist. Marketplaces may emerge. However, settlement integrity does not depend on continuous mediation by a third party.
This preserves operator sovereignty during degraded operations.
5.4 Control-Plane Independence for Settlement Logic
Control-plane dependency introduces risk during outages. In cloud environments, customers have experienced scenarios where control-plane impairment limited expected remediation actions even when workloads were healthy. In orbit, the consequences of similar dependency are amplified by physical inaccessibility and long mission lifetimes.
Major cloud providers have documented incidents in which control-plane impairment limited expected remediation actions, even when workloads remained otherwise healthy [11].
Payment-to-execution architectures decouple settlement logic from centralized control-plane availability. Execution policy and receipt verification remain valid even if coordination services are temporarily impaired.
The result is not speculative resilience. It is bounded economic behavior under stress.
When degraded conditions occur, operators require predictable settlement outcomes tied directly to defined execution rules. Payment-to-execution aligns economic logic with operational constraints rather than with platform-defined recovery behavior.
6. Jurisdiction and Regulatory Alignment
Orbital coordination and settlement mechanisms are not purely technical decisions. They carry jurisdictional, contractual, and regulatory implications.
Commercial operators serving government, defense, or regulated customers must demonstrate:
Deterministic control over execution behavior
Clear identity and authorization boundaries
Auditability of tasking and settlement logic
Jurisdictional clarity regarding control paths and data handling
Payment-to-execution architectures can strengthen this posture when designed appropriately.
6.1 Operator-Controlled Keys
In a payment-to-execution model, identity and authorization primitives remain under operator control.
Capability definitions, policy envelopes, and receipt validation are anchored to keys controlled by the operator or mutually agreed counterparties. No external platform holds unilateral authority over task acceptance or settlement logic.
This preserves jurisdictional clarity. Legal responsibility and operational authority remain aligned.
6.2 No Custody of Customer Assets
Settlement rails may be programmable, but custody is not required.
The architecture does not require an intermediary to hold customer funds, escrow balances, or operator-controlled assets. Payment instruments can be structured such that settlement finalization is triggered by execution without centralized custody.
From a regulatory perspective, this reduces exposure associated with financial intermediation. The system coordinates settlement. It does not become a custodial institution.
6.3 No Forced Identity Regime
Participation in payment-to-execution models does not require adoption of a proprietary identity provider or centralized identity registry.
Operators may integrate existing compliance frameworks, export controls, customer vetting processes, and jurisdictional screening mechanisms into their capability definitions.
Identity remains modular and policy-driven rather than platform-imposed.
This supports compliance rather than bypassing it.
6.4 Settlement Rail Modularity
The underlying settlement rail is an implementation detail.
Different operators may adopt different settlement mechanisms depending on jurisdiction, regulatory environment, or customer requirements. The architectural principle is that settlement is bound to execution, not that a specific financial rail is mandated.
This modularity allows operators to remain compliant with evolving regulatory guidance without restructuring execution policy logic.
6.5 Local Policy Enforcement
Policy enforcement occurs within the operator’s execution environment.
Capability limits, degraded-mode rules, and settlement triggers are enforced locally according to predefined constraints. This reduces dependency on foreign-controlled coordination layers and simplifies jurisdictional mapping.
For regulators and government buyers, this improves auditability.
Execution behavior can be reconstructed from cryptographically verifiable receipts tied directly to policy definitions. Settlement outcomes follow defined logic rather than discretionary platform arbitration.
The objective is not to avoid oversight. It is to express operational and economic relationships in machine-verifiable form.
When policy, execution, and settlement are explicitly coupled, compliance review becomes clearer. The system exposes what was authorized, what was executed, and what was settled, without reliance on opaque third-party logs.
In a domain where jurisdiction and control are often intertwined with national security concerns, clarity is preferable to centralization.
7. Incremental Adoption Path
Payment-to-execution does not require immediate in-orbit firmware replacement, constellation redesign, or wholesale migration of coordination systems.
It can be introduced incrementally.
7.1 Phase 1: Ground-Side Enforcement
Initial deployment can occur entirely within ground infrastructure.
Operators define bounded capabilities and policy envelopes within their existing control and orchestration environments. Settlement triggers are tied to execution events as observed and validated on the ground.
No spacecraft modifications are required at this stage.
This allows operators to:
Validate economic logic
Test dispute reduction mechanisms
Evaluate audit workflows
Introduce micro-capability monetization
Risk is limited to software integration within known ground systems.
7.2 Phase 2: Hosted Payload Integrations
Once capability definitions and settlement logic are stable, bounded execution policies can extend closer to the payload environment.
Hosted payload providers can expose defined capability primitives with associated policy envelopes. Execution receipts are generated at or near the payload execution layer and validated within operator-defined trust boundaries.
This phase increases determinism and reduces interpretive surface area during contention.
Importantly, this does not require universal adoption. Individual payload services can migrate selectively.
7.3 Phase 3: Cross-Operator Interoperability
Only after bilateral deployments mature does cross-operator interoperability become relevant.
At this stage, multiple operators may expose compatible capability definitions and settlement primitives. Inter-satellite services, relay arrangements, and distributed compute tasks can be economically coordinated without surrendering control to a centralized intermediary.
Participation remains voluntary. Operators retain sovereignty over capability exposure and policy enforcement.
7.4 No Radical Migration Required
At no stage is a wholesale architectural reversal required.
Operators can:
Maintain existing contracts
Preserve traditional SLA structures
Introduce programmable settlement only where beneficial
Revert or isolate deployments if needed
Payment-to-execution is additive.
It aligns economic logic with programmable execution gradually, beginning at the control layer and extending outward only as confidence grows.
In a domain where mission lifetimes span years and requalification risk is non-trivial, incrementalism is not optional. It is structural.
A Final Note
This memorandum is not an argument for speculative markets or financial experimentation.
It is an argument for aligning financial settlement with operational reality as space systems become increasingly programmable and autonomous.
As capabilities move into software and autonomy expands, economic coordination cannot remain interpretive and post-facto without introducing friction, dispute, and structural inefficiency.
The question is not whether programmable settlement rails exist. They do. The question is whether settlement will remain loosely coupled to execution, or whether it will be expressed in the same deterministic terms as the capabilities themselves.
The protocol layer is where incentives are either preserved or gradually externalized.
Operators who retain authority over capability definition, policy enforcement, and settlement coupling maintain leverage as coordination scales. Operators who defer these decisions inherit economic structures optimized elsewhere.
The window for incremental adoption remains open. Architectural decisions made during this period will persist for mission lifetimes measured in years.
Payment-to-execution is not a departure from commercial space operations. It is a refinement of them.
Appendix A: Conditional Settlement Primitives: HTLCs and PTLCs
Programmable settlement is already deployed in production payment channel networks. The most widely implemented construction is the Hashed Timelock Contract (HTLC). More recent designs, including Point Timelock Contracts (PTLCs), extend this model with improved composability and privacy.
This appendix outlines their operation and relevance to payment-to-execution architectures.
A.1 HTLC Flow
An HTLC enables conditional settlement based on revelation of a cryptographic preimage within a defined time window.
The simplified flow is:
A payer generates a secret value s.
The hash H(s) is embedded in a conditional payment.
The payee can claim the payment only by revealing s before a timelock expires.
If the secret is not revealed in time, the payment reverts.
This construction is widely used in routed payment channels. The revelation of the preimage both finalizes settlement and proves that a specific condition has been satisfied.
Key properties:
Settlement contingent on a verifiable cryptographic event.
Predefined refund path via timelock.
No centralized intermediary required.
In a payment-to-execution context, an execution environment could generate the secret only upon successful completion of a bounded capability. Revealing that secret would finalize settlement.
However, HTLCs have limitations:
The preimage becomes public upon settlement.
Conditional logic is limited to hash revelation or timeout.
Complex multi-party flows require layered constructions.
HTLCs are sufficient for simple conditional release. They are less expressive for richer execution-bound workflows.
A.2 PTLC Flow
PTLCs replace hash-based conditions with elliptic curve point commitments and adaptor signatures.
Instead of locking payment to a hash, PTLCs embed the condition directly into the signature logic used to authorize settlement.
Conceptually:
A conditional payment is tied to a public elliptic curve point.
The payee finalizes settlement by producing a valid signature incorporating a corresponding secret scalar.
Completion of the signature reveals the scalar needed to satisfy upstream conditions.
Refund logic remains enforced through timelock constraints.
Key properties:
No public hash revelation.
Improved privacy and reduced linkability.
Cleaner composition of multi-party conditional flows.
More flexible integration with adaptor signatures and advanced proof systems.
In a payment-to-execution architecture, this allows settlement to be tightly coupled to the generation of an execution proof rather than to disclosure of a standalone secret.
Partial execution states can map to differentiated settlement outcomes. Multi-party workflows can settle atomically without exposing unnecessary intermediate states.
HTLCs demonstrate that conditional settlement is operational today.
PTLCs expand the expressive depth of those conditions.
A.3 Practical Implications for Space Systems
For space systems, conditional primitives matter because execution may be:
Multi-stage
Resource-bounded
Contention-sensitive
Cross-operator
Settlement mechanisms must accommodate deterministic success, failure, and partial fulfillment states.
Payment-to-execution does not depend on a specific primitive. It depends on the existence of cryptographically enforceable conditional settlement.
HTLCs establish viability.
PTLCs enable deeper composability.
Sources
[1] Netflix ISP Speed Index (Netflix publishes measured throughput by ISP, reflecting congestion and ISP policy effects), accessed February 2026,
https://ispspeedindex.netflix.net/
[2] RFC 9110: HTTP Semantics, Section 15.5.3 (402 Payment Required), accessed February 2026,
https://datatracker.ietf.org/doc/html/rfc9110
[3] L402: Lightning HTTP 402 Protocol overview (Macaroons + Lightning payments used with 402 flows), accessed February 2026,
https://docs.lightning.engineering/the-lightning-network/l402
[4] L402 Protocol Specification (Macaroon + invoice preimage model for service access), accessed February 2026,
https://docs.lightning.engineering/the-lightning-network/l402/protocol-specification
[5] AWS API Gateway request throttling documentation (rate limits and 429 responses under burst and steady-state limits), accessed February 2026,
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
[6] AWS Ground Station pricing (On-Demand vs Reserved scheduling, “improved scheduling” language), accessed February 2026,
https://aws.amazon.com/ground-station/pricing/
[7] AWS Ground Station FAQs (On-Demand contacts schedulable 15 minutes to 7 days in advance; Reserved scheduling tied to reservation), accessed February 2026,
https://aws.amazon.com/ground-station/faqs/
[8] Space Market Update Q4 2024 (Gallagher) describing market volatility, loss-driven underwriting tightening, and premium pressure, accessed February 2026,
https://specialty.ajg.com/plane-talking/space-market-update-q4-2024
[9] AXA XL article on space insurance market transformation, including premium volume dynamics versus satellite counts, accessed February 2026,
https://axaxl.com/fast-fast-forward/articles/adapting-to-a-new-era_how-the-space-insurance-market-is-transforming
[10] UCS Satellite Database (Union of Concerned Scientists), number of active satellites by year, accessed February 2026,
https://www.ucsusa.org/resources/satellite-database
[11] AWS post-incident analysis discussing control-plane impairment and customer remediation limits, accessed February 2026,
https://aws.amazon.com/message/12721/
