Individual Submission S. Das
Internet-Draft Independent
Intended status: Informational 14 September 2026
Expires: 18 March 2027
Execution-Finality Profiles for LEO/NTN Satellites, Orbital AI, Optical
ISLs, Spacecraft Autonomy, and Cybersecurity
draft-das-satellite-orbital-finality-profiles-00
Abstract
Satellite and non-terrestrial networks are becoming programmable
compute, routing, sensing, radio, and AI infrastructures. In such
systems, successful authentication, attestation, routing, scheduling,
inference, fault recovery, or protocol processing does not
necessarily establish authority for the resulting operation to become
externally effective.
This document describes an execution-finality architecture in which a
consequence-bearing operation is represented as a Candidate Act and
may remain in a Non-Effective State after computation. A Protected
Enforcement Domain validates act-bound predicates and protected
state, commits protected validation evidence, and permits release of
scoped non-bearer authority. A Finality Sink at or before the
relevant consequence boundary verifies that authority before an
operation becomes routing-effective, radiative-effective, storage-
effective, control-effective, disclosure-effective, or otherwise
externally effective.
Sixty satellite and NTN enforcement profiles are provided, covering
orbital AI output release, model-state transfer, Earth observation,
power- and thermal-bounded compute, radiation recovery, optical
inter-satellite links, onboard gNB and user-plane functions, delay-
tolerant delivery, emergency services, firmware and microcode
activation, privileged maintenance, orbital maneuver and collision-
avoidance authority, proximity operations, propulsion and attitude
actuation, hosted-payload control, sensing activation, end-of-life
decommissioning, manufacturing and launch-preparation component
admission, and high-consequence command release. Each profile states
a concrete problem space and the corresponding execution-finality
solution.
Publicly described work from SpaceX / Starlink, Blue Origin, Northrop
Grumman / SpaceLogistics, Rocket Lab, Airbus Defence and Space, and
Thales Alenia Space illustrates industry directions involving direct-
to-device connectivity, optical inter-satellite networking, orbital
mobility, hosted and software-defined payloads, onboard processing,
Das Expires 18 March 2027 [Page 1]
Internet-Draft LEO/NTN Orbital Finality September 2026
rendezvous and proximity operations, and in-orbit servicing. These
references identify technical complementarity and possible
enforcement locations; they do not imply that any named organization
has reviewed, endorsed, adopted, or lacks equivalent mechanisms.
The proposal does not replace 3GPP NTN, IETF routing or Time-Variant
Routing, DTN, RATS/attestation, ACE authorization, SUIT update
mechanisms, optical-link protocols, spacecraft fault detection,
isolation and recovery, or cryptographic authentication. Those
mechanisms can provide inputs to the finality decision. The
additional question is whether a specific Candidate Act is permitted
to cross the boundary at which it first acquires external effect.
Technical corrections and references to equivalent existing
mechanisms are expressly invited.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Das Expires 18 March 2027 [Page 2]
Internet-Draft LEO/NTN Orbital Finality September 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Problem Space . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Existing Approaches and the Remaining Gap . . . . . . . . 7
1.3. From Policy Requirements to Technical Enforcement . . . . 8
1.4. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 9
2. Relationship to the Existing NTN/RF Execution-Finality
Draft . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Correction, Consolidation, and Modification Invited . . . 12
3. Public Industry Context and Technical Complementarity . . . . 13
3.1. SpaceX / Starlink . . . . . . . . . . . . . . . . . . . . 14
3.2. Blue Origin . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Northrop Grumman / SpaceLogistics . . . . . . . . . . . . 15
3.4. Rocket Lab . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Airbus Defence and Space . . . . . . . . . . . . . . . . 15
3.6. Thales Alenia Space . . . . . . . . . . . . . . . . . . . 16
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Execution-Finality Architecture . . . . . . . . . . . . . . . 17
5.1. Core Enforcement Properties . . . . . . . . . . . . . . . 17
6. Satellite and NTN Threat and Failure Model . . . . . . . . . 18
7. Relationship to Existing Technologies and Standards . . . . . 19
7.1. Relevance to IETF Working Groups and Areas . . . . . . . 21
7.2. Correction Invited and Equivalence Test . . . . . . . . . 21
8. Companion Public Resources and Related Internet-Drafts . . . 22
8.1. Related IETF Internet-Drafts . . . . . . . . . . . . . . 22
8.2. GitHub Reference Implementations . . . . . . . . . . . . 22
8.3. Zenodo Technical Background and Archived Material . . . . 22
9. Additional Patent-Family Disclosure for Technical
Transparency . . . . . . . . . . . . . . . . . . . . . . 23
9.1. WIPO/PCT Application Disclosure Trail . . . . . . . . . . 23
9.2. Indian Provisional Application Disclosure Trail . . . . . 24
9.3. Separation of Technical Disclosure from Patent Status . . 25
10. Satellite and NTN Enforcement Profiles . . . . . . . . . . . 26
10.1. Sovereignty, Cross-Border Handoff, and Gateway
Profiles . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1.1. Profile 1: Satellite and NTN Sovereignty Finality . 26
10.1.2. Profile 2: Cross-Border Downlink and Terrestrial
Sovereign-Ingress Finality . . . . . . . . . . . . . 27
10.1.3. Profile 3: NTN Terrestrial-Satellite Mobility and
Handover Finality . . . . . . . . . . . . . . . . . . 27
10.1.4. Profile 4: Beam-Footprint and Jurisdiction-Mapping
Finality . . . . . . . . . . . . . . . . . . . . . . 28
10.1.5. Profile 5: Gateway, Feeder-Link, and Service-Link
Effectuation Finality . . . . . . . . . . . . . . . . 28
10.2. Orbital AI, Model State, Earth Observation, and Compute
Profiles . . . . . . . . . . . . . . . . . . . . . . . . 29
Das Expires 18 March 2027 [Page 3]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.2.1. Profile 6: Orbital AI Inference-Output Release
Finality . . . . . . . . . . . . . . . . . . . . . . 29
10.2.2. Profile 7: Ground-Station and Orbital-Cloud API
Response Finality . . . . . . . . . . . . . . . . . . 30
10.2.3. Profile 8: Space-to-Earth AI Sovereign Handoff
Finality . . . . . . . . . . . . . . . . . . . . . . 30
10.2.4. Profile 9: Inter-Satellite Tensor Transfer
Finality . . . . . . . . . . . . . . . . . . . . . . 31
10.2.5. Profile 10: Inter-Satellite KV-Cache and Hidden-State
Finality . . . . . . . . . . . . . . . . . . . . . . 32
10.2.6. Profile 11: Orbital Model-Weight and Checkpoint
Migration Finality . . . . . . . . . . . . . . . . . 32
10.2.7. Profile 12: Orbital Training-Shard and
Gradient-Release Finality . . . . . . . . . . . . . . 33
10.2.8. Profile 13: Satellite LoRA and Adapter-Update
Activation Finality . . . . . . . . . . . . . . . . . 34
10.2.9. Profile 14: Sensor-Origin Provenance Admission
Finality . . . . . . . . . . . . . . . . . . . . . . 34
10.2.10. Profile 15: Poisoning-Risk and Quarantine
Finality . . . . . . . . . . . . . . . . . . . . . . 35
10.2.11. Profile 16: Ground-Aggregator Model-Update Admission
Finality . . . . . . . . . . . . . . . . . . . . . . 36
10.2.12. Profile 17: Earth-Observation AI Product Release
Finality . . . . . . . . . . . . . . . . . . . . . . 36
10.2.13. Profile 18: Earth-Observation Resolution and
Purpose-Bounded Disclosure Finality . . . . . . . . . 37
10.2.14. Profile 19: Solar-Power, Battery, Thermal-Window, and
Compute-Scheduling Finality . . . . . . . . . . . . . 38
10.2.15. Profile 20: Power-Budgeted Orbital Compute Admission
Finality . . . . . . . . . . . . . . . . . . . . . . 38
10.2.16. Profile 21: Accelerator Launch, Partition, and
Clock-Enable Finality . . . . . . . . . . . . . . . . 39
10.3. Spacecraft Hardware, Radiation, Memory, and Recovery
Profiles . . . . . . . . . . . . . . . . . . . . . . . . 40
10.3.1. Profile 22: Single-Event-Upset Evidence and Recovery
Finality . . . . . . . . . . . . . . . . . . . . . . 40
10.3.2. Profile 23: ECC Scrub and Memory-Integrity Epoch
Finality . . . . . . . . . . . . . . . . . . . . . . 40
10.3.3. Profile 24: Post-Scrub Checkpoint and
Memory-Externalization Finality . . . . . . . . . . . 41
10.3.4. Profile 25: Triple-Modular-Redundancy and
Redundant-Vote Finality . . . . . . . . . . . . . . . 41
10.3.5. Profile 26: Latch-Up, Overcurrent, and Subsystem
Re-Enable Finality . . . . . . . . . . . . . . . . . 42
10.3.6. Profile 27: Safe-Mode Exit and Operational Re-Entry
Finality . . . . . . . . . . . . . . . . . . . . . . 43
10.3.7. Profile 28: Radiation-Degraded Output Release
Finality . . . . . . . . . . . . . . . . . . . . . . 43
Das Expires 18 March 2027 [Page 4]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.3.8. Profile 29: Post-Radiation Boot, Recovery-Image, and
Rollback Finality . . . . . . . . . . . . . . . . . . 44
10.4. Optical and Inter-Satellite Network Profiles . . . . . . 45
10.4.1. Profile 30: Optical Inter-Satellite Link Establishment
Finality . . . . . . . . . . . . . . . . . . . . . . 45
10.4.2. Profile 31: Optical Pointing, Acquisition, and
Laser-Emission Finality . . . . . . . . . . . . . . . 45
10.4.3. Profile 32: Wavelength, Channel, and Optical
Beam-Retune Finality . . . . . . . . . . . . . . . . 46
10.4.4. Profile 33: Partner-Constellation Admission and
Attestation Finality . . . . . . . . . . . . . . . . 46
10.4.5. Profile 34: Multi-Protocol Optical and Satellite
Translation Finality . . . . . . . . . . . . . . . . 47
10.4.6. Profile 35: Optical Mesh Route and
Jurisdiction-Corridor Finality . . . . . . . . . . . 48
10.5. NTN, RAN, Direct-to-Device, DTN, and Emergency-Service
Profiles . . . . . . . . . . . . . . . . . . . . . . . . 48
10.5.1. Profile 36: Onboard gNB and AI-RAN Scheduler
Finality . . . . . . . . . . . . . . . . . . . . . . 48
10.5.2. Profile 37: Satellite UPF-Like User-Plane Forwarding
Finality . . . . . . . . . . . . . . . . . . . . . . 49
10.5.3. Profile 38: UE-Satellite-UE and Direct-to-Device Relay
Finality . . . . . . . . . . . . . . . . . . . . . . 50
10.5.4. Profile 39: NTN Network-Slice Admission and Mutation
Finality . . . . . . . . . . . . . . . . . . . . . . 50
10.5.5. Profile 40: DTN Store-and-Forward Release
Finality . . . . . . . . . . . . . . . . . . . . . . 51
10.5.6. Profile 41: Delayed Delivery Revocation and
Revalidation Finality . . . . . . . . . . . . . . . . 51
10.5.7. Profile 42: Emergency Satellite Bearer Finality . . 52
10.5.8. Profile 43: Mass-Alert Broadcast Finality . . . . . 53
10.5.9. Profile 44: Location Disclosure and Rescue-Mode
Finality . . . . . . . . . . . . . . . . . . . . . . 53
10.5.10. Profile 45: Disaster Roaming and Offline-Survival
Service Finality . . . . . . . . . . . . . . . . . . 54
10.6. Firmware, Microcode, Maintenance, and Privileged-Control
Profiles . . . . . . . . . . . . . . . . . . . . . . . . 55
10.6.1. Profile 46: Satellite Microcode-Update Activation
Finality . . . . . . . . . . . . . . . . . . . . . . 55
10.6.2. Profile 47: Beamforming Firmware and Codebook Update
Finality . . . . . . . . . . . . . . . . . . . . . . 55
10.6.3. Profile 48: Payload-Controller Patch Finality . . . 56
10.6.4. Profile 49: Maintenance, Debug, JTAG, and Privileged
Console Finality . . . . . . . . . . . . . . . . . . 57
10.6.5. Profile 50: Break-Glass, Emergency Override, and
Finality-Bypass Control . . . . . . . . . . . . . . . 57
10.7. Future Space-Mobility, Manufacturing, Servicing, and
End-of-Life Profiles . . . . . . . . . . . . . . . . . . 58
Das Expires 18 March 2027 [Page 5]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.7.1. Profile 51: Autonomous Orbital Maneuver and Delta-V
Finality . . . . . . . . . . . . . . . . . . . . . . 59
10.7.2. Profile 52: Collision-Avoidance and
Conjunction-Response Finality . . . . . . . . . . . . 60
10.7.3. Profile 53: Rendezvous, Proximity-Operations, and
Servicing-Approach Finality . . . . . . . . . . . . . 60
10.7.4. Profile 54: Propulsion Ignition and Thruster-Impulse
Finality . . . . . . . . . . . . . . . . . . . . . . 61
10.7.5. Profile 55: Attitude-Control, Reaction-Wheel, and
Gimbal Actuation Finality . . . . . . . . . . . . . . 62
10.7.6. Profile 56: Hosted-Payload Activation,
Reconfiguration, and Third-Party Egress Finality . . 63
10.7.7. Profile 57: High-Resolution Imaging and
Sensor-Exposure Finality . . . . . . . . . . . . . . 63
10.7.8. Profile 58: End-of-Life Battery Decommissioning and
Irreversible Power-State Finality . . . . . . . . . . 64
10.7.9. Profile 59: Spaceborne Component Re-Admission Across
Manufacturing, Integration, Launch Preparation, and
Servicing . . . . . . . . . . . . . . . . . . . . . . 65
10.7.10. Profile 60: High-Consequence Mission Command Quorum
and Anti-Coercion Finality . . . . . . . . . . . . . 66
11. Operational and Deployment Considerations . . . . . . . . . . 67
11.1. Finality-Sink Placement . . . . . . . . . . . . . . . . 67
11.2. Latency and Availability Tradeoffs . . . . . . . . . . . 67
11.3. Disconnected and Emergency Operation . . . . . . . . . . 67
11.4. Incremental and Legacy Deployment . . . . . . . . . . . 67
11.5. Time, Ephemeris, Epoch, and Revocation State . . . . . . 67
12. Security Considerations . . . . . . . . . . . . . . . . . . . 68
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 68
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68
15. Informative References . . . . . . . . . . . . . . . . . . . 68
Profile Construction and Traceability . . . . . . . . . . . . . . 72
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 73
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 73
1. Introduction
Satellite systems increasingly combine radio access, direct-to-device
communication, regenerative payloads, onboard packet processing,
optical inter-satellite links, distributed sensing, onboard AI
inference, accelerator compute, autonomous scheduling, store-and-
forward communication, Earth observation analytics, and satellite-to-
ground cloud services.
These capabilities make a distinction necessary between an operation
being computable and an operation being authorized to cause a
consequence. A model can infer, a route can exist, an attestation
result can be acceptable, a command can authenticate, a bundle can be
Das Expires 18 March 2027 [Page 6]
Internet-Draft LEO/NTN Orbital Finality September 2026
stored, or a recovery procedure can complete without those facts
necessarily answering whether the exact resulting act should become
externally effective now.
The core invariant of this document is therefore: *computation is not
authority*. The proposal makes the execution-to-effect boundary
explicit and places a verifiable finality decision at or before that
boundary.
1.1. Problem Space
The problem is not limited to malicious commands. It also includes
stale authority, delayed delivery, changing orbital geometry, route
changes, cross-jurisdictional handoff, autonomous model output,
radiation-degraded state, partner-constellation changes, emergency-
mode transitions, and software updates whose downstream effects are
broader than the authority used to obtain or install them.
Existing controls frequently establish properties about identity,
platform state, connectivity, path availability, update authenticity,
or fault recovery. Those properties are necessary. The unresolved
engineering question addressed here is narrower: what prevents a
prepared operation from becoming effective when one of the conditions
governing the actual consequence is absent, stale, revoked,
mismatched, exhausted, or indeterminate?
1.2. Existing Approaches and the Remaining Gap
Existing solutions already address important parts of the system:
cryptographic authentication can establish identity and integrity;
secure channels can protect transport; RATS can provide evidence and
Attestation Results; TVR and routing mechanisms can describe path
state; DTN can carry data across disruption; ACE can provide
constrained authorization; SUIT can protect software-update
workflows; spacecraft FDIR can detect, isolate and recover faults;
and 3GPP NTN can provide radio, mobility, bearer and user/control-
plane procedures.
The proposed architecture does not duplicate those functions. The
remaining gap considered here is the transition from a successful
upstream operation to an externally consequential act.
Authentication answers who or what; attestation can answer properties
of state; routing answers how traffic can move; DTN answers how it
can survive disruption; FDIR answers how faults are detected and
recovered. Execution finality asks whether this exact Candidate Act,
under the current bound state, may cross this consequence boundary
now.
Das Expires 18 March 2027 [Page 7]
Internet-Draft LEO/NTN Orbital Finality September 2026
The technical shortcoming addressed by the proposal is therefore not
the absence of policy or the absence of those mechanisms. It is the
possibility that a policy decision or trustworthy upstream result is
advisory, stale, detached from the act, or bypassable at the point of
effect. The proposed solution is to preserve a Non-Effective State
until act-bound authority is verified by the Finality Sink.
1.3. From Policy Requirements to Technical Enforcement
Regulatory and risk-management frameworks increasingly require
lifecycle risk management, oversight, robustness, cybersecurity, and
technical or organisational mitigation. As one example, Articles 9,
14, and 15 of the European Union Artificial Intelligence Act address
risk management, human oversight, and accuracy, robustness and
cybersecurity for high-risk AI systems [EU-AI-ACT]. The same
Regulation contains a standards and conformity-assessment section,
including Article 40 on harmonised standards and standardisation
deliverables, illustrating the continuing need to translate legal
requirements into interoperable technical specifications. The NIST
AI Risk Management Framework similarly treats AI risk management as
an ongoing governance and risk management activity [NIST-AI-RMF].
Those frameworks do not mandate the architecture in this document,
and deployment of execution finality does not by itself establish
legal or regulatory compliance. Their relevance is the engineering
translation problem: high-level requirements such as risk mitigation,
oversight, robustness, misuse resistance, and cybersecurity must
ultimately be enforced through concrete system behavior.
Policies, audits, operating procedures, logs, model documentation,
contracts, and human-oversight processes remain important. They are
not, by themselves, a technical property that prevents a machine-
generated act from crossing an effect boundary. This document
therefore focuses on the *policy-to-enforcement* and *execution-to-
effect* boundary rather than treating documentation or post-event
evidence as a substitute for pre-effectuation control.
Das Expires 18 March 2027 [Page 8]
Internet-Draft LEO/NTN Orbital Finality September 2026
+===============+===============================+=================+
| Policy | Possible execution-finality | Not claimed |
| objective | contribution | |
+===============+===============================+=================+
| Risk | Machine-verifiable predicates | A complete |
| mitigation | and fail-closed effectuation | risk-management |
| | | program |
+---------------+-------------------------------+-----------------+
| Human | Human approval or quorum can | Replacement of |
| oversight | be a bound predicate before | human oversight |
| | effect | duties |
+---------------+-------------------------------+-----------------+
| Robustness | Freshness, revocation, | Complete system |
| and | protected state, alternate- | cybersecurity |
| cybersecurity | path closure, bounded release | |
+---------------+-------------------------------+-----------------+
| Traceability | Protected validation evidence | A universal |
| | committed before or | legal audit- |
| | atomically with release | record format |
+---------------+-------------------------------+-----------------+
Table 1: Illustrative regulatory-to-technical alignment
1.4. Scope and Non-Goals
This document is an architectural and profile catalogue. It does not
define a new satellite physical layer, radio scheduler, optical
modulation scheme, routing protocol, attestation evidence format,
firmware manifest, legal policy language, spacecraft FDIR algorithm,
or universal capability-token format.
The architecture can consume outputs from such systems as predicates.
It does not decide what the governing policy should be. It defines
where and how a policy decision can be made load-bearing before the
corresponding external consequence.
2. Relationship to the Existing NTN/RF Execution-Finality Draft
This document is complementary to, and does not replace, the earlier
Internet-Draft “RF Enable Is Not Transmit Authority: Finality for
LEO/NTN and Inter-Satellite Control” ([DAS-NTN-RF]draft-das-ntn-rf-
execution-finality).
The earlier document addresses a deliberately focused problem: the
transition from an authenticated, scheduled, computed, or otherwise
prepared satellite or non-terrestrial-network operation into an
actual radio-frequency, beam, inter-satellite-link, gateway, or
related communications consequence. Its principal enforcement
Das Expires 18 March 2027 [Page 9]
Internet-Draft LEO/NTN Orbital Finality September 2026
locations include boundaries such as power-amplifier enablement,
beam-control paths, inter-satellite forwarding, feeder gateways,
user-terminal transmit paths, and other points at which a prepared
network or radio operation becomes physically or externally
effective.
The present document serves a different but complementary purpose.
Satellite and non-terrestrial infrastructure increasingly extends
beyond RF transport. A modern spacecraft or constellation may
contain autonomous mission software, onboard AI accelerators,
distributed orbital compute, optical inter-satellite networking,
regenerative payloads, software-defined routing, spacecraft recovery
logic, radiation-tolerant computing, programmable firmware, hosted
third-party payloads, autonomous collision-avoidance functions,
orbital-maneuver planning, propulsion and attitude-control systems,
Earth-observation processing, cross-constellation cooperation,
delayed store-and-forward services, and increasingly autonomous
maintenance and mission-management functions.
Accordingly, the present document does not attempt merely to restate
the RF-finality mechanism for additional satellite examples.
Instead, it provides a catalogue of Enforcement Profiles showing how
the common execution-finality invariant may be instantiated at
materially different satellite, spacecraft, orbital-compute,
manufacturing, servicing, routing, sensing, recovery, and physical-
effect boundaries.
The relationship between the two documents may therefore be
summarized as follows:
* draft-das-ntn-rf-execution-finality provides a focused treatment
of execution finality for NTN, RF, beam, inter-satellite-link,
gateway, and closely related communications consequences.
* This document provides a broader satellite and orbital-
infrastructure profile catalogue describing how the same
underlying execution-finality architecture may apply across
multiple distinct consequence classes and technical boundaries.
Das Expires 18 March 2027 [Page 10]
Internet-Draft LEO/NTN Orbital Finality September 2026
For example, the present profile catalogue includes cases in which
the relevant Finality Sink is not an RF transmitter. Depending on
the profile, the Finality Sink may instead be an orbital-AI output-
release boundary, optical-terminal admission gate, tensor-ingress
interface, spacecraft storage-commit interface, propulsion actuator,
thruster latch valve, reaction-wheel driver, payload activation rail,
sensor-exposure control, firmware activation boundary, reset-release
gate, safe-mode exit gate, spacecraft-component admission boundary,
or terrestrial ingestion boundary.
The distinction is important because the same architectural principle
can produce different engineering requirements depending on the
consequence being controlled.
A transmit operation may require verification immediately before RF
energy leaves an aperture. An orbital AI result may require
verification before downlink or destination admission. An inter-
satellite tensor transfer may require separate source-release and
destination-admission checks. A spacecraft recovery action may
require verification before reset release or safe-mode exit. A
propulsion command may require verification at a thruster or actuator
boundary. A replacement or reintroduced spacecraft component may
require validation before it becomes operationally authoritative
within the spacecraft package. These are related applications of
execution finality, but they are not identical effectuation
boundaries.
The profiles therefore make explicit a property that would otherwise
remain hidden behind a generic statement that “execution finality
also applies to satellites.” Each profile identifies the concrete
problem space, Candidate Act, Non-Effective State, relevant authority
predicates and protected evidence, scoped authority, applicable
Finality Sink, fail-closed behavior, and relationship to existing
technical mechanisms.
This profile-oriented treatment also makes it possible to evaluate
the architecture against existing standards and implementations on a
boundary-by-boundary basis. A mechanism that already provides an
equivalent property for RF transmission may not necessarily provide
the same property for orbital AI output release, firmware activation,
autonomous maneuver execution, post-radiation recovery, optical-mesh
admission, hosted-payload egress, or component re-admission.
Conversely, an existing mechanism in any of those domains may already
satisfy some or all of the execution-finality properties described by
the corresponding profile.
Das Expires 18 March 2027 [Page 11]
Internet-Draft LEO/NTN Orbital Finality September 2026
For that reason, the existence of the earlier NTN/RF draft is not
treated as evidence that a second satellite-focused document is
required merely for additional terminology or additional use cases.
The justification for this document is the presence of materially
different consequence boundaries requiring separate technical
analysis.
The documents intentionally share the same architectural substrate:
Candidate Act
|
v
Non-Effective State
|
v
Protected Validation
|
v
Protected Validation Evidence
|
v
Scoped Non-Bearer Authority
|
v
Finality Sink Verification
|
v
External Effect
They differ principally in scope and level of decomposition.
Where an Enforcement Profile in this document substantially overlaps
the earlier NTN/RF draft, the earlier draft should be treated as the
more focused technical treatment of that RF- or communications-
specific boundary. This document provides the wider profile context
and should not duplicate detailed material unnecessarily.
Where a profile addresses a consequence boundary outside that focused
NTN/RF scope, this document provides the domain-specific problem
statement and execution-finality mapping.
2.1. Correction, Consolidation, and Modification Invited
The separation between the two documents is intended to improve
technical clarity rather than multiply specifications unnecessarily.
Readers are expressly invited to identify:
Das Expires 18 March 2027 [Page 12]
Internet-Draft LEO/NTN Orbital Finality September 2026
* a profile in this document that is already fully and unambiguously
covered by draft-das-ntn-rf-execution-finality;
* an existing IETF, 3GPP, CCSDS, ETSI, ITU, space-industry,
hardware, safety, or proprietary mechanism that already provides
an equivalent enforcement property;
* a profile whose technical distinction is too small to justify
separate treatment;
* an enforcement boundary that has been characterized incorrectly;
* terminology that should be aligned between the documents;
* profiles that should be consolidated, narrowed, expanded,
relocated, or removed; or
* additional technical distinctions necessary to accurately
represent deployed or emerging satellite architectures.
Such corrections and modifications are welcomed.
The objective is not to claim that existing satellite or NTN systems
lack equivalent mechanisms. The objective is to identify, with
sufficient technical precision, the point at which a particular
prepared satellite operation becomes externally effective and to
determine whether act-specific, current, machine-verifiable authority
is enforced at that boundary.
These references and cross-references identify technical
complementarity and possible enforcement locations; they do not imply
that any named organization has reviewed, endorsed, adopted, or lacks
equivalent mechanisms.
3. Public Industry Context and Technical Complementarity
These public references are included to orient the engineering
discussion around capabilities that make consequence-bound
authorization increasingly relevant. The references identify
publicly described directions in satellite manufacturing, launch and
in-space systems, orbital mobility, direct-to-device connectivity,
software-defined payloads, optical inter-satellite networking, hosted
payloads, onboard processing, and in-orbit servicing. They are not
statements about proprietary implementation details.
These references identify technical complementarity and possible
enforcement locations; they do not imply that any named organization
has reviewed, endorsed, adopted, or lacks equivalent mechanisms.
Das Expires 18 March 2027 [Page 13]
Internet-Draft LEO/NTN Orbital Finality September 2026
Corrections and modifications are expressly invited. A named
organization, standards participant, implementer, researcher, or
other reader is encouraged to identify any inaccurate
characterization, later technical change, existing equivalent or
stronger mechanism, more appropriate enforcement boundary, or wording
that should be narrowed, corrected, expanded, or removed. Where an
equivalent mechanism exists, the most useful correction is a
reference to the specific public mechanism and an explanation of
where the equivalent of the Candidate Act, Non-Effective State, act-
bound validation evidence or authority, Finality Sink, and alternate-
path closure occurs.
This industry-context discussion is technical rather than legal. It
does not state or imply patent infringement, patent essentiality,
freedom-to-operate status, novelty, inventive step, validity,
enforceability, or a legal prior-art conclusion. Patent and
standards-IPR questions are governed by their applicable legal and
procedural frameworks independently of these engineering references.
3.1. SpaceX / Starlink
SpaceX publicly describes Starlink Direct to Cell satellites as
regenerative cellular infrastructure using onboard eNodeB
functionality, phased-array antennas, and laser backhaul through the
Starlink constellation. SpaceX also describes Starlink laser inter-
satellite networking and future Direct to Cell generations with
substantially greater beam and bandwidth capability. These
directions make Profiles covering beam/RF effectuation, inter-
satellite routing, onboard scheduling, partner or destination
admission, autonomous orbital state, and fail-closed consequence
boundaries potentially relevant as possible technical application
points. Possible enforcement locations discussed by this document
include RF-chain enablement, beamforming or antenna-control
boundaries, optical-terminal admission, routing or packet-forwarding
gates, and propulsion or attitude-control boundaries; this does not
assert how SpaceX implements those functions internally. Public
reference (https://starlink.com/business/direct-to-cell).
3.2. Blue Origin
Blue Origin publicly describes Blue Ring as a highly maneuverable
multi-mission and multi-orbit spacecraft supporting payload hosting
and deployment, onboard computing and communications, and substantial
orbital maneuverability. Those capabilities create natural possible
technical application points for Profiles 51, 53, 54, 56, and related
orbital-compute and payload-release profiles. Potential Finality
Sinks in the abstract architecture could include propulsion
enablement, hosted-payload activation, onboard-compute egress,
Das Expires 18 March 2027 [Page 14]
Internet-Draft LEO/NTN Orbital Finality September 2026
communications release, or other mandatory consequence boundaries.
No assertion is made about Blue Origin's internal authorization or
safety architecture. Public reference (https://www.blueorigin.com/
blue-ring).
3.3. Northrop Grumman / SpaceLogistics
Northrop Grumman publicly describes SpaceLogistics systems for
mission extension and robotic in-orbit servicing, including
rendezvous and proximity operations, inspection, relocation, repair,
upgrades, disposal, debris-removal functions, and robotic servicing.
These capabilities are technically adjacent to Profiles 52 and 53 and
to act-bound propulsion, attitude, servicing-approach, payload, and
irreversible mission-state controls. The document identifies
possible consequence boundaries generically, such as propulsion or
attitude actuation and other servicing-effectuation gates, without
asserting the internal architecture of SpaceLogistics systems.
Public reference (https://www.northropgrumman.com/what-we-do/space/
space-logistics-services).
3.4. Rocket Lab
Rocket Lab has publicly described spacecraft and mission capabilities
including Photon-based in-space propulsion, orbit raising and hosted
payload operation, and has identified programs involving rendezvous
and proximity operations and an in-orbit spacecraft refueling depot.
These directions provide useful technical context for orbital-
maneuver, propulsion, proximity-operation, mission-state, and
spacecraft-integration profiles. The present architecture does not
define refueling plumbing or docking mechanics; it addresses only
supported authority and effectuation boundaries such as exact
maneuver release, propulsion enablement, payload or subsystem
activation, and protected command execution. Public reference
(https://investors.rocketlabusa.com/files/doc_financials/2024/q2/
FINAL-Rocket-Lab-Q2-2024-Earnings-Presentation.pdf).
3.5. Airbus Defence and Space
Airbus publicly describes SpaceRAN work using software-defined
satellites, onboard 5G processing, inter-satellite links, routing,
and beam or satellite handover, and is also developing large LEO
satellite programs. These directions are technically complementary
to profiles concerning onboard gNB or regenerative processing, NTN
handoff, inter-satellite routing, software-defined payload state,
beam control, and orbital compute or output release. Possible
enforcement locations in this document include onboard routing or
scheduler commits, payload-control boundaries, beam or RF
effectuation points, optical-link gates, and terrestrial handoff
Das Expires 18 March 2027 [Page 15]
Internet-Draft LEO/NTN Orbital Finality September 2026
admission. No claim is made about whether Airbus systems already
provide equivalent controls. Public reference
(https://www.airbus.com/en/newsroom/press-releases/2026-01-airbus-
launches-demonstrator-to-test-global-5g-connectivity-in).
3.6. Thales Alenia Space
Thales Alenia Space publicly describes secure digital satellite
payloads and future IRIS2 payload work involving optical inter-
satellite links, native 5G capability, in-orbit traffic routing,
active interference management, active antennas, and software-defined
processing. These directions provide technical context for optical-
link establishment, wavelength or beam control, satellite user-plane
forwarding, onboard network functions, secure routing, and payload
reconfiguration profiles. Potential enforcement locations described
here include optical-terminal or routing admission, active-antenna or
RF-control boundaries, payload-processing commits, and destination or
gateway admission; no statement is made about proprietary
implementation details or the absence of equivalent mechanisms.
Public reference (https://www.thalesgroup.com/en/news-centre/press-
releases/thales-alenia-space-provide-digital-and-secure-payloads-
330-iris2).
4. Terminology
Candidate Act A computed, proposed, queued, routed, scheduled,
recovered, or otherwise prepared operation that has not yet been
permitted to cause the relevant external consequence.
Non-Effective State A state in which the Candidate Act can exist or
be fully prepared but cannot yet produce the protected external
effect.
Protected Enforcement Domain (PED) A protected hardware, firmware,
operating-system, gateway, or hybrid enforcement domain that
validates required predicates and protected state. It is not
limited to any one TEE or HSM technology.
Protected validation evidence Machine-verifiable evidence or a
protected receipt committed before effectuation or atomically with
release of the authority required for effectuation.
Scoped non-bearer authority Authority bound to the Candidate Act,
relevant state, scope, and Finality Sink such that mere possession
of a detached artifact is insufficient to authorize a different
effect.
Finality Sink The point at or before which the protected Candidate
Das Expires 18 March 2027 [Page 16]
Internet-Draft LEO/NTN Orbital Finality September 2026
Act first becomes externally effective. The sink can verify,
reconstruct, or re-verify load-bearing state.
External Effect A network, routing, radio, optical, storage,
disclosure, control, model-update, subsystem-activation, or other
consequence protected by the profile.
Fail-closed Absence, staleness, exhaustion, revocation, mismatch,
replay, or indeterminacy results in denial, continued non-
effectiveness, bounded degradation, or an explicitly authorized
substitute path rather than unvalidated effectuation.
5. Execution-Finality Architecture
The common sequence used by the profiles is shown below. Deployments
can combine or distribute components, but the security property
depends on the ordering rather than on a particular physical
packaging.
Candidate Act
|
v
Non-Effective State
|
v
Protected validation + protected-state checks/consumption
|
v
Protected validation evidence
|
v
Scoped non-bearer authority
|
v
Finality Sink verification
|
v
External Effect
The architecture intentionally separates authority to compute from
authority to cause an effect. It can also separate authority to
consume scarce compute, power, thermal, radio, optical, or routing
resources from authority to release the resulting output.
5.1. Core Enforcement Properties
1. The consequential operation is represented as a specific
Candidate Act.
Das Expires 18 March 2027 [Page 17]
Internet-Draft LEO/NTN Orbital Finality September 2026
2. The Candidate Act can remain in a Non-Effective State after
computation or protocol processing.
3. Validation is bound to the act, relevant current state, intended
sink, and permitted consequence scope.
4. Freshness, revocation, replay, quota, and protected mutable state
are evaluated where applicable.
5. Protected validation evidence is committed before effectuation or
atomically with authority release.
6. The Finality Sink verifies the required authority before the
protected external effect.
7. Alternate paths to the equivalent protected effect are either
covered by equivalent finality enforcement or are treated as
bypasses.
8. Emergency or disconnected operation uses explicitly bounded
substitute authority rather than an unqualified fail-open path.
6. Satellite and NTN Threat and Failure Model
The profiles are motivated by both adversarial and non-adversarial
failure modes. An attacker or faulty component may be able to
prepare an operation without being entitled to make it effective.
Separately, a previously valid operation can become invalid because
satellite state changes between preparation and effectuation.
* stale, replayed, substituted, or over-broad authority;
* compromised or buggy onboard software preparing unauthorized acts;
* ground-station, gateway, operator, or partner-constellation state
changing after preparation;
* long DTN delay causing policy or revocation state to change before
delivery;
* orbital, beam, route, service-area, jurisdiction, or spectrum
state changing before effect;
* radiation, memory, power, thermal, or redundant-compute faults
corrupting load-bearing state;
* model, tensor, gradient, adapter, or sensor-state crossing tenant,
mission, purpose, or destination boundaries;
Das Expires 18 March 2027 [Page 18]
Internet-Draft LEO/NTN Orbital Finality September 2026
* firmware, microcode, or payload patches having broader effects
than the authority used to obtain them;
* maintenance, debug, emergency, or break-glass functions bypassing
ordinary control paths; and
* alternate output, routing, RF, optical, storage, or API paths
bypassing the intended enforcement point.
The architecture assumes that at least one protected enforcement path
and the cryptographic or hardware roots on which it relies remain
trustworthy. A complete compromise of every relevant Finality Sink
or its root of trust is outside the guarantee of this architecture
and must be addressed by platform, supply-chain, redundancy, and
recovery controls.
7. Relationship to Existing Technologies and Standards
The technologies below are complementary. Their inclusion does not
imply endorsement of this proposal, that the proposal is within a
particular Working Group charter, or that equivalent functionality is
absent from existing specifications. Corrections identifying an
existing equivalent are specifically requested.
+==================+======================+=========================+
| Technology / | Primary role | Execution-finality |
| work | | question |
+==================+======================+=========================+
| 3GPP NTN | Radio access, | May this specific |
| [TGPP-TR-38.821] | mobility, service | scheduled, routed, |
| | and user/control- | handed-over, or |
| | plane procedures | radiative act become |
| | | effective now? |
+------------------+----------------------+-------------------------+
| IETF TVR | Time-varying | Does an available or |
| [TVR-WG] | topology and | predicted path also |
| [RFC9657] | scheduled routing | carry authority for |
| | attributes, with | this Candidate Act and |
| | NTN as a main | consequence? |
| | driver | |
+------------------+----------------------+-------------------------+
| IETF DTN / BPv7 | Communication | When connectivity |
| [DTN-WG] | under delay and | returns, is previously |
| [RFC9171] | disruption, | accepted traffic still |
| [RFC9172] | storage and | authorized to be |
| | forwarding | released? |
+------------------+----------------------+-------------------------+
| IETF RATS | Evidence, | Does trustworthy |
Das Expires 18 March 2027 [Page 19]
Internet-Draft LEO/NTN Orbital Finality September 2026
| [RATS-WG] | appraisal and | component state |
| [RFC9334] | Attestation | authorize this |
| | Results concerning | particular output or |
| | system components | operation to cross the |
| | | effect boundary? |
+------------------+----------------------+-------------------------+
| IETF ACE | Authentication and | Is the grant bound to |
| [ACE-WG] | authorization for | the exact consequence, |
| [RFC9200] | constrained | current state, and |
| | environments | Finality Sink rather |
| | | than merely resource |
| | | access? |
+------------------+----------------------+-------------------------+
| IETF SUIT | Secure firmware- | After an update is |
| [SUIT-WG] | update | obtained or verified, |
| [RFC9019] | architecture and | when may it become |
| | manifests | active and cause |
| | | subsystem effects? |
+------------------+----------------------+-------------------------+
| IETF CCAMP | Control and | May the particular |
| [CCAMP-WG] | measurement for | optical path, retune, |
| | optical and other | or emission become |
| | non-packet | effective under current |
| | technologies | act-bound authority? |
+------------------+----------------------+-------------------------+
| TEEP | Provisioning and | Can protected execution |
| architecture | management of | be used as an |
| [TEEP-WG] | trusted | enforcement location |
| [RFC9397] | applications in | without equating TEE |
| | TEEs | presence with release |
| | | authority? |
+------------------+----------------------+-------------------------+
| Spacecraft FDIR | Fault detection, | After recovery |
| | isolation, | succeeds, which |
| | recovery, | consequential outputs |
| | redundancy, safe | or subsystem re-enables |
| | mode and subsystem | may become effective? |
| | restoration | |
+------------------+----------------------+-------------------------+
| Cryptographic | Identity, | Is this authenticated |
| authentication | integrity, origin | operation presently |
| and secure | authentication and | authorized for this |
| channels | confidentiality | consequence? |
+------------------+----------------------+-------------------------+
Table 2: Existing technology and the additional finality question
Das Expires 18 March 2027 [Page 20]
Internet-Draft LEO/NTN Orbital Finality September 2026
7.1. Relevance to IETF Working Groups and Areas
The proposal is cross-area and is not presented as work already
belonging to one Working Group. The strongest technical
intersections are TVR for time-varying satellite path state, DTN for
delayed release and store-and-forward, and RATS for trustworthy
evidence used as a predicate. ACE is relevant to constrained
authorization semantics; SUIT is relevant to update distribution and
activation; CCAMP is relevant where optical control-plane
abstractions intersect with the optical consequence boundary. TEEP
has concluded, but its architecture remains relevant where a TEE is
an implementation option for a Protected Enforcement Domain.
Radio-layer, bearer, mobility, beam, and other NTN procedure design
remains primarily a 3GPP matter. Spacecraft FDIR, flight software,
safety, spectrum, and mission-control requirements also involve
standards and operational communities outside the IETF. The IETF-
relevant question is the protocol and authorization property at
boundaries where networked state becomes a consequential act.
7.2. Correction Invited and Equivalence Test
Readers are expressly invited to identify an existing standard,
protocol, architecture, implementation, or prior work that already
provides an equivalent property for any profile. A useful correction
should identify where the equivalent mechanism provides all of the
following, or explain which property is unnecessary in that domain:
1. a specific consequence-bearing act can remain technically non-
effective after computation or protocol processing;
2. authority is bound to that act, the relevant current state, and
the intended consequence boundary;
3. required validation evidence exists before effectuation or
atomically with the authority that enables it;
4. verification occurs at or before the actual external-effect
boundary; and
5. an alternate path cannot produce the equivalent protected effect
while bypassing that verification.
The purpose of this equivalence test is not to assume that existing
mechanisms are deficient. It is to make the claimed boundary precise
enough that overlap, equivalence, or technical difference can be
tested rather than asserted.
Das Expires 18 March 2027 [Page 21]
Internet-Draft LEO/NTN Orbital Finality September 2026
8. Companion Public Resources and Related Internet-Drafts
This section lists public materials that apply the same execution-
finality architecture to closely related satellite,
telecommunications, hardware, attestation, and regulatory contexts.
These materials are informative only. They are not prerequisites for
implementing or evaluating this document, and their inclusion does
not incorporate their requirements into this document.
8.1. Related IETF Internet-Drafts
The most directly related companion document is [DAS-NTN-RF], which
applies execution finality to LEO/NTN RF transmission, beam control,
and inter-satellite operation. The broader telecommunications
relationship is developed in [DAS-6G-ORAN]. Attestation as an input
to act-specific finality is developed in [DAS-RATS-EF], while the
hardware-rooted and general protocol formulations are described in
[DAS-HW-EF] and [DAS-PROTOCOL-LAYER] respectively.
The policy-to-enforcement distinction discussed in this document is
further explored in [DAS-EU-AI-ACT], and cross-jurisdiction authority
separation is discussed in [DAS-DIGITAL-SOV]. All of these documents
are Internet-Drafts and therefore works in progress that may be
updated, replaced, or obsoleted.
8.2. GitHub Reference Implementations
A satellite-specific runnable implementation is published as
[DAS-NTN-IMPL]. Closely related implementations cover AI-native
5G/6G and O-RAN [DAS-6G-ORAN-IMPL], GPU and AI accelerator finality
[DAS-GPU-IMPL], hardware-rooted execution finality [DAS-HW-IMPL], and
technical enforcement for AI-governance constraints
[DAS-AI-GOV-IMPL].
These repositories are provided for engineering review,
experimentation, interoperability discussion, and reproducibility.
They are not production certifications, satellite flight software,
regulatory compliance certifications, or normative dependencies of
this document.
8.3. Zenodo Technical Background and Archived Material
Broader explanatory background across AI, telecommunications, cloud,
payments, satellite systems, and other consequence-bearing
environments is archived in [DAS-ZENODO-FOUNDATIONAL]. An archived
companion snapshot for accelerator and confidential-computing
execution finality is available as [DAS-ZENODO-GPU]. Additional
Candidate-Act architectural material is available as
Das Expires 18 March 2027 [Page 22]
Internet-Draft LEO/NTN Orbital Finality September 2026
[DAS-ZENODO-CANDIDATE].
These records provide supplementary context and archival stability.
The architecture and profiles in this Internet-Draft are intended to
remain understandable independently of those external materials.
9. Additional Patent-Family Disclosure for Technical Transparency
This section is provided solely for technical-source transparency,
provenance, and easier review of the public and author-disclosed
disclosure trail from which portions of the terminology, consequence-
boundary catalogue, and implementation examples in this document were
developed. Inclusion of an application in this section is not an
assertion that any patent claim is granted, valid, enforceable,
infringed, essential to an IETF standard, or required to implement
this document. It also does not imply review, approval, endorsement,
or participation by WIPO, the Indian Patent Office, the IETF, any
government, standards body, satellite operator, equipment vendor, or
other industry participant.
This informational list is not intended to satisfy, replace,
interpret, or alter any separate disclosure obligation that may arise
under RFC 8179 / BCP 79 (https://www.rfc-editor.org/info/rfc8179).
Where an IETF IPR disclosure is required, it should be made through
the IETF IPR disclosure process (https://datatracker.ietf.org/ipr/).
9.1. WIPO/PCT Application Disclosure Trail
The principal published WIPO record identified by the author is WO
2026/150382 / PCT/IB2026/055615 — THE DAS PROTOCOLS
(https://patentscope.wipo.int/search/en/
detail.jsf?docId=WO2026150382). The author identifies that
specification as the principal broad technical disclosure underlying
the execution-finality architecture discussed here. The Mothership
publication alone comprises approximately 8,598 pages of technical
disclosure, independently of the related follow-on PCT applications
and Indian provisional applications identified below.
The following related PCT application identifiers are listed for
technical transparency. Filing dates are reproduced where they are
present in the author's cross-reference materials; the authoritative
bibliographic, publication, priority, and legal status of each
application remains the applicable WIPO record.
* PCT/IB2026/053385 — filed 7 April 2026
* PCT/IB2026/054453 — filed 5 May 2026
Das Expires 18 March 2027 [Page 23]
Internet-Draft LEO/NTN Orbital Finality September 2026
* PCT/IB2026/055615 — filed 4 June 2026
* PCT/IB2026/055760 — filed 7 June 2026
* PCT/IB2026/055870 — filed 10 June 2026
* PCT/IB2026/056058 — filed 13 June 2026
* PCT/IB2026/056353 — filed 22 June 2026
* PCT/IB2026/056571 — filed 26 June 2026
* PCT/IB2026/056771 — filed 1 July 2026
* PCT/IB2026/056809 — filed 1 July 2026
* PCT/IB2026/056941 — filed 6 July 2026
* PCT/IB2026/057198 — filed 12 July 2026
* PCT/IB2026/057540 — filed 19 July 2026
* PCT/IB2026/058236
The list is a technical cross-reference only. It does not state that
every listed application has been published, that every application
claims priority to every other application, or that all subject
matter in this Internet-Draft is entitled to any particular priority
date. Readers should consult WIPO PATENTSCOPE and the official file
of the relevant application for the formal record.
9.2. Indian Provisional Application Disclosure Trail
The author has identified the following 32 Indian patent applications
as provisional applications related to the broader technical
disclosure. Some provisional filings may not themselves be publicly
accessible; the identifiers and filing dates are included here
because the author has elected to disclose them for transparency and
technical provenance.
* Indian Patent Application No. 202531123959 — filed 9 December 2025
* Indian Patent Application No. 202531123977 — filed 9 December 2025
* Indian Patent Application No. 202531125643 — filed 12 December
2025
* Indian Patent Application No. 202531129538 — filed 20 December
2025
* Indian Patent Application No. 202531130168 — filed 22 December
2025
Das Expires 18 March 2027 [Page 24]
Internet-Draft LEO/NTN Orbital Finality September 2026
* Indian Patent Application No. 202531130665 — filed 23 December
2025
* Indian Patent Application No. 202631000572 — filed 3 January 2026
* Indian Patent Application No. 202631001586 — filed 7 January 2026
* Indian Patent Application No. 202631002990 — filed 12 January 2026
* Indian Patent Application No. 202631004331 — filed 16 January 2026
* Indian Patent Application No. 202631005583 — filed 20 January 2026
* Indian Patent Application No. 202631005645 — filed 20 January 2026
* Indian Patent Application No. 202631006616 — filed 22 January 2026
* Indian Patent Application No. 202631007467 — filed 26 January 2026
* Indian Patent Application No. 202631009579 — filed 30 January 2026
* Indian Patent Application No. 202631011216 — filed 3 February 2026
* Indian Patent Application No. 202631011630 — filed 3 February 2026
* Indian Patent Application No. 202631016797 — filed 16 February
2026
* Indian Patent Application No. 202631018571 — filed 18 February
2026
* Indian Patent Application No. 202631024957 — filed 3 March 2026
* Indian Patent Application No. 202631030760 — filed 14 March 2026
* Indian Patent Application No. 202631034260 — filed 21 March 2026
* Indian Patent Application No. 202631035846 — filed 24 March 2026
* Indian Patent Application No. 202631038227 — filed 27 March 2026
* Indian Patent Application No. 202631041923 — filed 1 April 2026
* Indian Patent Application No. 202631043195 — filed 4 April 2026
* Indian Patent Application No. 202631043507 — filed 6 April 2026
* Indian Patent Application No. 202631046689 — filed 11 April 2026
* Indian Patent Application No. 202631046739 — filed 12 April 2026
* Indian Patent Application No. 202631047382 — filed 14 April 2026
* Indian Patent Application No. 202631049021 — filed 17 April 2026
* Indian Patent Application No. 202631051652 — filed 23 April 2026
Identification of an Indian application in this section is not
intended, by itself, to create, add, correct, modify, or establish a
priority claim. Any priority relationship exists only to the extent
validly and expressly reflected in the applicable Request, priority
declaration, or other official filing record.
9.3. Separation of Technical Disclosure from Patent Status
This Internet-Draft uses the listed patent-family material only as an
additional technical-disclosure trail. The architecture,
terminology, and Enforcement Profiles in this document are presented
for engineering review independently of the outcome of examination,
search, prosecution, grant, national-phase entry, abandonment,
amendment, licensing, or enforcement of any listed application.
Das Expires 18 March 2027 [Page 25]
Internet-Draft LEO/NTN Orbital Finality September 2026
For formal bibliographic data, publication status, priority
information, applicant or inventor data, national-phase status, and
the complete legal record, readers should consult WIPO PATENTSCOPE
and the relevant national patent-office records rather than relying
on this informational summary.
10. Satellite and NTN Enforcement Profiles
The following sixty profiles instantiate the same execution-finality
invariant at different consequence boundaries. They are not sixty
separate protocol principles. Several profiles are deliberate
decompositions or technically distinct combinations of broader source
mechanisms so that each problem and sink can be reviewed
independently.
10.1. Sovereignty, Cross-Border Handoff, and Gateway Profiles
10.1.1. Profile 1: Satellite and NTN Sovereignty Finality
*Problem space.* A satellite link can be authenticated, routable, and
physically available while the contemplated downlink, uplink, beam,
relay, or cross-border event is inconsistent with the current
orbital, beam, spectrum, gateway, or jurisdictional state.
*Execution-finality solution.* The Candidate Act is the proposed
satellite transmission, payload disclosure, beam activation, beam-
steering operation, relay, feeder-link transmission, or cross-border
communication event. It remains in a Non-Effective State until the
Protected Enforcement Domain validates authenticated ephemeris or
orbital state, beam geometry and coverage state, applicable
jurisdiction or spectrum policy, gateway or cross-border authority,
freshness, and revocation state; commits the required protected
validation evidence; and permits scoped non-bearer authority bound to
the Candidate Act and the intended sink. The Finality Sink is the
gateway earth station, payload controller, inter-satellite routing
switch, phase-shifter or beamforming controller, RF-chain interface,
power-amplifier bias gate, terminal controller, or NTN routing
component. The relevant operation remains non-effective rather than
becoming radiative-, routing-, disclosure-, or network-effective.
*Relationship to existing technology.* 3GPP NTN and routing
mechanisms remain responsible for radio and network procedures;
execution finality adds an act-specific consequence boundary. Where
an existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
Das Expires 18 March 2027 [Page 26]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.1.2. Profile 2: Cross-Border Downlink and Terrestrial Sovereign-
Ingress Finality
*Problem space.* An orbital compute or payload system may possess a
valid space-to-earth path even when the destination jurisdiction,
data-residency scope, policy epoch, or terrestrial-ingestion
authority has changed since computation began.
*Execution-finality solution.* The Candidate Act is the downlink,
terrestrial ingestion, cross-border routing, storage, exposure, or
application of an orbital output. It remains in a Non-Effective
State until the Protected Enforcement Domain validates destination-
jurisdiction policy, permitted ingestion scope, path and gateway
identity, policy and revocation epochs, freshness, nonce state, and
any applicable orbital-compute attestation result; commits the
required protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the space-to-earth receiver output, NTN core or
sovereign gateway, protected terrestrial-handoff boundary, or
destination admission interface. Path availability alone cannot
cause the orbital output to become effective in terrestrial
infrastructure.
*Relationship to existing technology.* TVR or other routing
information may establish path state, while RATS may contribute
platform evidence; neither is treated here as blanket release
authority. Where an existing mechanism already guarantees the same
non-bypassable consequence-bound property, that mechanism is invited
as a technical correction or equivalence reference.
10.1.3. Profile 3: NTN Terrestrial-Satellite Mobility and Handover
Finality
*Problem space.* A valid mobility or handover procedure can identify
a technically reachable terrestrial or satellite domain without
necessarily establishing current authority for the exact cross-domain
transition.
*Execution-finality solution.* The Candidate Act is NTN cell
activation, handover, satellite-to-terrestrial re-entry, gateway
switching, beam-footprint update, or other mobility event. It
remains in a Non-Effective State until the Protected Enforcement
Domain validates ephemeris and coverage state, feeder- or service-
link authority, terrestrial interworking authority, security
association, policy epoch, descriptor binding, freshness, and
revocation state; commits the required protected validation evidence;
and permits scoped non-bearer authority bound to the Candidate Act
and the intended sink. The Finality Sink is the NTN mobility
Das Expires 18 March 2027 [Page 27]
Internet-Draft LEO/NTN Orbital Finality September 2026
function, gateway switch, payload controller, feeder- or service-link
controller, beam controller, or protected effectuation component.
The handover or re-entry remains non-effective when the current
authority state does not match the Candidate Act.
*Relationship to existing technology.* This profile complements 3GPP
NTN mobility and interworking procedures rather than redefining them.
Where an existing mechanism already guarantees the same non-
bypassable consequence-bound property, that mechanism is invited as a
technical correction or equivalence reference.
10.1.4. Profile 4: Beam-Footprint and Jurisdiction-Mapping Finality
*Problem space.* Beam geometry and satellite motion can change the
set of geographic or jurisdictional regions affected by an otherwise
valid radio operation. A previously acceptable beam decision can
therefore become stale before radiation.
*Execution-finality solution.* The Candidate Act is activation,
steering, retargeting, or footprint modification of an NTN or
satellite beam. It remains in a Non-Effective State until the
Protected Enforcement Domain validates current orbital and beam
state, terminal or coverage state, jurisdiction mapping, spectrum
policy, permitted service area, policy epoch, freshness, and
revocation state; commits the required protected validation evidence;
and permits scoped non-bearer authority bound to the Candidate Act
and the intended sink. The Finality Sink is the beam controller,
phase-shifter array controller, RF-chain enable point, power-
amplifier bias gate, or equivalent radiative boundary. No RF or beam
effect occurs when the bound beam, geographic scope, or policy state
no longer validates.
*Relationship to existing technology.* Radio resource and beamforming
procedures remain a 3GPP or implementation matter; this profile
addresses authority immediately before the physical effect. Where an
existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
10.1.5. Profile 5: Gateway, Feeder-Link, and Service-Link Effectuation
Finality
*Problem space.* Gateway authorization, service-link state, feeder-
link state, and routing decisions can be valid independently, yet the
combined operation may cross an operator, security, mission, or
sovereign boundary.
Das Expires 18 March 2027 [Page 28]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is feeder-link
transmission, service-link transmission, gateway switching, satellite
relay, or payload forwarding. It remains in a Non-Effective State
until the Protected Enforcement Domain validates gateway identity and
authorization, link authorization, route authority, policy epoch,
security association, freshness, revocation, and descriptor binding;
commits the required protected validation evidence; and permits
scoped non-bearer authority bound to the Candidate Act and the
intended sink. The Finality Sink is the feeder-link controller,
service-link controller, gateway switch, payload routing component,
earth station, or protected link-effectuation interface. The link
operation is denied or retained in a non-effective state until the
exact link and gateway scope validates.
*Relationship to existing technology.* Existing link and gateway
protocols provide connectivity; the added property is consequence-
bound release. Where an existing mechanism already guarantees the
same non-bypassable consequence-bound property, that mechanism is
invited as a technical correction or equivalence reference.
10.2. Orbital AI, Model State, Earth Observation, and Compute Profiles
10.2.1. Profile 6: Orbital AI Inference-Output Release Finality
*Problem space.* An onboard GPU, NPU, tensor accelerator, inference
engine, or AI payload may successfully produce an output even though
current authority to release that output to a destination is absent,
stale, revoked, or narrower than the computation authority.
*Execution-finality solution.* The Candidate Act is release, storage,
routing, downlink, external API publication, or downstream delivery
of an orbital inference output. It remains in a Non-Effective State
until the Protected Enforcement Domain validates satellite, payload,
accelerator, model and session identity; model version or checkpoint;
input and output classes; destination; mission state; provenance;
policy epoch; freshness; and revocation state; commits the required
protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the onboard output buffer, payload release gate,
storage-commit interface, RF or optical downlink, ISL interface,
ground delivery interface, orbital-cloud API, or destination
admission interface. Successful inference does not itself cause
output release.
Das Expires 18 March 2027 [Page 29]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Relationship to existing technology.* RATS-style attestation can
provide execution evidence; this profile treats that evidence as an
input to an act-bound release decision. Where an existing mechanism
already guarantees the same non-bypassable consequence-bound
property, that mechanism is invited as a technical correction or
equivalence reference.
10.2.2. Profile 7: Ground-Station and Orbital-Cloud API Response
Finality
*Problem space.* A satellite or orbital-cloud service can
successfully compute a response while the response destination,
caller scope, data class, service state, or terrestrial admission
authority does not permit disclosure.
*Execution-finality solution.* The Candidate Act is generation,
return, relay, publication, or delivery of a response from an orbital
cloud, satellite API, ground-station relay API, payload service, or
inference endpoint. It remains in a Non-Effective State until the
Protected Enforcement Domain validates service and caller scope,
output class, destination, applicable routing and policy state,
freshness, revocation, and protected response-binding state; commits
the required protected validation evidence; and permits scoped non-
bearer authority bound to the Candidate Act and the intended sink.
The Finality Sink is the API response gate, relay or gateway output,
RF or optical downlink, ISL, terrestrial cloud ingress, or
destination admission interface. The API operation can complete
internally while the response remains non-effective externally.
*Relationship to existing technology.* HTTP or service authentication
can identify endpoints; execution finality determines whether the
particular response may cross the release boundary. Where an
existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
10.2.3. Profile 8: Space-to-Earth AI Sovereign Handoff Finality
*Problem space.* Orbital AI processing can occur outside the
jurisdiction in which an inference result, model state, or processed
data will eventually be used. Link security does not itself settle
whether the terrestrial destination may ingest the result.
*Execution-finality solution.* The Candidate Act is terrestrial
handoff of an AI inference result, model weight, gradient, or
processed data product. It remains in a Non-Effective State until
the Protected Enforcement Domain validates orbital-compute identity
or attestation, destination sovereign policy, data-residency or
Das Expires 18 March 2027 [Page 30]
Internet-Draft LEO/NTN Orbital Finality September 2026
ingestion scope, route and gateway, policy epoch, revocation epoch,
nonce, and freshness; commits the required protected validation
evidence; and permits scoped non-bearer authority bound to the
Candidate Act and the intended sink. The Finality Sink is the
satellite-gateway inference-ingestion boundary, space-to-earth
receiver output, protected terrestrial handoff, or destination
admission gate. The result cannot be admitted, stored, exposed,
routed onward, or applied unless the handoff authority validates.
*Relationship to existing technology.* This profile is complementary
to RATS and NTN routing: trustworthy source state and a valid path
are predicates, not the final release decision. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
10.2.4. Profile 9: Inter-Satellite Tensor Transfer Finality
*Problem space.* Intermediate tensor, activation, embedding, or
hidden-state data can be technically routable between satellites even
when the destination workload, mission, tenant, route, or transfer
window is not authorized for that state.
*Execution-finality solution.* The Candidate Act is transfer,
routing, replication, sharding, synchronization, migration, or
delivery of tensor or activation state over an inter-satellite link.
It remains in a Non-Effective State until the Protected Enforcement
Domain validates source and destination satellite identity, link
endpoint, tensor class, model and workload identity, partition,
transfer window, permitted route, tenant or mission scope, freshness,
revocation, and receipt-chain state; commits the required protected
validation evidence; and permits scoped non-bearer authority bound to
the Candidate Act and the intended sink. The Finality Sink is the
optical terminal, RF ISL modem, tensor serializer, routing
controller, destination tensor-ingress gate, or orbital compute-
fabric interface. The intermediate state remains non-effective at
the destination when the exact transfer scope fails validation.
*Relationship to existing technology.* Optical or RF ISL protocols
establish transport; this profile governs admission of the specific
AI state carried by that transport. Where an existing mechanism
already guarantees the same non-bypassable consequence-bound
property, that mechanism is invited as a technical correction or
equivalence reference.
Das Expires 18 March 2027 [Page 31]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.2.5. Profile 10: Inter-Satellite KV-Cache and Hidden-State Finality
*Problem space.* Distributed inference may move key-value cache,
hidden state, embeddings, or other model context between orbital
nodes. Such state can disclose context or expand execution authority
if accepted outside its bound workload or mission.
*Execution-finality solution.* The Candidate Act is delivery or
migration of KV cache, hidden state, embeddings, activation state, or
intermediate AI context to another orbital compute node. It remains
in a Non-Effective State until the Protected Enforcement Domain
validates source workload, destination workload, model version,
session or partition, tenant and mission isolation, route, transfer
window, freshness, revocation, and destination admission state;
commits the required protected validation evidence; and permits
scoped non-bearer authority bound to the Candidate Act and the
intended sink. The Finality Sink is the model-state transfer gate,
destination tensor or context ingress, accelerator admission
boundary, or orbital compute-fabric interface. Possession of
transported context does not by itself make that context admissible
to the receiving model or accelerator.
*Relationship to existing technology.* This is an application-state
admission profile layered above the underlying inter-satellite
transport. Where an existing mechanism already guarantees the same
non-bypassable consequence-bound property, that mechanism is invited
as a technical correction or equivalence reference.
10.2.6. Profile 11: Orbital Model-Weight and Checkpoint Migration
Finality
*Problem space.* Model weights, checkpoints, optimizer state, and
adapter state may need to move between orbital nodes for resilience
or distributed compute. A technically valid transfer can still
target an unauthorized model, partition, tenant, or mission.
Das Expires 18 March 2027 [Page 32]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is replication,
synchronization, migration, or delivery of model weights,
checkpoints, optimizer state, adapter state, or other model state
between satellites. It remains in a Non-Effective State until the
Protected Enforcement Domain validates source and destination
identity, model and version, checkpoint digest, partition and
workload scope, route, transfer window, destination admission,
freshness, revocation, and protected receipt-chain state; commits the
required protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the model-state serializer, ISL egress, destination
model-store ingress, accelerator admission gate, or orbital compute-
fabric interface. Transferred model state cannot become active or
accepted at the destination without matching authority.
*Relationship to existing technology.* The profile does not replace
model distribution or storage protocols; it adds destination-bound
activation/admission finality. Where an existing mechanism already
guarantees the same non-bypassable consequence-bound property, that
mechanism is invited as a technical correction or equivalence
reference.
10.2.7. Profile 12: Orbital Training-Shard and Gradient-Release
Finality
*Problem space.* Distributed or federated orbital learning can create
gradients, model deltas, training shards, optimizer updates, or
learned representations that are technically transferable before
their provenance, privacy, mission, or aggregation scope has been
established.
*Execution-finality solution.* The Candidate Act is release,
aggregation, transmission, storage, synchronization, or admission of
a training shard, gradient, model delta, federated-learning update,
optimizer update, or learned representation. It remains in a Non-
Effective State until the Protected Enforcement Domain validates
training job and model identity, source and destination, data and
update class, provenance, privacy or no-raw-export conditions,
aggregation scope, poisoning or anomaly state, freshness, and
revocation; commits the required protected validation evidence; and
permits scoped non-bearer authority bound to the Candidate Act and
the intended sink. The Finality Sink is the gradient or model-delta
release gate, orbital or ground aggregator ingress, ISL, downlink,
training commit, or model-update interface. A computed training
contribution remains non-effective until its release and aggregation
scope validates.
Das Expires 18 March 2027 [Page 33]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Relationship to existing technology.* Federated-learning algorithms
determine how updates are computed; execution finality determines
whether the particular update may leave or enter a protected training
boundary. Where an existing mechanism already guarantees the same
non-bypassable consequence-bound property, that mechanism is invited
as a technical correction or equivalence reference.
10.2.8. Profile 13: Satellite LoRA and Adapter-Update Activation
Finality
*Problem space.* A low-rank adaptation or other adapter can be
validly stored or transmitted yet unauthorized for a particular
satellite, mission, tenant, model, runtime, or time window.
*Execution-finality solution.* The Candidate Act is generation,
loading, transmission, admission, merge, activation, application,
export, revocation, or disabling of a LoRA or other model adapter.
It remains in a Non-Effective State until the Protected Enforcement
Domain validates adapter identity and digest, base-model identity,
mission or tenant scope, destination runtime, activation or merge
scope, policy epoch, freshness, revocation, and protected update
state; commits the required protected validation evidence; and
permits scoped non-bearer authority bound to the Candidate Act and
the intended sink. The Finality Sink is the adapter release gate,
model-store ingress, merge gate, runtime admission point, parameter-
update interface, ISL, or ground aggregator. The adapter cannot
alter effective model behavior merely because the artifact is present
or cryptographically valid.
*Relationship to existing technology.* Software-update or model-
management mechanisms remain responsible for distribution; this
profile adds bounded model-behavior activation. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
10.2.9. Profile 14: Sensor-Origin Provenance Admission Finality
*Problem space.* Earth-observation, RF, optical, SAR, hyperspectral,
thermal, maritime, weather, or telemetry data may be authentic yet
unsuitable for a particular model-update, training, aggregation, or
downstream-use scope.
*Execution-finality solution.* The Candidate Act is admission or use
of sensor-origin data, features, or derived representations in
training, model update, aggregation, storage, downlink, or runtime
processing. It remains in a Non-Effective State until the Protected
Enforcement Domain validates sensor identity and origin, capture
Das Expires 18 March 2027 [Page 34]
Internet-Draft LEO/NTN Orbital Finality September 2026
time, spatial region, data class, model identity, permitted use,
provenance chain, policy epoch, freshness, and revocation; commits
the required protected validation evidence; and permits scoped non-
bearer authority bound to the Candidate Act and the intended sink.
The Finality Sink is the sensor-data admission gate, feature ingress,
training or model-update boundary, product-release gate, store,
downlink, or ground aggregator. Authentic sensor data remains non-
effective for the new use until provenance and permitted-use
predicates validate.
*Relationship to existing technology.* Provenance mechanisms provide
evidence; this profile binds that evidence to a concrete admission or
release consequence. Where an existing mechanism already guarantees
the same non-bypassable consequence-bound property, that mechanism is
invited as a technical correction or equivalence reference.
10.2.10. Profile 15: Poisoning-Risk and Quarantine Finality
*Problem space.* A training contribution, gradient, sensor feature,
checkpoint, adapter, or model delta may exhibit poisoning, anomaly,
drift, adversarial, Byzantine, or compromised-source indicators after
it has already entered an orbital learning workflow.
*Execution-finality solution.* The Candidate Act is admission,
exclusion, quarantine, unquarantine, down-weighting, rejection,
retraining, storage, transmission, aggregation, or merge of a suspect
contribution. It remains in a Non-Effective State until the
Protected Enforcement Domain validates source and contribution
identity, anomaly or poisoning evidence, quarantine state, permitted
weighting or use, model and training scope, policy epoch, freshness,
and revocation; commits the required protected validation evidence;
and permits scoped non-bearer authority bound to the Candidate Act
and the intended sink. The Finality Sink is the training-admission
gate, quarantine store, gradient or model-update gate, adapter merge,
model store, downlink, or ground-aggregator interface. Suspect state
cannot become effective in a model update merely because processing
has completed.
*Relationship to existing technology.* Detection systems can supply
risk evidence; execution finality governs whether the flagged
artifact crosses the model-update consequence boundary. Where an
existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
Das Expires 18 March 2027 [Page 35]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.2.11. Profile 16: Ground-Aggregator Model-Update Admission Finality
*Problem space.* A terrestrial aggregator may receive multiple valid
orbital updates whose provenance, quarantine status, aggregation
policy, merge scope, or destination model do not all authorize
application to the ground model.
*Execution-finality solution.* The Candidate Act is admission,
aggregation, merge, application, storage, routing, rejection, or
publication of orbital model updates at a ground or cloud
coordinator. It remains in a Non-Effective State until the Protected
Enforcement Domain validates source provenance receipts, poisoning
and quarantine receipts, aggregation policy, model and checkpoint
identity, merge scope, destination runtime, policy epoch, freshness,
and revocation; commits the required protected validation evidence;
and permits scoped non-bearer authority bound to the Candidate Act
and the intended sink. The Finality Sink is the ground aggregator,
federated-learning aggregation boundary, model or adapter merge gate,
model registry, checkpoint store, or serving-runtime admission point.
Receipt of an update does not make the update effective in the
terrestrial model.
*Relationship to existing technology.* The profile complements
federated aggregation and model registries by adding a final act-
bound admission check. Where an existing mechanism already
guarantees the same non-bypassable consequence-bound property, that
mechanism is invited as a technical correction or equivalence
reference.
10.2.12. Profile 17: Earth-Observation AI Product Release Finality
*Problem space.* An Earth-observation AI system may validly derive a
geospatial or sensor product while disclosure is restricted by
spatial region, resolution, recipient, purpose, embargo, mission, or
emergency conditions.
Das Expires 18 March 2027 [Page 36]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is release,
downlink, publication, storage, API delivery, marketplace delivery,
or emergency delivery of an Earth-observation AI product. It remains
in a Non-Effective State until the Protected Enforcement Domain
validates sensor provenance, observation time, spatial region,
resolution, product and model identity, destination, purpose,
restricted-area or embargo state, policy epoch, freshness, and
revocation; commits the required protected validation evidence; and
permits scoped non-bearer authority bound to the Candidate Act and
the intended sink. The Finality Sink is the product-release gate,
satellite store, API, RF or optical downlink, marketplace interface,
emergency delivery interface, or destination admission gate. A
successfully generated geospatial product remains non-effective until
the permitted release scope is validated.
*Relationship to existing technology.* This profile does not define
Earth-observation policy; it supplies a boundary at which machine-
verifiable release policy can be enforced. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
10.2.13. Profile 18: Earth-Observation Resolution and Purpose-Bounded
Disclosure Finality
*Problem space.* The same Earth-observation source can support
outputs at different resolution, geographic coverage, or purpose. A
general authorization to process imagery does not necessarily
authorize every derived precision or recipient.
*Execution-finality solution.* The Candidate Act is release of an EO-
derived output at a particular resolution, region, product class,
destination, or use purpose. It remains in a Non-Effective State
until the Protected Enforcement Domain validates source provenance,
observation and region binding, permitted resolution or product
class, purpose and destination scope, restricted-area state,
freshness, and revocation; commits the required protected validation
evidence; and permits scoped non-bearer authority bound to the
Candidate Act and the intended sink. The Finality Sink is the
product formatter or release gate, API output, store commit, downlink
interface, marketplace boundary, or destination admission point. The
system can compute a higher-resolution or differently purposed result
without making that result externally releasable.
Das Expires 18 March 2027 [Page 37]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Relationship to existing technology.* This is a precision- and
purpose-bound specialization of the EO release profile rather than a
replacement for sensor or analytics standards. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
10.2.14. Profile 19: Solar-Power, Battery, Thermal-Window, and Compute-
Scheduling Finality
*Problem space.* Orbital compute availability varies with solar
generation, battery state, eclipse, thermal conditions, radiation
state, communications windows, payload duty cycle, and mission
priority. A queued workload can be computationally valid but unsafe
or unauthorized to launch under the current resource state.
*Execution-finality solution.* The Candidate Act is scheduling,
activation, throttling, suspension, migration, prioritization, or
allocation of an onboard AI or general compute workload. It remains
in a Non-Effective State until the Protected Enforcement Domain
validates workload identity, requested compute window, power and
battery state, thermal state, eclipse state, communication window,
mission priority, affected subsystem, quota, policy epoch, freshness,
and revocation; commits the required protected validation evidence;
and permits scoped non-bearer authority bound to the Candidate Act
and the intended sink. The Finality Sink is the workload-admission
point, accelerator scheduler, payload compute allocator, power
controller, thermal controller, accelerator partition, clock-enable,
or reset-release boundary. The workload remains non-effective with
respect to high-energy compute when the authorized resource envelope
is unavailable.
*Relationship to existing technology.* Existing schedulers optimize
resources; execution finality makes the permission to consume the
bounded resource state explicit. Where an existing mechanism already
guarantees the same non-bypassable consequence-bound property, that
mechanism is invited as a technical correction or equivalence
reference.
10.2.15. Profile 20: Power-Budgeted Orbital Compute Admission Finality
*Problem space.* An orbital workload can pass ordinary scheduling
checks yet exceed the power, battery, thermal, or mission budget that
is currently authorized for that workload class.
*Execution-finality solution.* The Candidate Act is admission or
continuation of a compute job that would consume protected processor,
GPU, NPU, memory, or payload energy resources. It remains in a Non-
Das Expires 18 March 2027 [Page 38]
Internet-Draft LEO/NTN Orbital Finality September 2026
Effective State until the Protected Enforcement Domain validates
workload and accelerator identity, authorized compute window, power
or battery envelope, thermal limit, mission priority, quota or
counter state, policy epoch, freshness, and revocation; commits the
required protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the compute-job launch gate, accelerator scheduler,
power-domain enable, thermal controller, payload compute allocator,
or accelerator partition admission boundary. The expensive compute
path is not entered, or is bounded or suspended, when the current
resource authority is absent or exhausted.
*Relationship to existing technology.* This profile is about
authority to consume orbital compute resources; it does not replace
energy-efficiency scheduling algorithms. Where an existing mechanism
already guarantees the same non-bypassable consequence-bound
property, that mechanism is invited as a technical correction or
equivalence reference.
10.2.16. Profile 21: Accelerator Launch, Partition, and Clock-Enable
Finality
*Problem space.* Low-level accelerator enablement can make a prepared
workload physically effective before higher-layer software notices
that mission, quota, thermal, or resource authority has changed.
*Execution-finality solution.* The Candidate Act is launch of an
accelerator job, enablement of an accelerator partition, release from
reset, or clock/power enablement for a bounded compute operation. It
remains in a Non-Effective State until the Protected Enforcement
Domain validates workload, accelerator and partition identity,
mission priority, resource and thermal state, allowed compute window,
quota, policy epoch, freshness, and revocation; commits the required
protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the accelerator job-launch interface, partition-
admission point, reset-release gate, clock-enable boundary, power
controller, or protected scheduler. A prepared job does not become
hardware-effective unless the final bound state still validates at
launch.
*Relationship to existing technology.* The profile places finality
below or alongside the software scheduler where necessary; it does
not prescribe a particular accelerator ISA or vendor design. Where
an existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
Das Expires 18 March 2027 [Page 39]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.3. Spacecraft Hardware, Radiation, Memory, and Recovery Profiles
10.3.1. Profile 22: Single-Event-Upset Evidence and Recovery Finality
*Problem space.* Radiation or a single-event upset can transiently
corrupt processor, memory, accelerator, payload, or control state.
Error detection or correction may indicate recovery without proving
that every downstream consequence is safe to resume.
*Execution-finality solution.* The Candidate Act is release,
activation, continuation, reset, recovery, rollback, quarantine exit,
or output use following an SEU or related transient fault. It
remains in a Non-Effective State until the Protected Enforcement
Domain validates fault evidence, affected subsystem identity,
corrected or recovered state, recovery mode, dependency evidence,
policy epoch, freshness, revocation, and protected recovery state;
commits the required protected validation evidence; and permits
scoped non-bearer authority bound to the Candidate Act and the
intended sink. The Finality Sink is the reset-release gate,
corrected-memory release, payload or accelerator output, command-
continuation gate, safe-mode exit, telemetry release, or recovery
activation boundary. Recovery processing may complete while the
affected subsystem remains non-effective until recovery authority
validates.
*Relationship to existing technology.* Spacecraft FDIR remains
responsible for detecting and responding to faults; execution
finality governs consequential re-entry or release. Where an
existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
10.3.2. Profile 23: ECC Scrub and Memory-Integrity Epoch Finality
*Problem space.* ECC checks, scrubbing, refresh, repair, or radiation
correction can produce a memory region that appears usable while its
integrity epoch, affected data scope, downstream consumer, or
recovery policy remains unresolved.
*Execution-finality solution.* The Candidate Act is use, release,
migration, checkpointing, mirroring, externalization, or downstream
processing of memory after an integrity or scrub event. It remains
in a Non-Effective State until the Protected Enforcement Domain
validates memory region and technology, integrity or correction
evidence, memory epoch, affected workload or model state,
destination, policy epoch, freshness, revocation, and protected
state; commits the required protected validation evidence; and
permits scoped non-bearer authority bound to the Candidate Act and
Das Expires 18 March 2027 [Page 40]
Internet-Draft LEO/NTN Orbital Finality September 2026
the intended sink. The Finality Sink is the memory read or write
gate, cache or HBM aperture, checkpoint commit, DMA release,
accelerator memory admission, payload memory release, or external
egress boundary. Corrected memory is not automatically authorized
for every downstream use.
*Relationship to existing technology.* ECC and scrub mechanisms
detect or repair errors; the profile determines when corrected state
may regain consequential use. Where an existing mechanism already
guarantees the same non-bypassable consequence-bound property, that
mechanism is invited as a technical correction or equivalence
reference.
10.3.3. Profile 24: Post-Scrub Checkpoint and Memory-Externalization
Finality
*Problem space.* A corrected memory image, checkpoint, mirrored
buffer, or recovered model state may be internally usable while
externalization would propagate an uncertain or wrong recovery epoch
to another subsystem or node.
*Execution-finality solution.* The Candidate Act is checkpoint
commit, memory mirroring, migration, DMA release, storage
externalization, or model-state export after memory correction. It
remains in a Non-Effective State until the Protected Enforcement
Domain validates memory-integrity epoch, affected region, checkpoint
or buffer identity, destination, dependency receipts, recovery state,
freshness, and revocation; commits the required protected validation
evidence; and permits scoped non-bearer authority bound to the
Candidate Act and the intended sink. The Finality Sink is the
checkpoint-commit gate, DMA boundary, model-state export gate,
external memory egress, accelerator ingress, or payload release
interface. Recovered state remains local or quarantined until the
exact externalization act validates.
*Relationship to existing technology.* This is a propagation-control
specialization of memory-integrity finality. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
10.3.4. Profile 25: Triple-Modular-Redundancy and Redundant-Vote
Finality
*Problem space.* A TMR, DMR, majority vote, redundant processor,
sensor, accelerator, or payload controller may produce a selected
result even when vote confidence, voter health, mission policy, or
downstream effect authority is insufficient.
Das Expires 18 March 2027 [Page 41]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is acceptance,
release, commitment, transmission, or actuation based on a redundant
vote or selected redundant result. It remains in a Non-Effective
State until the Protected Enforcement Domain validates redundant-
source identities, vote or disagreement state, health evidence,
selected output, mission and safety scope, policy epoch, freshness,
and revocation; commits the required protected validation evidence;
and permits scoped non-bearer authority bound to the Candidate Act
and the intended sink. The Finality Sink is the voted-output release
gate, command commit, payload-control boundary, actuator enable, RF
or optical output, reset-release gate, safe-mode transition, or
telemetry release. The selected vote result is not automatically
allowed to cause the downstream effect.
*Relationship to existing technology.* Redundancy mechanisms
determine a selected result; execution finality determines whether
that result may be acted upon. Where an existing mechanism already
guarantees the same non-bypassable consequence-bound property, that
mechanism is invited as a technical correction or equivalence
reference.
10.3.5. Profile 26: Latch-Up, Overcurrent, and Subsystem Re-Enable
Finality
*Problem space.* A latch-up, overcurrent, thermal event, or
radiation-induced current anomaly can force isolation or power
cycling. Removal of the electrical fault does not necessarily
establish authority to restart the affected subsystem.
*Execution-finality solution.* The Candidate Act is continuation,
disablement, reset, power-cycle, isolation, throttling, restart, or
re-enablement of an affected subsystem. It remains in a Non-
Effective State until the Protected Enforcement Domain validates
fault and current evidence, affected subsystem, power and thermal
state, isolation state, recovery scope, dependency state, policy
epoch, freshness, and revocation; commits the required protected
validation evidence; and permits scoped non-bearer authority bound to
the Candidate Act and the intended sink. The Finality Sink is the
power switch, current limiter, reset gate, clock gate, isolation
control, safe-mode gate, payload enable, RF or optical enable, or
accelerator enable boundary. Re-enablement fails closed until the
recovered electrical and mission state validates.
Das Expires 18 March 2027 [Page 42]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Relationship to existing technology.* Electrical protection and FDIR
detect and isolate faults; this profile governs the consequence of
returning the subsystem to service. Where an existing mechanism
already guarantees the same non-bypassable consequence-bound
property, that mechanism is invited as a technical correction or
equivalence reference.
10.3.6. Profile 27: Safe-Mode Exit and Operational Re-Entry Finality
*Problem space.* Safe mode intentionally suppresses normal spacecraft
functions. A command to leave safe mode can be authenticated and
technically executable while dependency, fault, mission, or
authorization state is still unsuitable for operational re-entry.
*Execution-finality solution.* The Candidate Act is safe-mode exit,
subsystem activation, reset release, processor execution, payload re-
enable, or return to operational mode. It remains in a Non-Effective
State until the Protected Enforcement Domain validates safe-mode and
fault evidence, recovery image or subsystem state, dependency
receipts, mission state, override authority where applicable, policy
epoch, freshness, and revocation; commits the required protected
validation evidence; and permits scoped non-bearer authority bound to
the Candidate Act and the intended sink. The Finality Sink is the
safe-mode exit gate, reset-release gate, processor execution gate,
payload enable, memory admission, or subsystem activation boundary.
Operational effects remain blocked even after a valid command unless
re-entry predicates validate.
*Relationship to existing technology.* Spacecraft safe-mode
procedures remain unchanged; the profile supplies an explicit final
gate for effectuation. Where an existing mechanism already
guarantees the same non-bypassable consequence-bound property, that
mechanism is invited as a technical correction or equivalence
reference.
10.3.7. Profile 28: Radiation-Degraded Output Release Finality
*Problem space.* A spacecraft may continue operating in a degraded
radiation or component-health state and produce useful but lower-
confidence outputs. Treating all such outputs as either fully
trusted or fully unavailable can be operationally undesirable.
*Execution-finality solution.* The Candidate Act is release, use,
downlink, storage, or downstream application of output produced under
a declared degraded state. It remains in a Non-Effective State until
the Protected Enforcement Domain validates affected subsystem and
degradation evidence, output class, confidence or quality metric,
model or computation identity, destination, permitted degraded mode,
Das Expires 18 March 2027 [Page 43]
Internet-Draft LEO/NTN Orbital Finality September 2026
mission-risk state, policy epoch, freshness, and revocation; commits
the required protected validation evidence; and permits scoped non-
bearer authority bound to the Candidate Act and the intended sink.
The Finality Sink is the output or data-release gate, inference-
output gate, sensor-product gate, telemetry gate, RF or optical
downlink, payload-control interface, or destination admission gate.
Only outputs within the explicitly permitted degradation and
confidence scope become effective.
*Relationship to existing technology.* Fault detection supplies
degradation evidence; the finality layer binds that evidence to the
exact output and destination. Where an existing mechanism already
guarantees the same non-bypassable consequence-bound property, that
mechanism is invited as a technical correction or equivalence
reference.
10.3.8. Profile 29: Post-Radiation Boot, Recovery-Image, and Rollback
Finality
*Problem space.* After radiation, watchdog reset, memory fault, safe-
mode entry, latch-up isolation, or chiplet anomaly, a subsystem may
have multiple boot or rollback choices. Cryptographic image validity
alone does not determine whether the chosen recovery path is
presently authorized.
*Execution-finality solution.* The Candidate Act is boot, restart,
restore, rollback, reinitialization, re-enable, or transition to
operational mode. It remains in a Non-Effective State until the
Protected Enforcement Domain validates target subsystem, boot stage,
recovery image digest, rollback target, fault evidence, safe-mode
state, dependency receipts, anti-rollback state, policy epoch,
freshness, and revocation; commits the required protected validation
evidence; and permits scoped non-bearer authority bound to the
Candidate Act and the intended sink. The Finality Sink is the boot-
stage selector, recovery-image selector, rollback gate, reset-release
gate, safe-mode exit, processor execution, payload enable, memory
admission, or subsystem activation gate. No recovered image or
rollback target becomes operational unless the bound recovery act
validates.
*Relationship to existing technology.* Secure boot establishes image
integrity and provenance; this profile adds current recovery
authority and consequence-bound activation. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
Das Expires 18 March 2027 [Page 44]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.4. Optical and Inter-Satellite Network Profiles
10.4.1. Profile 30: Optical Inter-Satellite Link Establishment Finality
*Problem space.* Two satellites may be able to acquire, authenticate,
align, and form an optical crosslink while mission scope, endpoint
identity, link window, data class, power, or safety authority is not
valid for the particular connection.
*Execution-finality solution.* The Candidate Act is establishment,
activation, admission, alignment, authentication, routing,
transmission, reception, or maintenance of an optical ISL. It
remains in a Non-Effective State until the Protected Enforcement
Domain validates source and destination satellites, terminal and
laser identity, pointing and acquisition state, permitted link
window, data and mission scope, optical power or safety bound,
freshness, and revocation; commits the required protected validation
evidence; and permits scoped non-bearer authority bound to the
Candidate Act and the intended sink. The Finality Sink is the
optical terminal enable, laser-emission gate, pointing controller,
acquisition/tracking boundary, modem, serializer, receiver admission,
routing interface, or destination optical ingress. An available
optical link does not become operational for the Candidate Act until
its exact link authority validates.
*Relationship to existing technology.* CCAMP and optical-link work
can describe control and path properties; this profile addresses
release authority at the optical consequence boundary. Where an
existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
10.4.2. Profile 31: Optical Pointing, Acquisition, and Laser-Emission
Finality
*Problem space.* Acquisition and tracking can converge on a peer
before authority to emit laser energy, reserve the terminal, or
expose a particular data class has been established for that moment.
*Execution-finality solution.* The Candidate Act is laser emission,
pointing commitment, acquisition/tracking continuation, optical-
terminal activation, or data-bearing modulation. It remains in a
Non-Effective State until the Protected Enforcement Domain validates
peer identity, terminal and laser identity, pointing state,
acquisition state, link window, optical power and safety scope,
mission scope, freshness, and revocation; commits the required
protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Das Expires 18 March 2027 [Page 45]
Internet-Draft LEO/NTN Orbital Finality September 2026
Finality Sink is the laser-emission gate, optical-terminal enable,
beam-pointing controller, acquisition/tracking controller, or
modulator boundary. Pointing success alone cannot cause radiative
optical effect.
*Relationship to existing technology.* Physical-layer acquisition
remains unchanged; the finality layer supplies the authorization gate
immediately before emission or data-bearing use. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
10.4.3. Profile 32: Wavelength, Channel, and Optical Beam-Retune
Finality
*Problem space.* An established optical or RF link may permit
retuning of wavelength, channel, carrier, beam direction, divergence,
power, modulation, coding, polarization, or spatial channel. A
technically valid retune can alter interference, coverage, peer, or
mission scope.
*Execution-finality solution.* The Candidate Act is retuning,
hopping, allocation, redirection, or mutation of optical or RF
channel and beam parameters. It remains in a Non-Effective State
until the Protected Enforcement Domain validates link and terminal
identity, permitted wavelength or channel, peer, beam or pointing
scope, power, modulation or coding scope, mission state, policy
epoch, freshness, and revocation; commits the required protected
validation evidence; and permits scoped non-bearer authority bound to
the Candidate Act and the intended sink. The Finality Sink is the
wavelength selector, channel controller, beam-steering or power
controller, modulator, optical terminal, switch, router, or receiver
admission boundary. The new channel or beam state does not become
externally effective merely because hardware can retune.
*Relationship to existing technology.* Optical and radio control
protocols select parameters; finality binds the selected mutation to
present authority. Where an existing mechanism already guarantees
the same non-bypassable consequence-bound property, that mechanism is
invited as a technical correction or equivalence reference.
10.4.4. Profile 33: Partner-Constellation Admission and Attestation
Finality
*Problem space.* A partner, allied, commercial, hosted, or third-
party constellation may present valid identity or attestation
evidence while the current mission, operator, route, data-sharing,
jurisdiction, or traffic scope does not permit admission.
Das Expires 18 March 2027 [Page 46]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is admission,
establishment, routing, receipt, forwarding, synchronization, or
reliance on traffic, telemetry, tensor state, model state, or payload
data from a partner constellation. It remains in a Non-Effective
State until the Protected Enforcement Domain validates partner
identity and attestation, operator and constellation domain, traffic
or data class, mission and data-sharing scope, route and jurisdiction
state, freshness, and revocation; commits the required protected
validation evidence; and permits scoped non-bearer authority bound to
the Candidate Act and the intended sink. The Finality Sink is the
receive or transmit gate, routing or relay boundary, packet filter,
payload ingress, model-state ingress, or partner-service admission
point. Trustworthy partner identity does not become unrestricted
cross-constellation authority.
*Relationship to existing technology.* RATS can supply partner
evidence; execution finality binds that evidence to the exact cross-
constellation act. Where an existing mechanism already guarantees
the same non-bypassable consequence-bound property, that mechanism is
invited as a technical correction or equivalence reference.
10.4.5. Profile 34: Multi-Protocol Optical and Satellite Translation
Finality
*Problem space.* Gateways can translate, encapsulate, decapsulate,
tunnel, or bridge traffic between optical, RF, packet, circuit,
satellite, terrestrial, DTN, encrypted, or proprietary protocols.
Translation can unintentionally launder routing or egress authority
across protocol domains.
*Execution-finality solution.* The Candidate Act is translation,
encapsulation, decapsulation, bridging, conversion, tunneling,
mapping, or forwarding between protocol domains. It remains in a
Non-Effective State until the Protected Enforcement Domain validates
source and destination domains, traffic class, route and egress
scope, protocol translation class, no-protocol-laundering or no-
unauthorized-egress constraints, freshness, and revocation; commits
the required protected validation evidence; and permits scoped non-
bearer authority bound to the Candidate Act and the intended sink.
The Finality Sink is the translation engine, encapsulation or
decapsulation gate, router, regenerative forwarder, ISL, feeder link,
tunnel endpoint, packet egress, or destination admission interface.
Protocol conversion does not create new authority to cross an
otherwise prohibited consequence boundary.
Das Expires 18 March 2027 [Page 47]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Relationship to existing technology.* The profile leaves protocol
semantics intact and adds cross-domain authority preservation. Where
an existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
10.4.6. Profile 35: Optical Mesh Route and Jurisdiction-Corridor
Finality
*Problem space.* A dynamic optical satellite mesh may offer multiple
technically valid multi-hop paths, some of which traverse disallowed
operators, ground exits, sovereign corridors, or mission domains.
*Execution-finality solution.* The Candidate Act is selection,
activation, modification, rerouting, or use of an optical mesh path
or jurisdiction-constrained corridor. It remains in a Non-Effective
State until the Protected Enforcement Domain validates route and
relay identities, jurisdiction and partner scope, traffic and data
class, permitted corridor, prohibited ground-egress state, route
freshness, policy epoch, and revocation; commits the required
protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the route-commit point, routing controller, optical
switch, relay gate, feeder link, ground gateway, or destination
admission interface. A route being reachable or optimal is
insufficient if the exact path is not authorized for the Candidate
Act.
*Relationship to existing technology.* TVR can provide time-varying
path information; execution finality consumes such state when
deciding whether the selected path may become effective. Where an
existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
10.5. NTN, RAN, Direct-to-Device, DTN, and Emergency-Service Profiles
10.5.1. Profile 36: Onboard gNB and AI-RAN Scheduler Finality
*Problem space.* An onboard gNB, regenerative payload, NTN scheduler,
or AI-native RAN scheduler can compute a valid allocation while
bearer, terminal, mission, emergency, beam, QoS, or resource
authority is absent or stale.
*Execution-finality solution.* The Candidate Act is scheduling,
admission, prioritization, or allocation of a bearer, PRB, beam,
time-frequency resource, random access opportunity, QoS treatment,
emergency resource, or D2D/NTN service. It remains in a Non-
Das Expires 18 March 2027 [Page 48]
Internet-Draft LEO/NTN Orbital Finality September 2026
Effective State until the Protected Enforcement Domain validates
terminal and service identity, bearer and QoS scope, beam and service
area, resource budget, mission or emergency class, policy epoch,
freshness, and revocation; commits the required protected validation
evidence; and permits scoped non-bearer authority bound to the
Candidate Act and the intended sink. The Finality Sink is the gNB or
MAC scheduler, bearer-admission gate, beam-resource allocator, RRC
boundary, RF-chain enable, D2D admission, emergency admission, or UE
service gate. A scheduler decision remains a Candidate Act until the
bounded radio consequence is authorized.
*Relationship to existing technology.* 3GPP specifies RAN procedures;
this profile adds an execution-authority boundary and does not
propose a replacement scheduler. Where an existing mechanism already
guarantees the same non-bypassable consequence-bound property, that
mechanism is invited as a technical correction or equivalence
reference.
10.5.2. Profile 37: Satellite UPF-Like User-Plane Forwarding Finality
*Problem space.* An onboard packet core, regenerative payload, NTN
user-plane gateway, or UPF-like element can possess valid forwarding
state while a particular flow, tunnel, mirror, steer, or egress
operation lacks current authority.
*Execution-finality solution.* The Candidate Act is forwarding,
routing, tunneling, filtering, dropping, mirroring, steering,
buffering, or admission of user, application, emergency, sensor, AI,
telemetry, D2D, ISL, feeder, or ground traffic. It remains in a Non-
Effective State until the Protected Enforcement Domain validates flow
and service identity, tunnel or path scope, traffic class,
destination, slice or mission context, policy epoch, freshness,
revocation, and protected forwarding state; commits the required
protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the user-plane forwarding gate, packet output,
tunnel interface, route commit, ISL, feeder link, ground egress,
application ingress, or destination admission boundary. Installed
forwarding state alone cannot cause the specific packet or flow
consequence.
*Relationship to existing technology.* Routing and forwarding
protocols retain their normal role; finality adds per-act or per-
bounded-flow effectuation authority. Where an existing mechanism
already guarantees the same non-bypassable consequence-bound
property, that mechanism is invited as a technical correction or
equivalence reference.
Das Expires 18 March 2027 [Page 49]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.5.3. Profile 38: UE-Satellite-UE and Direct-to-Device Relay Finality
*Problem space.* Direct-to-device or UE-satellite-UE relay can
provide life-critical connectivity while also creating a path that
bypasses ordinary terrestrial policy or operator controls.
*Execution-finality solution.* The Candidate Act is establishment,
admission, routing, maintenance, or relay of D2D, direct-to-device,
emergency, disaster, roaming, or local NTN traffic. It remains in a
Non-Effective State until the Protected Enforcement Domain validates
source and destination UE scope, service and emergency class, relay
and beam identity, geographic or service area, duration or quota,
policy epoch, freshness, and revocation; commits the required
protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the relay-admission gate, onboard gNB relay, UE-to-
UE bearer, regenerative forwarder, beam scheduler, D2D gate, packet
output, or destination UE admission point. The relay remains
unavailable outside the explicitly permitted service, duration, and
endpoint scope.
*Relationship to existing technology.* This profile is complementary
to 3GPP D2D/NTN service procedures and focuses on bounded relay
effectuation. Where an existing mechanism already guarantees the
same non-bypassable consequence-bound property, that mechanism is
invited as a technical correction or equivalence reference.
10.5.4. Profile 39: NTN Network-Slice Admission and Mutation Finality
*Problem space.* Creating or modifying an NTN slice can reallocate
scarce compute, radio, routing, or mission resources and can cross
tenant boundaries even when the control request is authenticated.
*Execution-finality solution.* The Candidate Act is creation,
admission, activation, expansion, shrinkage, migration, merge, split,
prioritization, suspension, deletion, or resource reallocation of an
NTN slice. It remains in a Non-Effective State until the Protected
Enforcement Domain validates tenant and mission identity, slice and
service class, service area, QoS and resource scope, no-cross-tenant
constraints, policy epoch, freshness, and revocation; commits the
required protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the slice manager, gNB, UPF, QoS or resource
controller, network-function admission point, emergency service gate,
or service activation boundary. The slice mutation cannot become
network-effective unless its exact tenant, mission, and resource
scope validates.
Das Expires 18 March 2027 [Page 50]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Relationship to existing technology.* 3GPP slicing mechanisms define
slice behavior; finality governs whether the requested mutation may
take effect. Where an existing mechanism already guarantees the same
non-bypassable consequence-bound property, that mechanism is invited
as a technical correction or equivalence reference.
10.5.5. Profile 40: DTN Store-and-Forward Release Finality
*Problem space.* A bundle or stored object may be validly accepted
when created but remain queued through long disruption. By the time
connectivity returns, destination, route, custody, priority,
retention, policy, or revocation state may have changed.
*Execution-finality solution.* The Candidate Act is storage,
buffering, custody transfer, forwarding, release, retransmission,
prioritization, routing, or delivery of a delay-tolerant object. It
remains in a Non-Effective State until the Protected Enforcement
Domain validates object and destination identity, storage and
forwarding windows, expiration, priority, route or custody scope,
policy epoch, freshness at release, and revocation; commits the
required protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the storage commit, bundle admission, custody-
transfer boundary, retransmission or forwarding-release gate, ISL,
feeder link, ground egress, or destination admission point. Stored
validity is not treated as perpetual delivery authority.
*Relationship to existing technology.* BPv7 and DTN mechanisms
provide disrupted-network transport; execution finality adds
revalidation at the consequence-bearing release boundary. Where an
existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
10.5.6. Profile 41: Delayed Delivery Revocation and Revalidation
Finality
*Problem space.* Long store-and-forward intervals create a specific
time-of-check/time-of-use problem: an object that was authorized for
eventual delivery can outlive a revocation, route change, emergency
termination, or destination-policy change.
*Execution-finality solution.* The Candidate Act is release or
retransmission of previously accepted delayed traffic after a
connectivity or custody interval. It remains in a Non-Effective
State until the Protected Enforcement Domain validates original
authorization binding, current destination and route, expiration,
current policy and revocation epoch, custody state, replay state,
Das Expires 18 March 2027 [Page 51]
Internet-Draft LEO/NTN Orbital Finality September 2026
freshness, and any required new evidence; commits the required
protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the retransmission gate, forwarding-release
boundary, next-hop admission, ground or ISL egress, or final
destination ingress. Reappearance of connectivity does not
automatically reactivate stale delivery authority.
*Relationship to existing technology.* This profile is a DTN-specific
revalidation specialization and is intended for technical evaluation
against any existing BPv7/BPSec mechanism that already provides
equivalent non-bypassable semantics. Where an existing mechanism
already guarantees the same non-bypassable consequence-bound
property, that mechanism is invited as a technical correction or
equivalence reference.
10.5.7. Profile 42: Emergency Satellite Bearer Finality
*Problem space.* Emergency and public-safety services require rapid
access, but broad emergency authorization can become a standing
privilege if event, geography, endpoint, traffic, duration, or
priority scope is not enforced at effectuation.
*Execution-finality solution.* The Candidate Act is creation,
admission, maintenance, prioritization, transmission, or delivery of
an emergency, rescue, public-safety, D2D, voice, data, or mission-
critical satellite bearer. It remains in a Non-Effective State until
the Protected Enforcement Domain validates declared event, terminal
class, service area, priority, duration, traffic class, authorized
endpoints, quota, policy epoch, freshness, and revocation; commits
the required protected validation evidence; and permits scoped non-
bearer authority bound to the Candidate Act and the intended sink.
The Finality Sink is the emergency-bearer gate, gNB, beam scheduler,
D2D gate, RF-chain output, message output, UPF, UE admission, or
service-delivery boundary. Emergency authority remains bounded to
the actual event and service scope.
*Relationship to existing technology.* The profile does not define
emergency policy or priority rules; it supplies an effectuation
boundary for the rules selected by the operator or authority. Where
an existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
Das Expires 18 March 2027 [Page 52]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.5.8. Profile 43: Mass-Alert Broadcast Finality
*Problem space.* Public warning systems can reach large populations,
making a mistaken, replayed, geographically overbroad, or
unauthorized alert consequential even when the broadcast
infrastructure itself is functioning correctly.
*Execution-finality solution.* The Candidate Act is generation,
authorization, scheduling, transmission, repetition, geo-targeting,
expansion, limitation, or cancellation of a mass alert. It remains
in a Non-Effective State until the Protected Enforcement Domain
validates message identity and digest, event authority, geographic
region or beam, terminal class, transmission window, repetition
quota, policy epoch, freshness, and revocation; commits the required
protected validation evidence; and permits scoped non-bearer
authority bound to the Candidate Act and the intended sink. The
Finality Sink is the broadcast gate, scheduler, RF output, beam
controller, D2D/public-warning interface, gNB, or destination
delivery boundary. The alert cannot become radiative or delivery-
effective outside the authorized message, region, time, and
repetition scope.
*Relationship to existing technology.* Existing public-warning
formats and broadcast procedures remain responsible for message
transport; finality constrains the consequence of transmission.
Where an existing mechanism already guarantees the same non-
bypassable consequence-bound property, that mechanism is invited as a
technical correction or equivalence reference.
10.5.9. Profile 44: Location Disclosure and Rescue-Mode Finality
*Problem space.* Satellite systems can derive location, proximity,
beam, timing, Doppler, rescue, beacon, or device-region information
at precision levels that exceed what a particular recipient or
emergency purpose is authorized to receive.
Das Expires 18 March 2027 [Page 53]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is collection,
derivation, disclosure, transmission, storage, release, precision
increase, or correlation of location-related artifacts. It remains
in a Non-Effective State until the Protected Enforcement Domain
validates data source, subject or device scope, permitted precision,
recipient, emergency or rescue purpose, minimization and retention
constraints, no-unauthorized-correlation policy, freshness, and
revocation; commits the required protected validation evidence; and
permits scoped non-bearer authority bound to the Candidate Act and
the intended sink. The Finality Sink is the location-release gate,
rescue-mode output, emergency API, downlink, public-safety interface,
or destination admission boundary. The system can compute more
precise location internally without automatically making that
precision externally effective.
*Relationship to existing technology.* This profile complements
location and emergency-service mechanisms by separating access to raw
capability from authority to disclose a particular precision. Where
an existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
10.5.10. Profile 45: Disaster Roaming and Offline-Survival Service
Finality
*Problem space.* During terrestrial outage, network partition, or
ledger/connectivity loss, a satellite service may need to operate
from cached policy and local protected state. Permanently failing
closed can defeat emergency continuity, while unrestricted fail-open
behavior can create standing bypass authority.
*Execution-finality solution.* The Candidate Act is admission or
continuation of disaster roaming, offline survival, degraded
satellite access, pre-authorized emergency service, D2D continuity,
or other partition-tolerant service. It remains in a Non-Effective
State until the Protected Enforcement Domain validates cached policy
and revocation state, emergency scope, terminal or service identity,
quota and duration, local protected state, sealed receipt buffer,
reconciliation requirements, policy epoch, and freshness available
locally; commits the required protected validation evidence; and
permits scoped non-bearer authority bound to the Candidate Act and
the intended sink. The Finality Sink is the disaster-roaming gate,
emergency bearer, gNB or core admission, UPF, D2D interface, offline
receipt boundary, reconciliation gate, or service output. Offline
operation is bounded to the survival scope and produces protected
evidence for later reconciliation rather than creating unrestricted
authority.
Das Expires 18 March 2027 [Page 54]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Relationship to existing technology.* DTN and offline protocols
provide continuity; execution finality adds locally enforceable
bounded authority and reconciliation state. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
10.6. Firmware, Microcode, Maintenance, and Privileged-Control Profiles
10.6.1. Profile 46: Satellite Microcode-Update Activation Finality
*Problem space.* A microcode or low-level control-store update can be
authentic and applicable to the hardware revision yet still be
unauthorized for the current mission, boot slot, dependency state,
anti-rollback state, or recovery mode.
*Execution-finality solution.* The Candidate Act is loading,
activation, selection, commitment, rollback, restore, or hot-patch of
processor, accelerator, memory-controller, DSP, baseband,
cryptographic, recovery, or safe-mode microcode. It remains in a
Non-Effective State until the Protected Enforcement Domain validates
hardware revision, current and candidate versions, digest, function
and slot, anti-rollback state, mission state, dependencies, policy
epoch, freshness, and revocation; commits the required protected
validation evidence; and permits scoped non-bearer authority bound to
the Candidate Act and the intended sink. The Finality Sink is the
microcode load path, control-store write, patch register,
microsequencer, boot slot selector, reset gate, hot-patch boundary,
safe-mode gate, rollback gate, or execution-enable point. The update
artifact can be verified without becoming executable until activation
authority validates.
*Relationship to existing technology.* SUIT-style update metadata and
secure-update mechanisms can govern artifact distribution and
installation; finality adds the exact activation consequence. Where
an existing mechanism already guarantees the same non-bypassable
consequence-bound property, that mechanism is invited as a technical
correction or equivalence reference.
10.6.2. Profile 47: Beamforming Firmware and Codebook Update Finality
*Problem space.* Beamforming firmware, codebooks, weights, phase and
amplitude tables, precoders, nulls, hopping plans, tracking
parameters, frequency settings, and power settings can alter the
physical radiation pattern immediately when activated.
Das Expires 18 March 2027 [Page 55]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is loading or
activation of beamforming firmware, codebooks, array weights, phase/
amplitude settings, precoders, beam-hopping or tracking parameters,
frequency, power, calibration, debug, or safe-mode beam state. It
remains in a Non-Effective State until the Protected Enforcement
Domain validates firmware or codebook identity, beam footprint,
coverage and exclusion zones, frequency, RF power, emission mask,
mission scope, dependency state, policy epoch, freshness, and
revocation; commits the required protected validation evidence; and
permits scoped non-bearer authority bound to the Candidate Act and
the intended sink. The Finality Sink is the firmware-activation
gate, codebook bank, weight table, phase/amplitude controller,
precoder, null controller, beam scheduler, frequency controller, RF
power or EIRP gate, RF chain, or antenna-output boundary. A verified
update does not alter radiative behavior until the bound beam and
emission scope validates.
*Relationship to existing technology.* Secure update mechanisms
protect the artifact; 3GPP or radio implementations control beam
behavior; this profile binds update activation to the resulting
physical consequence. Where an existing mechanism already guarantees
the same non-bypassable consequence-bound property, that mechanism is
invited as a technical correction or equivalence reference.
10.6.3. Profile 48: Payload-Controller Patch Finality
*Problem space.* A payload patch can change command handling, state
machines, sensing, RF, optical, routing, storage, compression, AI,
emergency, D2D, recovery, debug, or partner behavior across many
subsystems. Signature validity alone does not bound those downstream
effects.
*Execution-finality solution.* The Candidate Act is loading,
installation, activation, rollback, restore, or switching of a
payload-controller patch or active bank. It remains in a Non-
Effective State until the Protected Enforcement Domain validates
patch identity and digest, target payload and subsystem, current and
candidate version, permitted function and effect scope, dependencies,
mission and recovery state, policy epoch, freshness, revocation, and
anti-rollback state; commits the required protected validation
evidence; and permits scoped non-bearer authority bound to the
Candidate Act and the intended sink. The Finality Sink is the patch-
activation boundary, active-bank selector, command or state-machine
gate, subsystem enable, sensor/RF/optical/AI/routing/storage output,
rollback gate, reset-release gate, or payload output. The patch may
be stored and verified without becoming operational until the
intended effect scope validates.
Das Expires 18 March 2027 [Page 56]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Relationship to existing technology.* This profile complements SUIT
and vendor update systems by making payload effectuation a separately
controlled event. Where an existing mechanism already guarantees the
same non-bypassable consequence-bound property, that mechanism is
invited as a technical correction or equivalence reference.
10.6.4. Profile 49: Maintenance, Debug, JTAG, and Privileged Console
Finality
*Problem space.* Maintenance interfaces such as JTAG, scan chains,
boundary scan, debug ports, engineering consoles, protected-memory
access, register writes, key-store diagnostics, tensor buffers, and
model-state access can bypass ordinary runtime controls if possession
of maintenance credentials is treated as unrestricted authority.
*Execution-finality solution.* The Candidate Act is enablement or use
of a maintenance, engineering, diagnostic, debug, JTAG, scan-chain,
console, protected-memory, register, key-store, tensor-buffer, or
model-state operation. It remains in a Non-Effective State until the
Protected Enforcement Domain validates target subsystem and
interface, command and argument digests, affected resource and output
scope, maintenance evidence, time window, quota or duration, approval
quorum where applicable, dependency receipts, freshness, replay
state, and revocation; commits the required protected validation
evidence; and permits scoped non-bearer authority bound to the
Candidate Act and the intended sink. The Finality Sink is the debug-
port, JTAG, scan-chain, command-handler, maintenance-shell,
protected-memory, register-write, key-store diagnostic, tensor-
buffer, or related privileged-access gate. Privileged maintenance
remains bounded to the exact command, interface, resource, and time
scope and fails closed outside it.
*Relationship to existing technology.* Authentication of a maintainer
or debug credential is necessary but is not treated as unrestricted
authority for every privileged consequence. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
10.6.5. Profile 50: Break-Glass, Emergency Override, and Finality-
Bypass Control
*Problem space.* Emergency and recovery procedures sometimes require
overriding normal RF, optical, payload, AI, watchdog, thermal, power,
or safe-mode limits. An unbounded break-glass mechanism can become
the very bypass path that defeats finality.
Das Expires 18 March 2027 [Page 57]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is invocation of an
emergency override, RF or optical override, payload or AI-accelerator
override, watchdog or thermal/power-limit override, safe-mode exit,
receipt repair, rollback, emergency service activation, or attempted
finality-sink bypass. It remains in a Non-Effective State until the
Protected Enforcement Domain validates override class, target
subsystem, command and argument digests, affected resource and output
commitments, emergency evidence, time window, quota or duration,
approval quorum where applicable, substitute-finality path where
required, freshness, replay prevention, policy epoch, and revocation;
commits the required protected validation evidence; and permits
scoped non-bearer authority bound to the Candidate Act and the
intended sink. The Finality Sink is the RF or optical gate, payload-
control gate, update or rollback gate, safe-mode exit, watchdog or
resource override, receipt-repair gate, reset-release gate,
emergency-service gate, or dedicated finality-bypass gate. The
override itself is treated as a Candidate Act; direct bypass is
rejected unless an explicitly authorized substitute finality path
satisfies the bounded emergency scope.
*Relationship to existing technology.* This profile is intended to
prevent "break glass" from becoming standing bearer authority while
preserving explicitly bounded emergency operation. Where an existing
mechanism already guarantees the same non-bypassable consequence-
bound property, that mechanism is invited as a technical correction
or equivalence reference.
10.7. Future Space-Mobility, Manufacturing, Servicing, and End-of-Life
Profiles
Profiles 51 through 60 extend the same execution-finality invariant
to consequence boundaries that are increasingly relevant to satellite
manufacturers, spacecraft integrators, launch providers that also
perform spacecraft integration or in-space services, orbital-mobility
platforms, in-orbit servicing systems, and operators planning more
autonomous missions. The selection is future-facing, but the
enforcement mechanisms below are limited to combinations supported by
the underlying disclosure rather than being inferred from any
particular commercial roadmap.
Das Expires 18 March 2027 [Page 58]
Internet-Draft LEO/NTN Orbital Finality September 2026
Scope discipline is intentional. This revision does not create
profiles for launcher stage separation, fairing jettison, docking-
capture mechanics, or propellant-transfer plumbing merely because
those functions are commercially important. Those mechanisms should
be added only where a separately reviewed disclosure provides
adequate technical support. The profiles below instead govern
disclosed maneuver, actuation, payload, sensing, end-of-life,
component-admission, and command-release boundaries that can be
relevant to future launcher-adjacent and satellite-manufacturing
roadmaps.
10.7.1. Profile 51: Autonomous Orbital Maneuver and Delta-V Finality
*Problem space.* Autonomous mission planners, flight-dynamics
software, or ground systems can calculate a technically valid
station-keeping or orbital-maneuver command while the current orbital
state, protected asset zones, mission phase, jurisdictional
conditions, or clearance state make that exact maneuver unauthorized.
Correct trajectory computation and valid telecommand authentication
therefore do not necessarily establish authority for physical orbital
change.
*Execution-finality solution.* The Candidate Act is a thrust command,
delta-V command, station-keeping change, orbital-path change, or
related maneuver instruction. The act remains in a Non-Effective
State while the Protected Enforcement Domain binds the exact maneuver
vector or command digest to the satellite identity, current or
predicted orbital state, mission phase, permitted orbital region or
corridor, kinetic and positional safety predicates, applicable
clearance or threshold authority, freshness, nonce state, policy
epoch, and revocation state. Protected validation evidence is
committed before scoped non-bearer maneuver authority becomes
available. The Finality Sink is the propulsion actuator, thruster
latch valve, attitude/propulsion control gate, or equivalent
mandatory maneuver-effectuation boundary. If the act, state,
clearance, or sink binding no longer corresponds, propulsion
authority is withheld and the proposed maneuver remains non-
effective.
*Relationship to existing technology.* This profile complements
flight dynamics, guidance-navigation-control, orbital propagation,
command authentication, and mission planning. Those systems may
calculate or recommend the maneuver; execution finality governs
whether the exact maneuver is permitted to cross the physical
maneuver boundary. Existing systems that already provide an
equivalent act-bound, non-bypassable maneuver-authority property are
invited as correction or equivalence references.
Das Expires 18 March 2027 [Page 59]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.7.2. Profile 52: Collision-Avoidance and Conjunction-Response
Finality
*Problem space.* Collision-avoidance automation can reduce risk, but
an avoidance maneuver can itself create a new conjunction, violate a
protected orbital corridor, conflict with another maneuver, or rely
on stale conjunction or telemetry state. Treating a conjunction
alert or optimizer output as direct propulsion authority can
therefore collapse risk estimation into physical authority.
*Execution-finality solution.* The Candidate Act is a collision-
avoidance, conjunction-response, evasive, hold, or related
trajectory-change command. Before effectuation, the Protected
Enforcement Domain evaluates the exact command against current
orbital and telemetry state, applicable conjunction assessment or
digital-twin state, predicted proximity to active satellites, crewed
spacecraft, debris fields or protected zones, mission and positional
constraints, command freshness, revocation state, policy epoch, nonce
state, and any required threshold authority. It commits protected
validation evidence and permits only act-specific, time-bounded
authority for the identified Finality Sink. The Finality Sink is the
propulsion or attitude-control boundary whose state change produces
the avoidance maneuver. If relevant state becomes stale,
inconsistent, revoked, or outside the permitted corridor, the
maneuver remains non-effective or is reduced to an explicitly
authorized safety-only mode.
*Relationship to existing technology.* This profile does not replace
conjunction assessment, space-domain awareness, space-traffic
coordination, or collision-avoidance algorithms. It uses their
outputs as predicates while separately governing the physical
response. This distinction is relevant to current zero-debris
roadmaps that increasingly rely on autonomous collision-risk
mitigation. Equivalent consequence-bound mechanisms are expressly
invited as technical corrections or equivalence references.
10.7.3. Profile 53: Rendezvous, Proximity-Operations, and Servicing-
Approach Finality
*Problem space.* Inspection, relocation, mission extension,
servicing, debris-removal preparation, and other future space-
logistics missions require a spacecraft to approach another object.
Mission authorization to perform a servicing operation does not
necessarily authorize every proximity vector, timing window, target
approach, or orbital-path change, particularly when protected assets
or restricted orbital volumes are nearby.
Das Expires 18 March 2027 [Page 60]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is a proximity-
operation, rendezvous, approach, relative-orbit, or servicing-
approach maneuver command. It remains non-effective until the
Protected Enforcement Domain validates the candidate command against
the participating spacecraft identities, orbital context, target or
protected-asset zone, mission scope, permitted approach or orbital
corridor, kinetic and positional predicates, required clearance or
threshold authority, current policy and revocation state, freshness,
and nonce state. Protected validation evidence is committed before
release of a scoped maneuver capability. The Finality Sink is the
propulsion actuator, thruster latch valve, reaction-wheel or
attitude-control gate, or equivalent boundary that makes the approach
physically effective.
*Relationship to existing technology.* This profile is relevant to
rendezvous and proximity operations used by emerging on-orbit
servicing and space-logistics systems. It does not define relative-
navigation algorithms, docking interfaces, capture mechanisms,
robotic arms, or refueling hardware. Its narrower function is to
keep an exact approach command non-effective until consequence-bound
authority validates. Existing RPO safety mechanisms that already
provide this invariant are invited as equivalence references.
10.7.4. Profile 54: Propulsion Ignition and Thruster-Impulse Finality
*Problem space.* A high-level maneuver may be properly planned while
a lower-level ignition, valve-open, burn-duration, or impulse command
is substituted, replayed, stale, or directed to the wrong propulsion
element. If low-level propulsion hardware accepts commands merely
because the flight computer or command channel is trusted, a bypass
can occur below the mission-planning authorization layer.
*Execution-finality solution.* The Candidate Act is propulsion
ignition, thruster-valve opening, bounded thruster impulse, burn
enablement, or another propulsion actuator command. The Protected
Enforcement Domain binds the exact command hash, propulsion subsystem
or actuator, mission phase, permitted act class, requested temporal
window, maneuver context, applicable hardware status, policy and
revocation epochs, nonce, and target Finality Sink. It commits
protected validation evidence before releasing a short-lived, non-
bearer propulsion capability. The Finality Sink is the propulsion
actuator, thruster latch valve, ignition-enable path, or equivalent
physical enablement point. The capability authorizes only the
specific propulsion act and cannot be reused for another thruster,
burn window, maneuver, mission phase, or sink.
Das Expires 18 March 2027 [Page 61]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Relationship to existing technology.* This profile complements
propulsion electronics, engine or thruster controllers, fault
protection, GNC, and command authentication. It adds an exact-act
authority check at the physical propulsion-enablement boundary rather
than replacing propulsion-control logic. Readers are invited to
identify existing flight-safety architectures that already enforce
the same non-bypassable binding.
10.7.5. Profile 55: Attitude-Control, Reaction-Wheel, and Gimbal
Actuation Finality
*Problem space.* A spacecraft can create consequential effects
without changing orbit. Attitude changes, reaction-wheel commands,
gimbal motion, or pointing changes can redirect an optical terminal,
sensor, antenna, or payload toward a different target or region. A
valid pointing computation therefore does not necessarily establish
authority for the corresponding physical orientation change.
*Execution-finality solution.* The Candidate Act is an attitude-
control instruction, reaction-wheel actuation, steering-actuator
command, gimbal movement, or pointing-state change. It remains non-
effective while the Protected Enforcement Domain validates satellite
and subsystem identity, mission phase, current attitude and pointing
state, target direction or payload/terminal context, spacecraft
health, reaction-wheel or steering state where applicable, power and
thermal margin where required, policy and revocation epochs,
freshness, nonce state, and any related beam, sensing, or mission
authority. Protected validation evidence precedes a scoped
capability. The Finality Sink is the reaction-wheel driver, gimbal
motor, attitude-control actuator, steering actuator, or other
mandatory orientation-control boundary.
*Relationship to existing technology.* This profile complements
attitude determination and control systems, star trackers, pointing
controllers, optical acquisition/tracking, and payload pointing
logic. Those systems determine how to point; execution finality
determines whether this particular commanded orientation is
authorized to become physically effective. Equivalent safety-
interlock behavior is invited as a technical correction or
equivalence reference.
Das Expires 18 March 2027 [Page 62]
Internet-Draft LEO/NTN Orbital Finality September 2026
10.7.6. Profile 56: Hosted-Payload Activation, Reconfiguration, and
Third-Party Egress Finality
*Problem space.* Future multi-mission spacecraft can host payloads
owned or operated by parties different from the platform operator. A
hosted payload may be authenticated and legitimately installed yet
still attempt a mode change, sensor activation, AI-output release,
storage commit, RF or optical egress, or payload-bus operation
outside the current mission, destination, jurisdiction, or platform
policy. Operating outside the primary application stack can
otherwise become a bypass path.
*Execution-finality solution.* The Candidate Act is hosted-payload
activation, payload-mode change, payload reconfiguration, payload-bus
action, sensing activation, output release, or governed RF, optical,
storage, or routing egress. The Protected Enforcement Domain
validates hosted-payload identity and attestation where required,
payload class and permitted mode, mission phase, destination or
route, current platform and payload state, applicable jurisdiction or
data-sharing scope, freshness, policy epoch, revocation state, nonce
state, and the target Finality Sink. Protected validation evidence
is committed before a capability scoped to the exact payload act is
released. The Finality Sink may be the payload activation rail,
payload controller, payload bus gate, storage-commit interface, RF or
optical egress, or destination-admission interface. A third-party
payload cannot obtain broader authority merely by bypassing the
primary application stack.
*Relationship to existing technology.* This profile is directly
relevant to spacecraft platforms offering payload hosting,
infrastructure services, edge computing, or mission-unique payload
integration. It does not define mechanical payload deployment or
separation. Existing hosted-payload isolation or bus-enforcement
systems providing the same act-bound effectuation property are
invited as equivalence references.
10.7.7. Profile 57: High-Resolution Imaging and Sensor-Exposure
Finality
*Problem space.* Authorization to operate an Earth-observation or
sensing spacecraft does not necessarily authorize every sensor
exposure, SAR emission, pointing direction, imaging resolution,
revisit, or observation of a restricted target. Controlling only
downstream data release can be too late where the acquisition or
emission itself is the protected consequence.
Das Expires 18 March 2027 [Page 63]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is camera exposure,
sensing-payload activation, high-resolution imaging, SAR pulse
emission, observation-mode change, or another bounded sensor-
acquisition operation. The Protected Enforcement Domain binds the
exact target or region, observation mode, permitted resolution or
sensing class, satellite and payload identity, orbital and attitude
state, mission phase, purpose, applicable jurisdiction or restricted-
area rule, freshness, policy and revocation epochs, nonce state, and
any required quorum or threshold approval for high-risk observation.
It commits protected validation evidence before issuing a scoped
sensing capability. The Finality Sink is the payload shutter
trigger, camera power rail, sensor activation path, SAR emission
path, or equivalent acquisition boundary. If validation fails, no
governed exposure or emission occurs even if the sensing plan was
otherwise executable.
*Relationship to existing technology.* This profile complements
Earth-observation tasking, sensor control, licensing, geofencing, and
downstream data-release controls. It governs the acquisition
boundary itself; Profiles 17 and 18 continue to govern later AI-
product release and resolution/purpose-bounded disclosure. Existing
sensor-tasking controls that already make acquisition technically
non-completable without exact current authority are invited as
technical corrections or equivalence references.
10.7.8. Profile 58: End-of-Life Battery Decommissioning and
Irreversible Power-State Finality
*Problem space.* End-of-life actions are safety relevant but can also
be destructive or irreversible. A stale, replayed, premature, or
mis-scoped battery-decommissioning or irreversible power-state
command can terminate mission capability, remove recovery options, or
leave the spacecraft in an unintended state. Treating an end-of-life
flag as standing authority creates a high-consequence control risk.
Das Expires 18 March 2027 [Page 64]
Internet-Draft LEO/NTN Orbital Finality September 2026
*Execution-finality solution.* The Candidate Act is battery
decommissioning, irreversible power-state transition, protected key
or state destruction associated with end-of-life, or another
explicitly governed mission-termination action supported by the
platform. The Protected Enforcement Domain validates spacecraft
identity, mission phase and end-of-life authority, target subsystem,
power and health state, command digest, lifecycle state, required
quorum or threshold authority, policy and revocation epochs,
freshness, nonce state, protected-state continuity, and target
Finality Sink. Protected validation evidence is committed before
release of a one-purpose, non-bearer decommissioning capability. The
Finality Sink is the battery or power controller, key-destruction or
protected-state gate where applicable, or other irreversible mission-
state boundary. The authority expires after the specified act and
cannot become standing power-control authority.
*Relationship to existing technology.* This profile is relevant to
zero-debris and autonomous end-of-life roadmaps, but it does not
define deorbit propulsion, venting, propellant passivation, drag
devices, or reentry mechanics. It governs only disclosed
decommissioning and irreversible power/state actions. Where existing
spacecraft end-of-life controllers already provide equivalent exact-
act, quorum-bound finality, that mechanism should be identified.
10.7.9. Profile 59: Spaceborne Component Re-Admission Across
Manufacturing, Integration, Launch Preparation, and Servicing
*Problem space.* Spaceborne processor packages and heterogeneous
subsystems can include components sourced from multiple vendors and
can be replaced, reintroduced, re-enumerated, repaired, upgraded, or
restored from quarantine during manufacturing, integration, launch
preparation, anomaly response, or later servicing. A component can
be genuine yet wrong for the package, slot, revision, mission, role,
firmware state, or current policy epoch, and test/debug state can
remain enabled after integration.
*Execution-finality solution.* The Candidate Act is component or
chiplet admission, re-admission, reactivation, re-enumeration,
restoration from quarantine, or replacement activation. The
Protected Enforcement Domain validates component identity and
certificate state, package and slot binding, permitted role, hardware
revision, compatible firmware or microcode, lifecycle and test/debug
state, mission phase, package topology, current health and recovery
state, revocation, freshness, policy epoch, nonce state, and
applicable prior admission evidence. Protected validation evidence
is committed before scoped admission authority becomes available.
The Finality Sink is the reset-release, interconnect-attach, memory-
admission, enumeration, execution-enable, or equivalent protected
Das Expires 18 March 2027 [Page 65]
Internet-Draft LEO/NTN Orbital Finality September 2026
package/subsystem activation boundary. Electrical compatibility or
certificate validity alone is insufficient for mission-ready
admission.
*Relationship to existing technology.* This profile complements
supply-chain assurance, secure boot, component authentication,
hardware attestation, acceptance testing, and launch-site integration
procedures. It is particularly relevant where manufacturers or
launch providers perform late integration or replacement before
flight. Existing component-admission systems that already bind
authenticity to package role, lifecycle state, mission phase, and the
actual activation sink are invited as equivalence references.
10.7.10. Profile 60: High-Consequence Mission Command Quorum and Anti-
Coercion Finality
*Problem space.* Some satellite actions remain too consequential to
treat a single authenticated command source, operator credential, or
software approval flag as sufficient authority. Orbital maneuvers,
propulsion actuation, attitude-control override, restricted payload
activation, high-power transmission, cryptographic-key release,
emergency override, beam reconfiguration, and irreversible mission-
state transitions can require stronger protection against coercion,
replay, compromised operator endpoints, or fabricated quorum state.
*Execution-finality solution.* The Candidate Act is the exact high-
consequence command. The Protected Enforcement Domain generates or
validates a challenge bound to the Candidate Operation Object,
command hash, mission phase, target subsystem, time window, policy
epoch, revocation epoch, nonce, and target Finality Sink. Where
configured, a geographically separated activation token, hardware
authenticator, secure element, user-presence-dependent device, or
multiple registered authority responses must return valid, fresh,
act-matching approvals. Verified-count or quorum state is maintained
inside protected state so ordinary software cannot fabricate, replay,
inflate, reorder, or transplant approvals. Protected validation
evidence is committed before a scoped command-enabling capability is
released, and the underlying physical or protocol Finality Sink still
verifies that capability before effectuation.
*Relationship to existing technology.* This profile complements
telecommand authentication, operator procedures, dual-control rules,
safety review, and mission key management. Human or multi-authority
approval is treated as an input predicate rather than as a bypass
around the Finality Sink. Existing threshold-command or two-person-
control systems that already bind fresh approvals to the exact
pending act and the actual consequence boundary are invited as
technical equivalence references.
Das Expires 18 March 2027 [Page 66]
Internet-Draft LEO/NTN Orbital Finality September 2026
11. Operational and Deployment Considerations
11.1. Finality-Sink Placement
The useful placement is the last boundary at which denial can still
prevent the protected consequence. Validation can occur earlier, but
an early decision alone is insufficient when later state can change.
A sink may therefore verify a compact capability or reconstruct load-
bearing state rather than rerun every upstream check.
11.2. Latency and Availability Tradeoffs
Additional validation can add latency and protected-state operations.
The architecture is therefore most appropriate where the protected
consequence justifies the cost, including high-value AI output
release, cross-domain routing, RF or optical effectuation, update
activation, emergency control, and spacecraft recovery. The document
does not propose that every packet, arithmetic operation, or internal
model token require an independent heavyweight validation
transaction.
11.3. Disconnected and Emergency Operation
Satellite systems cannot assume continuous access to a central policy
service. Deployments can use pre-authorized bounded offline
authority, protected counters, monotonic state, cached revocation
epochs, limited validity windows, sealed local evidence, and later
reconciliation. A disconnected mode should be explicit in scope and
duration rather than an implicit fail-open state.
11.4. Incremental and Legacy Deployment
A Protected Enforcement Domain or Finality Sink can be integrated
into hardware, firmware, a secure enclave, an HSM, a DPU or SmartNIC,
an OS or hypervisor boundary, a satellite gateway, a payload
controller, or a protected sidecar or proxy. The security claim must
match the actual bypass resistance of the deployment. A sidecar that
can be skipped by another path does not provide non-bypassable
finality for that path.
11.5. Time, Ephemeris, Epoch, and Revocation State
Satellite authorization can depend on time and rapidly changing
state. Deployments should define the trust source, update cadence,
acceptable uncertainty, monotonicity, and failure handling for
clocks, ephemeris, beam state, policy epochs, revocation epochs, and
other values that become load-bearing predicates.
Das Expires 18 March 2027 [Page 67]
Internet-Draft LEO/NTN Orbital Finality September 2026
12. Security Considerations
Every profile depends on accurate act binding and sink coverage. An
attacker must not be able to substitute the Candidate Act,
destination, model, route, beam, update, command arguments, or
protected state after validation without invalidating the authority
presented at the Finality Sink.
Replay protection, freshness, revocation, quota consumption,
monotonic state, and atomic or correctly ordered evidence commitment
are security-critical where the profile relies on them.
Implementations should also consider denial of service against the
validation path and avoid designs in which expensive radio, optical,
accelerator, or memory work is unconditionally consumed before
inexpensive reject conditions can be evaluated.
Alternate-path closure is central. If an AI output can leave through
a debug interface, a route can bypass the protected forwarding point,
or an RF chain can be enabled independently of the designated sink,
the deployment does not provide finality for that external effect.
Emergency and maintenance paths are therefore modeled as Candidate
Acts rather than assumed exceptions.
13. Privacy Considerations
Validation can involve location, jurisdiction, mission, route,
emergency, identity, model, sensor, or device state. Implementations
should minimize disclosure of such predicates and avoid turning
denial behavior into a side channel that reveals satellite topology,
terminal presence, rescue state, restricted regions, route
availability, or partner-constellation policy.
Protected validation evidence need not expose every underlying
predicate to every downstream component. Where possible, the
Finality Sink should receive only the information required to
establish the bounded authority for the relevant consequence.
14. IANA Considerations
This document has no IANA actions.
15. Informative References
[ACE-WG] IETF, "Authentication and Authorization for Constrained
Environments Working Group", 2026,
.
Das Expires 18 March 2027 [Page 68]
Internet-Draft LEO/NTN Orbital Finality September 2026
[CCAMP-WG] IETF, "Common Control and Measurement Plane Working
Group", 2026,
.
[DAS-6G-ORAN]
Das, S., "Execution-Finality for AI-Native 5G/6G and
O-RAN", Work in Progress, Internet-Draft, draft-das-ai-
native-6g-execution-finality, 2026,
.
[DAS-6G-ORAN-IMPL]
Das, S., "Execution-Finality for AI-Native 5G/6G and O-RAN
-- Runnable Reference Implementation", GitHub repository
sangmdas/Execution-Finality-for-AI-Native-5G-6G-and-O-RAN
---Runnable-Reference-Implementation, 2026,
.
[DAS-AI-GOV-IMPL]
Das, S., "Execution-Finality Technical Enforcement for EU
AI Act and AI Governance Constraints -- Runnable Reference
Implementation", GitHub repository sangmdas/Execution-
Finality-Technical-Enforcement-for-EU-AI-Act-and-AI-
Governance-Constraints, 2026,
.
[DAS-DIGITAL-SOV]
Das, S., "When Data Leaves Its Originating Jurisdiction,
Who Controls It? Digital Sovereignty Without Data
Localisation by Separating the Compute Plane from the
Authority Plane", Work in Progress, Internet-Draft, draft-
das-digital-sovereignty-finality, 2026,
.
[DAS-EU-AI-ACT]
Das, S., "Technical Enforcement of the EU AI Act and
Global AI Laws for High-Risk AI Systems Without Relying on
Paper Policies", Work in Progress, Internet-Draft, draft-
das-eu-ai-act-execution-enforcement, 2026,
.
Das Expires 18 March 2027 [Page 69]
Internet-Draft LEO/NTN Orbital Finality September 2026
[DAS-GPU-IMPL]
Das, S., "Execution-Finality for GPU AI Accelerators and
Confidential Workloads", GitHub repository
sangmdas/Execution-Finality-for-GPU-AI-Accelerators-and-
Confidential-Workloads, 2026,
.
[DAS-HW-EF]
Das, S., "Computation Is Not Authority: Hardware-Enforced
Execution-Finality for Agentic AI, MCP Tool Calls, and
Industrial Agents", Work in Progress, Internet-Draft,
draft-das-hardware-enforced-execution-finality, 2026,
.
[DAS-HW-IMPL]
Das, S., "Hardware Execution-Finality for AI and
Autonomous Systems -- Reference Implementation", GitHub
repository sangmdas/Hardware-Execution-Finality-for-AI-
and-Autonomous-Systems, 2026,
.
[DAS-NTN-IMPL]
Das, S., "NTN and Inter-Satellite Control -- Runnable
Reference Implementation", GitHub repository sangmdas/NTN-
and-Inter-Satellite-Control-Runnable-Reference-
Implementation, 2026, .
[DAS-NTN-RF]
Das, S., "RF Enable Is Not Transmit Authority: Finality
for LEO/NTN and Inter-Satellite Control", Work in
Progress, Internet-Draft, draft-das-ntn-rf-execution-
finality, 2026, .
[DAS-PROTOCOL-LAYER]
Das, S., "The Missing Protocol Layer for the Agentic
Internet: Computation Is Not Authority", Work in Progress,
Internet-Draft, draft-das-execution-finality-protocol-
layer, 2026, .
Das Expires 18 March 2027 [Page 70]
Internet-Draft LEO/NTN Orbital Finality September 2026
[DAS-RATS-EF]
Das, S., "Attestation-Bound Execution Finality for GPU, AI
Accelerator, DPU, SmartNIC, and Confidential-Computing
Infrastructure", Work in Progress, Internet-Draft, draft-
das-rats-attestation-bnd-execution-finality, 2026,
.
[DAS-ZENODO-CANDIDATE]
Das, S., "Technical Architecture for Governing
Consequential AI Agent Actions", Zenodo 22323362, 2026,
.
[DAS-ZENODO-FOUNDATIONAL]
Das, S., "The Internet Solved Communication. It Never
Solved Authority", Zenodo 22082995, 2026,
.
[DAS-ZENODO-GPU]
Das, S., "Architecture and Working Reference
Implementation for GPUs, AI Accelerators, and Confidential
Workloads", Zenodo 22308384, 2026,
.
[DTN-WG] IETF, "Delay/Disruption Tolerant Networking Working
Group", 2026,
.
[EU-AI-ACT]
European Union, "Regulation (EU) 2024/1689 laying down
harmonised rules on artificial intelligence (Artificial
Intelligence Act)", 2024, .
[NIST-AI-RMF]
National Institute of Standards and Technology,
"Artificial Intelligence Risk Management Framework (AI RMF
1.0)", NIST AI 100-1, 2023,
.
[RATS-WG] IETF, "Remote ATtestation ProcedureS Working Group", 2026,
.
[RFC9019] IETF, "A Firmware Update Architecture for Internet of
Things", RFC 9019, 2021,
.
Das Expires 18 March 2027 [Page 71]
Internet-Draft LEO/NTN Orbital Finality September 2026
[RFC9171] IETF, "Bundle Protocol Version 7", RFC 9171, 2022,
.
[RFC9172] IETF, "Bundle Protocol Security (BPSec)", RFC 9172, 2022,
.
[RFC9200] IETF, "Authentication and Authorization for Constrained
Environments Using the OAuth 2.0 Framework (ACE-OAuth)",
RFC 9200, 2022, .
[RFC9334] IETF, "Remote ATtestation procedureS (RATS) Architecture",
RFC 9334, 2023, .
[RFC9397] IETF, "Trusted Execution Environment Provisioning (TEEP)
Architecture", RFC 9397, 2023,
.
[RFC9657] IETF, "Time-Variant Routing (TVR) Use Cases", RFC 9657,
2024, .
[SUIT-WG] IETF, "Software Updates for Internet of Things Working
Group", 2026,
.
[TEEP-WG] IETF, "Trusted Execution Environment Provisioning Working
Group (concluded)", 2026,
.
[TGPP-TR-38.821]
3GPP, "Solutions for NR to support non-terrestrial
networks (NTN)", 3GPP TR 38.821, 2021.
[TVR-WG] IETF, "Time-Variant Routing Working Group", 2026,
.
Profile Construction and Traceability
The sixty profiles are engineering decompositions and supported
combinations of the satellite, NTN, orbital-compute, optical-link,
resilience, update, privileged-control, orbital-mobility, sensing,
end-of-life, and manufacturing/component-admission mechanisms used as
the drafting basis for this document. They intentionally avoid
reproducing patent-claim syntax. XML comments before each profile
preserve the source claim identifiers, embodiment identifiers, or
reviewed disclosure families used during drafting so that the author
can audit whether a proposed profile is directly supported or is a
combination of already disclosed elements. Profiles 51 through 60
were additionally selected for relevance to publicly described future
Das Expires 18 March 2027 [Page 72]
Internet-Draft LEO/NTN Orbital Finality September 2026
satellite-manufacturing, space-mobility, servicing, and zero-debris
roadmaps, but roadmap relevance does not expand the technical
disclosure. Those comments do not alter the rendered Internet-Draft.
Acknowledgements
This document is an individual submission. Critical technical review
is expressly invited, including corrections to the characterization
of 3GPP, IETF, optical-network, spacecraft FDIR, update, attestation,
authorization, and deployed satellite mechanisms. Identification of
existing mechanisms that already provide an equivalent non-bypassable
execution-to-effect property is particularly useful.
Author's Address
Sangam Kumar Das
Independent
Balasore
Odisha
India
Phone: +91-9861363532
Email: info@sangamdas.com
Das Expires 18 March 2027 [Page 73]