]> Independent Inventor

Balasore Odisha India info@sangamdas.com

Internet Network Working Group DRIP Remote ID UAS execution finality finality sink TESLA detect and avoid autonomous vehicle control authority handover Problem: Unmanned Aircraft System (UAS) trust infrastructure answers two questions well. Remote Identification (RID), strengthened by the Drone Remote ID Protocol (DRIP), answers "who is this aircraft?", and UAS Traffic Management (UTM), U-space, and geo-awareness answer "may this flight take place here and now?". Neither answers the question that decides physical consequence: may this specific act -- arming motors, crossing into a newly restricted volume, releasing a delivery payload, activating a camera over a protected area, emitting on a radio band, or joining a coordinated multi-aircraft manoeuvre -- become effective at this actuator, at this instant, under the airspace and revocation state that is current now? Authorizations are granted before or at take-off, while acts are executed continuously by mission computers and autonomy stacks that can be compromised, misled, coerced with validly signed commands, or cut off from their authorities. Observers on the ground, in turn, can verify an aircraft's identity but not whether what it is doing was authorized before it happened. Solution: The IETF-facing contribution of this document is Compact Broadcast Act Evidence: 16-octet per-act decision records authenticated with a TESLA-style one-way key chain sealed inside a Protected Enforcement Domain and anchored to the aircraft's DRIP identity. This lets an Observer verify, after a short disclosure delay and within the 25-octet Broadcast RID message budget, that the protected enforcement domain made an allow, deny, or safe-state decision before the corresponding evidence key was disclosed, without requiring a public-key signature on every act. The evidence mechanism is coupled to an execution-finality profile in which each safety-significant or externally consequential act remains non-effective as a Candidate Act until the Protected Enforcement Domain verifies an act-bound, sink-bound Execution Handle against live trusted context, consumes current authority state atomically, commits a Finality Receipt, and only then releases the physical enablement condition at the Finality Sink. The profile also specifies act classes and sinks, self-contained object fields, sink processing pseudocode, envelope handles for high-rate control, a boundary-proximity revalidation policy, bounded offline operation, and composite multi-aircraft semantics. For constrained onboard, air-to-air, telemetry, or other small-frame links, the profile also defines an optional Beacon Proof Capsule (BPC): a compact act-bound and sink-bound execution-proof representation using an Authority Reference, freshness and generation state, a context commitment, a keyed binding commitment, explicit truncation-risk sizing, authenticated multi-frame reconstruction when necessary, and fail-closed resolver semantics. A BPC is an input to execution verification; the AER/KDR/Anchor mechanism is output evidence of the PED decision, and the two roles are intentionally non-interchangeable. Additional profiles: This document also describes three narrowly scoped execution-finality embodiments: conflict-set-bound Detect-and-Avoid (DAA) resolution finality for UAS, emergency-scene temporary authority finality for autonomous road vehicles as an informative cross-domain application, and atomic control-authority handover with monotonic authority epochs for autonomous motion platforms. These profiles preserve the same rule: an authenticated or correctly computed instruction remains a Candidate Act until the current effectuation boundary independently verifies the state on which that instruction depends. In an autonomous road vehicle, that boundary may be a protected motion-admission gate rather than a motor or ESC gate, so the architecture can coexist with the vehicle's existing perception, planning, braking, steering, and minimal-risk-control functions. Industrial context and complementarity: The mechanism complements, and does not replace, Broadcast and Network RID, DRIP Entity Tags and authentication, DET resolution through DNS, UTM and U-space services, geo-awareness, Detect-and-Avoid, flight-control safety logic, automotive ADAS/autonomy stacks, remote-assistance systems, and authenticated command channels. Publicly described examples of the kinds of software-defined or autonomy-enabled platforms to which this boundary can be complementary include Tesla driver-assistance systems, BYD DiPilot and related intelligent-driving platforms, DJI enterprise drone automation, Boeing autonomous and uncrewed aircraft systems, and Lockheed Martin/Sikorsky autonomous aircraft systems. These names are illustrative only: this document does not state or imply that any named organization uses, endorses, requires, or has evaluated this profile. Their existing perception, planning, stabilization, DAA, ADAS, command-and-control, and safety mechanisms remain in place; the proposed finality layer operates later, at a protected motion-admission or actuator boundary, to verify the concrete pending act against current protected authority and state before effectuation. The scope of this document remains strictly civil and excludes weapon release, targeting, and counter-UAS engagement. This is an individual Informational Internet-Draft, not a DRIP WG work item. In short, its IETF/IRTF relevance is to DRIP (DET-anchored compact act evidence for Observers), RATS (attestation of the protected enforcement domain), COSE/CBOR (deterministic compact objects), ACE (constrained scoped authorization as input rather than effectuation), SCITT (later audit of receipts), and T2TRG (constrained Things with multiple authorities). No WG adoption or code-point allocation is requested in this version; the draft is offered for technical discussion in those communities and in UAS, Remote ID, constrained-security, autonomous-vehicle, and aviation standards forums.

Introduction This document is an individual Informational Internet-Draft. It is not a DRIP Working Group work item and does not request allocation of a DRIP or ASTM/ICAO carriage code point in this version. The compact evidence format and its carriage are presented for technical review and possible future standardization.

Industry-Standard Terminology and Functional Equivalence This subsection restates the architecture in conventional systems-engineering, cybersecurity, safety-control, automotive, aerospace, telecommunications, and distributed-systems language. It is included so that the technical disclosure remains readily understandable and searchable even when an implementation uses different product names, protocol names, or industry vocabulary. The mechanism described by this document does not depend on use of the labels "Candidate Act", "Protected Execution Domain", "Finality Sink", "Beacon Proof Capsule", or "Finality Receipt". An implementation can use different names or package the functions into different components while implementing the same enforcement sequence. In ordinary industrial terms, the architecture can be summarized as follows. A planner, application, autonomy stack, remote operator, network controller, AI component, or other command source may propose an action, but proposal is separated from permission to make the action physically or externally effective. The proposed operation is first represented precisely and bound, cryptographically or by equivalent protected integrity mechanisms, to the authorized operation or bounded operating envelope, the intended enforcement point or controlled resource, freshness information, and relevant policy, revocation, configuration, or operating-context state. The operation remains pending, inhibited, staged, uncommitted, or otherwise unable to actuate while those checks are unresolved. At the last practical control point before consequence -- for example a motor driver, steering or braking controller, payload latch, secure I/O gateway, RF transmit-enable path, baseband or beamformer control, routing or forwarding boundary, sensor-enable path, or other actuator/resource boundary -- a protected enforcement function determines the operation that is actually about to occur. It then compares that impending operation with the operation or envelope that was authorized. Effectuation is released only if the operation, target boundary, freshness, authority, current policy/revocation state, and required context still agree. A stale, replayed, substituted, redirected, widened, or contextually obsolete operation remains blocked. A successful decision may release only a narrow local capability or control envelope, while a failed decision leaves the consequential path inhibited or permits only a separately defined safe action. The following terminology bridge is informative. The entries identify common words under which substantially the same engineering functions may appear in specifications, safety cases, product documentation, security literature, prior art, or implementation descriptions. Terminology bridge to conventional industry wording

Term used in this document	Common industry wording or search terminology	Underlying function
Candidate Act	proposed command; action request; actuation request; control request; motion request; transaction; pending operation; requested state transition	The concrete operation that is proposed but has not yet been allowed to cause its consequence.
Non-Effective State	pending; staged; blocked; inhibited; disarmed; not committed; not admitted; output-disabled	A state in which computation may continue but the consequential output path is not yet usable.
Protected Execution Domain	trusted enforcement domain; isolated security domain; safety/security supervisor; protected controller; secure microcontroller; TEE-backed control function	A protected component that forms or verifies security-relevant state outside the control of the ordinary command-producing component.
Finality Sink	policy enforcement point (PEP); reference monitor; safety interlock; command gate; actuation gate; motion-admission gate; secure I/O gateway; output authorization gate; RF transmit-enable interlock	The last protected enforcement point that can still prevent the proposed operation from becoming externally effective.
Binding Commitment	cryptographic command binding; request binding; parameter binding; object binding; transaction binding; canonical-request digest; MAC/signature over operation and context	Integrity-protected association between the authorized operation and the exact parameters, target, context, and freshness against which it was evaluated.
Authority Object / Authority Reference	authorization credential; permit; capability; entitlement; policy decision; grant; signed authorization; token reference; cached authorization record	The authority basis against which the impending operation is permitted or denied; possession of a reference alone need not be sufficient to actuate.
Freshness and anti-replay state	nonce; sequence number; monotonic counter; challenge; timestamp; validity window; replay window; one-time token state	State that prevents an old or previously consumed authorization from being reused as if it were current.
Policy / revocation / authority epoch	generation number; version; revision; fencing token; lease generation; configuration epoch; controller epoch	A monotonic or otherwise protected version discriminator that makes stale authority distinguishable from current authority.
Context Commitment	state snapshot; state digest; context hash; environment version; geofence revision; ODD state; scene state; traffic-state snapshot	A protected representation of the operating conditions on which the authorization decision depended.
Bounded execution capability	least-privilege capability; single-use permit; scoped actuation token; control envelope; trajectory envelope; limited command authorization	A local permission that can enable only the specified act, sink, parameter range, time, counter value, trajectory, or actuator envelope.
Atomic finality commit	atomic check-and-use; compare-and-commit; transactional authorization; commit-time validation; TOCTOU-resistant authorization; atomic state transition	The deciding read of current security state, replay consumption, decision recording, and release of effectuation authority occur as one protected transaction or equivalent indivisible transition.
Finality Receipt	decision record; audit receipt; commit record; authorization evidence; tamper-evident event record	Protected evidence identifying what operation was admitted or denied, under which current state and enforcement boundary.
Safe-Action Set	fail-safe action; degraded mode; minimal-risk manoeuvre; controlled stop; inhibit; receive-only mode; bounded fallback behavior	A separately bounded set of stabilizing or risk-reducing actions that remains available when permission-expanding actions cannot be freshly authorized.
Beacon Proof Capsule	compact authorization proof; compact capability; command-authorization descriptor; short-form permit; constrained-link security token; act-binding evidence message	A compact representation carrying or referencing enough protected material for the downstream enforcement point to verify the intended act without treating the message itself as unrestricted authority.
Conflict-set commitment	traffic-state snapshot; encounter-state digest; threat-set commitment; intruder-set version; multi-object safety-state binding	Binding of a detect-and-avoid or collision-resolution decision to the set of relevant traffic objects and state on which the resolution was computed.
Atomic controller handover	controller arbitration; control-ownership transfer; single-writer handover; lease transfer; epoch-based leader change; fencing-based failover	A protected transition in which old control authority is made stale before ordinary effectuation by a replacement controller is enabled.

Functional-Equivalence Test in Plain Engineering Language For purposes of understanding the technical mechanism, the important question is not what a component is called but what it does. An implementation follows the same basic enforcement pattern when the following properties are present:

1. A command-producing component can request or compute an operation but cannot, by that fact alone, make the consequential output occur.
2. The proposed operation, or a deliberately bounded envelope of operations, is integrity-bound to the intended controlled resource or enforcement point and to freshness plus the security-relevant state on which permission depends.
3. The operation stays pending, inhibited, staged, or otherwise non-effective until a downstream enforcement check succeeds.
4. The downstream enforcement function derives or observes the actual operation that will reach the actuator, RF path, motion controller, protected resource, or other consequence-producing boundary rather than trusting only the upstream description of what was supposedly requested.
5. The actual impending operation is compared with the authorized operation or envelope, including material parameters, destination or sink identity, freshness, applicable context, and current policy/revocation/configuration generation.
6. Replay, parameter substitution, target substitution, stale authorization, stale controller ownership, or a material change in required context causes denial, revalidation, or transition to a bounded safe action rather than silent continuation.
7. Where stale-state races matter, the final security-state read, replay or nonce consumption, decision/receipt update, and release of effectuation authority are performed atomically or with equivalent transactional semantics so that a check cannot become obsolete before the consequence is enabled.
8. The released authority is no broader than needed -- for example one act, one actuator, one sink, one trajectory tube, one speed/thrust envelope, one RF configuration, one beam or route, one time interval, or one controller epoch -- and alternate consequence paths are either blocked or subject to equivalent enforcement.

Examples in specific industries may therefore be described as an actuator safety interlock, secure command gate, policy enforcement point, reference monitor, drive-by-wire admission controller, flight-control authorization gate, payload-release interlock, transactional authorization boundary, RF inhibit, transmit-enable gate, beam/frequency/power authorization gate, secure routing admission point, or controller-fencing mechanism. Those labels describe deployment forms; the common logic is the separation of computation from effectuation authority and the independent verification of the concrete impending act at the boundary where it can still be stopped.

Additional Public Disclosure and Transparency Materials Provisional patent disclosure / sample copy. For transparency, a public sample copy of the corresponding provisional patent disclosure and supporting technical material is available as additional disclosure at Zenodo: Remote ID Solved "Who Is Flying." It Never Solved "Who Allowed That." The record is made available so reviewers can inspect the broader disclosed technical context, embodiments, and enforcement-boundary material associated with this work. The external disclosure is supplementary; the technical content and requirements of this Internet-Draft are stated in this document. Broad architectural disclosure. For transparency and broader technical context beyond the UAS-specific profile, a public disclosure of the execution-finality architecture across AI, cloud, telecommunications, payments, satellite systems, critical infrastructure, and other consequence-bearing machine operations is available at Zenodo: The Internet Solved Communication. It Never Solved Authority. This record is provided as supplementary broad disclosure of the common computation-to-consequence enforcement architecture; it does not replace or modify the protocol requirements stated in this Internet-Draft. Related European public-interest discussion. A related public discussion of the authority problem in counter-drone and autonomous-system environments is available through the European Commission Apply AI Alliance / Futurium platform: Europe's Counter-Drone Challenge Is Also an Authority Problem. This material is provided as contextual background and for transparency; it does not alter the scope, protocol semantics, or interoperability requirements specified here.

Problem Space An uncrewed aircraft is a moving actuator. Its acts have immediate physical consequence and, once effective, often cannot be recalled: a rotor that spins up near people, a payload that leaves its latch, a camera frame captured over a private garden, or a transmission that interferes with a protected band. Current UAS governance authorizes the flight, identifies the aircraft, and records what happened. It does not, in general, make an individual consequential act depend on authority that is verified at the actuator at the moment of effect. The gap is structural rather than a matter of stricter policy. Consider the following civil situations, each of which occurs within a flight that was validly authorized at take-off:

1. Mid-flight restriction. A delivery aircraft is authorized for a corridor at 14:00. At 14:07 a temporary restriction is activated over part of that corridor for an emergency response. The authorization token held by the ground software is still cryptographically valid; the next corridor segment is no longer lawful. Whether the aircraft enters depends on whether the new geo-zone data reached, and was obeyed by, software that may be stale or compromised.
2. Compromised or misled mission computer. The perception or planning stack is fed adversarial input, runs a faulty update, or is controlled by an attacker with root access. If it has effective write access to motor output registers, ESC arming, the payload latch, or the camera power rail, a software failure becomes a physical event. A software-only geofence running on the same processor can be altered or bypassed by the same failure.
3. Validly signed but unsafe command. A ground station, fleet service, or remote pilot sends a correctly authenticated command to release a payload at an unapproved coordinate, disable RID transmission, or enter a restricted volume. Link authentication (for example, MAVLink 2 message signing) establishes that the command came from a key holder. It does not establish that this act is permitted in the present context.
4. Degraded or lost link. The aircraft loses contact with its operator, UTM service, and revocation source. A revocation issued after link loss cannot be learned. Without an explicit bound, cached authority may continue to permit acts indefinitely.
5. Partial coordinated manoeuvre. Several aircraft must change formation or hand off an inspection segment together. If some commit and others do not, separation assumptions are violated. Retries and compensations are themselves new acts.
6. Unverifiable conduct for Observers. A police officer, facility operator, or member of the public can use DRIP to verify that Broadcast RID messages come from the registered owner of a DRIP Entity Tag (DET). They cannot verify whether an act they are watching -- a camera pointed at a stadium, a payload lowered in a car park -- was authorized before it happened, and Broadcast RID has no room for per-act public-key signatures at typical broadcast rates.

In all six cases, the missing element is the same: a boundary, positioned immediately before the physical effect, at which authority for this act is verified against current state and consumed, and without which the actuator lacks the physical means to act.

Why Standardization Is Required Execution finality for aircraft cannot be delivered by one vendor in isolation, for four reasons.

1. Authority originates outside the aircraft. Corridor approvals, temporary restrictions, geo-zone data, operator credentials, revocations, and payload permissions are produced by UTM service suppliers, U-space service providers, aviation authority interfaces, fleet operators, and customers. The aircraft's enforcement domain must interpret their outputs identically. Without a common descriptor, generation model, and binding rule, each airframe would re-implement ad hoc checks that cannot be audited against one another.
2. Evidence must be verifiable by parties who did not issue the authority. Regulators, insurers, investigators, and Observers need portable receipts and broadcast evidence with defined formats and verification rules. DRIP already provides the identity and broadcast authentication foundation; act evidence needs to be compatible with it rather than parallel to it.
3. Constrained links force interoperable compactness. Broadcast RID messages are 25 octets. Legacy transports can lose Authentication Message pages. Onboard buses such as classic CAN carry 8-octet payloads. Compact encodings only interoperate if they are specified.
4. Multi-aircraft and multi-authority acts cross administrative domains. A coordinated manoeuvre across operators, or a handoff between service areas, requires common prepare, commit, abort, and hold semantics.

Existing Solutions and Their Boundaries Each of the following is necessary and well established. None of them, alone or together, makes an individual act non-effective until authority for that act is verified and consumed at the sink. Existing mechanisms and the question each answers

Mechanism	Question it answers	Boundary relative to this document
Broadcast and Network RID (ASTM F3411 ; regional rules such as 14 CFR Part 89 and EU Regulation 2019/945)	Who is this aircraft, where is it, who operates it?	Identity and telemetry; no act-level authority.
DRIP: DET , architecture , authentication formats , and DET/DIME resolution in DNS	Who controls the claimed DET, and can its identity/authentication material be resolved and verified?	Trustworthy identity, resolution, and message provenance; does not state whether a physical act was authorized before it occurred.
UTM (ASTM F3548 ) and U-space (EU Implementing Regulation 2021/664); authorization services such as LAANC	May this flight or operation take place in this airspace and time?	Strategic and tactical flight authorization; enforcement onboard is left to the aircraft.
Geo-awareness, geo-zone data (for example EUROCAE ED-269), vendor geo-zone databases, autopilot geofences and failsafes	Is the aircraft inside a permitted volume, and what should it do if not?	Usually software-mediated and co-located with the stack that can fail; typically movement-centric, not covering payload, sensor, and RF acts; not bound to consumable per-act authority.
MAVLink 2 message signing; authenticated onboard messaging (for example AUTOSAR SecOC-style truncated MAC with freshness)	Did this message come from a key holder, and is it fresh?	Authenticates the channel or sender; a valid key holder may still request a contextually unauthorized act.
Secure boot, measured boot, and remote attestation	Is the software that booted the expected software?	Establishes platform state; runtime deviation, coercion, and stale authority remain possible after boot.
Flight logs, post-flight analysis, Network RID records	What happened?	After the fact; the effect has already occurred.

Contributions of This Profile

1. Compact Broadcast Act Evidence: fixed 16-octet per-act records authenticated with a TESLA-style one-way key chain sealed in the Protected Enforcement Domain and anchored through DRIP identity, giving Observers loss-tolerant, delayed-disclosure verification inside the Broadcast RID size envelope without a public-key signature on every act ().
2. A constrained execution-proof transport profile using Beacon Proof Capsules (BPCs), compact Authority References, keyed act/sink/context commitments, explicit collision and attacker-work sizing for truncated values, authenticated fragmentation, and resolver-assisted reconstruction (). A BPC is verification input and is never accepted as broadcast evidence merely because it was received.
3. An act-level UAS profile mapping Candidate Act classes to concrete Finality Sinks and to the physical enablement condition withheld at each sink ().
4. A placement rule in which the Protected Enforcement Domain sits on every command-to-enablement path, so that a compromised command source cannot itself synthesize actuator authority ().
5. Live-context enforcement including corridor containment, multi-source position consistency, generation currentness inside atomic consume, and a conservative boundary-proximity revalidation scheduling policy ().
6. Envelope handles for high-rate actuation streams, so motor setpoints at hundreds of hertz are checked by bounded comparison rather than a public-key operation per setpoint ().
7. A bounded offline mode that converts link loss into a finite residual exposure rather than open-ended cached authority ().
8. A composite profile for multi-aircraft acts whose prepare step does not move an aircraft and whose HOLD state is a physically safe holding manoeuvre ().
9. A conflict-set-bound DAA finality profile that binds an accepted avoidance resolution to the conflict set, ownship state, motion sink, and monotonic Resolution Epoch on which the resolution was computed; the sink revalidates the current conflict set and all relevant intruders before admitting the maneuver ().
10. An informative emergency-scene profile for autonomous road vehicles in which temporary responder authority is bound to the incident, scene, vehicle, bounded traffic-rule exception, concrete motion, expiry, and independent local scene corroboration, and automatically extinguishes when the scene authority ceases to apply ().
11. An atomic control-authority handover profile in which protected current-controller state and monotonic Control Authority Epochs prevent two otherwise valid controllers from simultaneously acquiring ordinary effectuation authority over the same governed sink ().

Scope and Non-Goals In scope: civil UAS in the specific and certified categories and comparable national regimes, including delivery, infrastructure inspection, agriculture, mapping, emergency and public-safety support, and urban air mobility support functions. Out of scope: weapons, weapon release, targeting, and counter-UAS engagement. This document does not define airworthiness or certification requirements, does not replace flight-control safety design, does not define legal rules, and does not decide which acts a regulator permits. It defines how a permission that has been issued is technically enforced at the moment of effect, and how that enforcement can be evidenced. A safe-state manoeuvre (hover, loiter, controlled descent, landing, return-to-home) is never blocked by this profile for lack of a fresh handle; safe states are pre-authorized as described in . is intentionally included as an informative cross-domain application to autonomous road vehicles because the same effectuation-boundary problem occurs when a temporary first-responder instruction requests a bounded exception to ordinary motion policy. It does not change the UAS interoperability scope of the BPC, AER, RID, or DRIP mechanisms in this document. applies to UAS and may also be reused by other autonomous motion platforms.

Relationship to Companion Documents This document is intended to be implementable without requiring any companion Internet-Draft. The UAS Candidate Act fields, Authority Object fields, handle bindings, consume ordering, receipt semantics, failure behavior, composite rules, and broadcast-evidence procedures required by this profile are stated locally. Companion individual Internet-Drafts provide broader cross-domain background on execution handles , registries , composite finality , jurisdiction binding , actuation binding , state continuity , revocation , consequence-path completeness , and the general architecture . Those references are informative; in case of a difference, the rules in this UAS profile control for this document. Symbolic failure names not allocated by an IANA registry are local to this document.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. RID, UA, UAS, DET, HDA, Observer, and Broadcast Endorsement are used as in , , and ; DET/DIME resolution through DNS is described by . The following terms are used in addition.

Candidate Act:

A proposed UA action whose effect is held non-effective until finality is reached, for example "open payload latch at this location now".

Protected Enforcement Domain (PED):

An isolated execution environment onboard the UA (secure microcontroller, FPGA region, safety processor, TEE, or HSM-backed controller) that holds verification keys, sealed reference state, consume state, and the evidence key chain, and that controls the enablement conditions of Finality Sinks. The mission computer cannot read its keys, rewrite its predicates, or synthesize its release signal.

Finality Sink:

The component at which an act first becomes physically or externally effective, for example an ESC enable input, motor output register bank, payload latch driver, RF power-amplifier enable, or camera power rail.

Enablement Condition:

The physical or cryptographic condition without which the sink cannot produce the effect: an enable line, gated power rail, register write window, radio key, or sensor-output key.

UAS Candidate Act Descriptor (U-CAD):

The canonical descriptor of a Candidate Act defined by this document. It is compatible in concept with the broader Candidate Act Descriptor described in , but this document does not depend on that draft.

Airspace Authority Object (AAO):

A signed object issued by an operator, UTM or U-space service, aviation authority interface, or payload authority that states the corridor, time window, envelopes, and act classes permitted, together with the generations it was issued against.

Execution Handle:

A non-bearer, sink-bound, act-bound authorization object that the PED verifies and consumes. Possession of a handle confers nothing.

Envelope Handle:

An Execution Handle with the ENVELOPE reuse policy that authorizes a bounded parameter set over a bounded time window for a high-rate stream.

Generation:

A monotonically increasing version number of an authority input: airspace and geo-zone data (g_air), revocation state (g_rev), and operator policy (g_pol).

Finality Receipt:

A PED-signed record of an allow or deny decision committed before release. A receipt is evidence and is never accepted as a handle.

Safe-State Set (S_safe):

The pre-authorized set of manoeuvres and subsystem states that the PED may select without a fresh handle.

Beacon Proof Capsule (BPC):

A compact, machine-verifiable representation that carries or references execution-finality evidence for a Candidate Act over a constrained link. A BPC binds the act to its intended sink, authority reference, freshness and current generation state, and selected context. Receipt or possession of a BPC is not by itself authority; the PED and Finality Sink still reconstruct and verify the actual impending act.

Authority Reference:

A compact identifier, keyed digest, index, cache key, or resolver key by which the PED identifies an AAO or other authority state. The reference is not authority and a cache or resolver miss never degrades to authorization.

Binding Commitment:

A preferably keyed cryptographic commitment that binds the Candidate Act digest to the Finality Sink, Authority Reference, current-generation inputs, selected context, freshness, and validity scope. A compact BPC may carry only a truncated form selected according to the risk rules in .

Evidence key:

A PED-held public key, distinct from the UA Host Identity / DET key, used to sign an evidence-epoch Anchor. The DET / Host Identity key endorses the evidence key for a bounded validity period as described in .

Conflict Set:

The policy-relevant set of cooperative or non-cooperative traffic tracks whose state, uncertainty, freshness, and encounter class are material to a DAA resolution at a given resolution horizon.

Conflict-Set Root:

A deterministic cryptographic commitment to the canonical Conflict Set used as the safety basis for an accepted DAA resolution.

Resolution Epoch:

A protected monotonically increasing value identifying the currently selected DAA resolution. Superseding a resolution advances the epoch and invalidates ordinary motion authority bound to an earlier epoch.

Emergency Scene Authority Capsule (ESAC):

An informative cross-domain authority object binding a temporary first-responder or incident instruction to a vehicle, incident, scene, bounded exception class, concrete motion envelope, expiry, epochs, nonce, and local scene corroboration requirements.

Control Authority Epoch:

A protected monotonically increasing value associated with the controller currently authorized to exercise ordinary effectuation authority over a governed sink or sink class.

Current Controller:

The controller identifier recorded in protected authority state for the current Control Authority Epoch of a governed sink.

Act Evidence Record (AER):

The 16-octet broadcast record defined in . (The acronym is local to this document.)

Mathematical and Cryptographic Notation This section collects notation used by the cryptographic, execution-finality, delayed-disclosure, and autonomous-motion constructions in this document. Symbols are local to this specification unless an external reference states otherwise. In artwork, || denotes byte-string concatenation, not logical OR. Structured objects that are hashed or authenticated are first encoded using the deterministic representation required by the applicable section.

General Operators and Cryptographic Values

H(x), SHA-256(x):

A collision-resistant cryptographic hash of x. Where this document writes H(x) generically, a profile may instantiate it with SHA-256 or another specified cryptographic hash.

HMAC-SHA-256(K, x) or HMAC_K(x):

A keyed message-authentication code over x under secret key K, using HMAC with SHA-256 in the concrete constructions of this profile.

Trunc_b(x):

The first or otherwise profile-defined b bits of x. The retained length b is security-significant and is selected according to the collision, substitution, or forgery bounds stated in the relevant section.

HKDF(K_root, info):

A key-derivation operation that derives a purpose- and context-specific key from protected root material K_root and the indicated domain-separation and scope information.

det-CBOR(X), C(X), canonical(X):

The deterministic or canonical byte serialization of semantic object X. Equality of semantic fields is not sufficient when a cryptographic operation is defined over bytes; the required deterministic encoding is used before hashing or authentication.

DOM or quoted domain-separation string:

A fixed label separating one cryptographic use from another. For example, "UAS-BPC-ACT", "UAS-BPC-BIND", "UAS-AFE-chain", "UAS-AFE-tag", and "UAS-AFE-rec" prevent values from different cryptographic roles from being treated as interchangeable. In generic explanatory notation, DOM_E denotes the AER record-authentication domain; in this profile its concrete record-domain label is "UAS-AFE-rec".

TRUE / FALSE and AND / OR / NOT:

Boolean predicates and operators. An implication X => Y means that whenever X is true, Y is required to be true under the stated invariant.

Execution-Finality and BPC Notation

U:

The UAS Candidate Act Descriptor (U-CAD) for the concrete pending act.

d(U):

The deterministic digest of U, defined by this profile as SHA-256(det-CBOR(U)) unless a section defines a more specific domain-separated act digest.

D_A:

The domain-separated Act Commitment derived from the canonical Candidate Act.

D_C:

The domain-separated Context Commitment derived from the selected live or semi-live context material relevant to effectuation.

B:

The full Binding Commitment that cryptographically binds the act to the Finality Sink, Authority Reference, current-generation state, context, freshness, and validity scope.

B_t:

The t-bit compact representation Trunc_t(B) carried by a constrained BPC.

K_root:

Protected root key material from which role-specific keys may be derived. Possession of ordinary mission-computer state does not imply access to K_root.

K_B:

The BPC or compact-transport authentication key derived for the applicable session and scope.

K_bind:

The act-binding key used to bind execution semantics to the Candidate Act and Finality Sink. K_bind and K_B are distinct key roles.

K_R:

The protected Authority-Reference derivation key used by keyed compact Authority Reference constructions.

K_frag:

The protected key used to authenticate individual fragments belonging to an authenticated multi-frame BPC reconstruction.

K_S:

A protected sink-local capability-authentication key used to create or verify a bounded execution capability after successful finality verification. K_S is held by, derived within, or otherwise available only to the PED, the applicable Finality Sink, and any specifically authorized downstream capability verifier; it is unavailable to the ordinary act-proposing component.

t, r, m:

Respectively, the retained Binding-Commitment length, Authority-Reference length, and authentication-tag length, in bits, where used by the relevant construction.

q:

The approximate number of distinct compact commitments in the collision domain for the birthday-collision estimate. In the emergency-scene q-of-n corroboration equation, q is separately defined locally as the required number of independent validated evidence channels; the local definition controls.

W:

The assumed offline attacker-work budget, measured in candidate hash or commitment trials, for an unkeyed compact binding.

A_online:

The maximum or assumed number of online substitution attempts permitted by freshness, replay, rate-limit, lockout, or escalation controls.

epsilon_c, epsilon_s, epsilon_f:

Target upper bounds for accidental collision, targeted substitution, and aggregate authenticator forgery probability, respectively.

R_n:

The nth protected Finality Receipt in a receipt chain. H(R_(n-1)) denotes the cryptographic linkage to the preceding committed receipt.

Delayed-Disclosure AER and KDR Notation The delayed-disclosure construction uses a reverse one-way chain. The indexing in this subsection is normative for interpreting the equations in . AER intervals are zero-based. Interval i uses a tag key K'_i derived from the then-undisclosed chain value K_(i+1); K_0 is only the public Anchor commitment.

K_seed:

A random master seed generated inside the PED for an evidence epoch. K_seed is never disclosed to an Observer or transmitter and may be erased after the terminal chain value K_N has been derived and sealed.

K_N:

The terminal value of the reverse evidence chain. In the concrete profile it is derived from K_seed and the evidence epoch, for example K_N = Trunc_128(SHA-256("UAS-AFE-seed" || K_seed || epoch_id)). Unlike K_seed, K_N is a chain value and may become public if the final usable evidence interval is reached and its scheduled disclosure occurs.

K_i:

Chain value i in the reverse one-way chain, related by K_i = F(K_(i+1)) for i = N-1 ... 0.

F:

The domain-separated one-way chain function. The concrete profile defines F(x) = Trunc_128(SHA-256("UAS-AFE-chain" || x)).

F':

A distinct domain-separated one-way function used only to derive an AER authentication key from an undisclosed chain value. The concrete profile defines F'(x) = Trunc_128(SHA-256("UAS-AFE-tag" || x)).

K_0:

The public chain commitment carried in the signed Evidence Anchor. K_0 is used to authenticate later disclosed chain values and is not used, directly or through F', as an AER authentication secret.

K'_i:

The AER authentication key for zero-based evidence interval i, defined as K'_i = F'(K_(i+1)). The prime denotes a derived tag key; K'_i is not itself a member of the reverse chain.

I_i:

Evidence interval i, defined as [T_0 + i*Delta, T_0 + (i+1)*Delta).

i:

The zero-based evidence-interval index associated with an AER.

j:

A later evidence interval whose disclosed chain value K_(j+1) may be used in disclosure verification and loss recovery. Where j is later than i, K_(j+1) can be iterated through F to recover K_(i+1).

N:

The terminal chain index and the number of zero-based evidence intervals in the epoch: intervals 0 through N-1 use chain values K_1 through K_N.

T_0:

The authenticated start time of the evidence epoch carried in the Anchor.

Delta:

The duration of one evidence interval.

d:

The disclosure lag expressed in whole evidence intervals. The chain value K_(i+1) used for AER interval i becomes public only after the configured delay.

hdr or Header_i:

The canonical 8-octet AER header associated with interval i. The concrete construction names this value hdr; Header_i is equivalent explanatory notation when the interval must be explicit.

tag or TAG_i:

The truncated HMAC appended to hdr to form the 16-octet AER. In the default profile it is a 64-bit truncation computed under K'_i.

epoch_id:

The identifier of the current evidence epoch. It is bound both into terminal chain derivation and AER authentication so chain material and records from one evidence epoch cannot be transplanted into another.

ua_det:

The DRIP Entity Tag identifying the UA to which the evidence epoch and AER are bound.

i ]]>

Autonomous-Motion Profile Notation

d(t):

The protected estimate of distance from the current position to the nearest relevant boundary of the permitted spatial region at time t, positive while inside the permitted region.

eps_pos:

The conservative position-uncertainty bound used by the boundary-revalidation rule.

v_max:

The maximum outward or otherwise relevant permitted speed used in the revalidation bound.

tau:

The enforcement-to-actuator reaction latency assumed by the stopping-distance model.

a_brk:

The guaranteed positive deceleration magnitude used by the stopping-distance model.

Delta_r:

The maximum permitted time between spatial-authority revalidations under the selected boundary-proximity model.

p_i and sigma_i:

Respectively, the position estimate reported by source i and that source's stated one-sigma uncertainty for the multi-source consistency check.

k:

A positive, profile-selected uncertainty multiplier defining the required confidence margin in the multi-source position-consistency predicate.

q_min:

The minimum number of sufficiently independent or partially independent position sources required to agree within the stated uncertainty-dependent consistency bound.

||x||:

The applicable spatial-distance norm for vector x; a deployment selects the norm consistently with its position representation and safety analysis.

C_root:

The deterministic Conflict-Set Root binding the canonical policy-relevant intruder set used as the safety basis of a DAA resolution.

r_j, v_j:

Relative position and relative velocity of policy-relevant intruder j with respect to ownship for the illustrative closest-point-of-approach calculation.

T:

The prediction horizon for the illustrative DAA safety calculation.

t_CPA,j and d_CPA,j:

The predicted time to closest point of approach and distance at closest point of approach for intruder j under the stated illustrative motion model.

D_req,j:

The required separation distance or applicable well-clear threshold for encounter class j.

epsilon_j:

A conservative uncertainty margin accounting for surveillance, estimation, latency, or model error relevant to intruder j.

m_j(M):

The safety margin for candidate maneuver M against intruder j. A negative value indicates failure of the illustrative margin predicate.

C_auth, C_now:

Respectively, the conflict set used when the maneuver was authorized and the protected current conflict set reconstructed near motion admission.

S_scene:

The Emergency-Scene Commitment binding the incident, scene geometry, locally validated evidence, temporary-control state, and Scene Epoch.

v_i and q in scene corroboration:

v_i is the protected binary validation result for independent evidence channel i; q is the locally specified minimum number of independently validated channels required by the q-of-n corroboration rule.

E(t):

The Boolean predicate stating whether temporary emergency authority remains effective at time t.

delta_loc:

The conservative localization margin used when dilating an emergency-scene polygon for location-bounded authority.

A(c,s,e,t):

A Boolean indicator equal to 1 when controller c possesses ordinary effectuation authority over governed sink s in authority epoch e at time t, and 0 otherwise.

CurrentController[s], CurrentEpoch[s], CurrentEnvelope[s]:

Protected sink-local authority state identifying the controller, monotonic Control Authority Epoch, and permitted act or motion envelope currently valid for sink s.

Architecture The mission computer keeps every function it has today: perception, planning, route optimization, obstacle avoidance, inspection logic, and operator assistance. What changes is that its outputs become proposals. The PED sits on every path from a command source to an enablement condition.

Placement of the Protected Enforcement Domain | Protected Enforcement | | | | autonomy, AI, | | Domain (PED) | | | | planner, GCS link|<--decisions---| keys | sealed refs | | | +------------------+ | consume | receipts | | | | evidence key chain | | | +------------------+ trusted | safe-state logic | | | | GNSS/RTK, VIO, |-------------->| | | | | IMU, baro, time, | context +---+-----+-----+-----+--+ | | | battery, ESC tel.| | | | | | | +------------------+ enable/ | | | | | | release v v v v | | +------+ +-----+ +----+ +-------+ | | RID module <-- AER ---------| ESC / | |Latch| | RF | |Camera/| | | (Broadcast RID, DRIP) | motor | |power| | PA | |sensor | | | | regs | | | | EN | | power | | | +------+ +-----+ +----+ +-------+ | | Finality Sinks (default: disabled) | +-------------------------------------------------------------------+ ]]>

Three authorities are kept separate. Computation authority belongs to the mission computer. Resource and airspace authority belongs to off-board issuers and is carried in AAOs. Effect authority exists only at the PED and is expressed as a released enablement condition. A compromise of the first does not yield the third. The PED MUST hold every protected enablement condition in the non-effective state by default. A command signal that reaches a sink without the corresponding enablement condition MUST NOT produce the effect. The mission computer, debug ports, maintenance interfaces, and radio command links MUST NOT have a path to a protected register bank or enable line that bypasses the PED; this is the path-completeness requirement of applied to the airframe. The stabilizing inner control loop may run in the flight controller outside the PED. The PED gates the envelope within which that loop may drive the motors, and the arming condition, rather than every inner-loop computation. This keeps real-time attitude control where it is today.

Independent Enforcement Points This section states selected execution-finality properties as independently testable enforcement points. Each point stands on its own and does not depend on a preceding item for its security meaning. The list is intentionally selective: it identifies boundaries at which effect authority is created, withheld, narrowed, refreshed, transferred, or evidenced, rather than repeating every embodiment described elsewhere in this document.

Core Exact-Act and Atomic-Finality Enforcement

1. EP-01 — Exact-act sink verification. A consequential operation MUST remain in a Non-Effective State until a protected Finality Sink independently reconstructs the operation actually presented for effectuation, derives the expected act binding, verifies the designated sink, freshness, current authority, and required context, and releases effectuation only after those checks succeed.
2. EP-02 — Binding-key separation. When a keyed binding commitment is used, the Binding Key MUST NOT be available to the mission computer, autonomy model, motion planner, network forwarder, ordinary application processor, or other component that can propose or relay the Candidate Act. Control of proposal inputs therefore does not by itself permit construction of a different valid act binding.
3. EP-03 — Authority reference is not effect authority. A compact Authority Reference MAY identify or resolve a fuller Authority Object from protected local storage, an authenticated cache, a gateway, or a trusted resolver, but possession of the reference alone MUST NOT authorize effectuation. Failure to resolve or validate the referenced authority MUST leave the Candidate Act non-effective.
4. EP-04 — Current-state binding. An act binding MAY include policy and revocation generations, geofence or road-zone version, corridor, mission or driving mode, payload state, radio state, device identity, altitude or lane scope, safety state, expiry, and a Context Commitment. A material change in a bound value before effectuation MUST cause rejection or protected revalidation rather than silent reuse of the earlier authorization.
5. EP-05 — Freshness and replay consumption. A protected verifier MUST validate freshness using a nonce, sequence value, monotonic counter, time slot, validity interval, rolling session value, challenge, expiry, or an equivalent mechanism. A freshness value that has already been consumed for a single-use act MUST NOT authorize a second effect.
6. EP-06 — Atomic finality commit. For a permission-expanding act, the deciding read of current policy and revocation state, replay or freshness consumption, protected decision recording, and creation or release of the bounded execution capability MUST occur as one protected finality transaction or with equivalent crash-safe semantics. A failure between these steps MUST NOT expose an unrecorded usable capability.
7. EP-07 — Receipt-before-release ordering. When a Finality Receipt is part of the selected profile, the receipt or equivalent protected decision state MUST be committed before the corresponding sink-local execution capability becomes usable. The capability MUST remain bounded by the act, sink, parameters, time or counter scope, and applicable single-use or envelope condition.
8. EP-08 — Fail-closed permission expansion with preserved safe action. Failure of authentication, act binding, sink binding, freshness, replay, policy currentness, revocation currentness, context, authority resolution, fragmentation, or ambiguity checks MUST NOT expand effect authority. A separately protected Safe-Action Set MAY remain available for stabilizing, risk-reducing, or state-preserving action.

Constrained-Beacon, Fragmentation, and Evidence Enforcement

1. EP-09 — Compact BPC remains act- and sink-specific. A Beacon Proof Capsule used on a constrained channel MUST preserve the same exact-act and designated-sink semantics as the fuller execution evidence from which it is derived. Transporting the BPC beside Remote ID, V2X, telemetry, discovery, sidelink, mesh, onboard-bus, or similar traffic MUST NOT turn identification or message possession into effect authority.
2. EP-10 — Truncation has an explicit security budget. A truncated cryptographic representation MUST use a retained bit length selected against collision risk and, for an unkeyed value, feasible offline attacker work. Detection of more than one full commitment mapping to the same compact representation MUST cause denial, escalation to a longer representation, or another fail-closed response.
3. EP-11 — Fragment sets cannot be mixed into authority. Each execution-evidence fragment MUST be bound to a fragment-set or session identifier, common root commitment, fragment index and count, and fragment payload. Fragments associated with different sessions, root commitments, freshness values, policy generations, devices, or Candidate Acts MUST NOT be combinable into valid execution evidence.
4. EP-12 — Incomplete or corrupt reconstruction is non-effective. An incomplete, corrupt, duplicate, ambiguous, or otherwise insufficient fragment set MUST NOT authorize effectuation. Reconstructed evidence MUST still be checked at the Finality Sink against the independently reconstructed actual Candidate Act.
5. EP-13 — Evidence is not authority. An observer-verifiable Act Evidence Record, delayed key disclosure, Evidence Anchor, or Finality Receipt MUST NOT be accepted by a Finality Sink as authority to perform a Candidate Act. Such objects establish evidence about a protected decision; they do not themselves release the effectuation boundary.

Spatial, UAS, and Automated-Vehicle Enforcement

1. EP-14 — Boundary-proximity revalidation. Spatially scoped authority MUST be revalidated early enough that position uncertainty and stopping distance remain inside the authorized region. A representative bound is Delta_r <= (d - epsilon_pos - s_stop) / v, with s_stop = v*tau + v^2/(2*a). When the resulting interval is non-positive, the system MUST withhold further outward motion, reduce the permitted speed, or select a protected safe action.
2. EP-15 — Independent position consistency. When a motion authorization depends on position, the protected enforcement path MAY require agreement from multiple independent or partially independent position sources. Falling below the required agreement threshold MUST remove permission-expanding spatial motion rather than silently treating the last estimate as current.
3. EP-16 — UAS actuation remains envelope-bound. For UAS propulsion, a verified authorization MAY release a bounded PWM, thrust, velocity-vector, motor, or propulsion envelope so that every inner-loop setpoint need not carry a fresh capsule. Commands outside the verified envelope MUST NOT become actuator-effective.
4. EP-17 — Payload effect is bound to the real payload boundary. A payload operation MUST bind the pending operation to the payload identity and payload-effectuation sink and MAY additionally bind release zone, altitude, attitude, mission phase, operator or customer authority, airspace authority, and payload state. The latch, actuator, or associated power-enable path MUST remain disabled when the reconstructed pending operation does not match those bounds.
5. EP-18 — Vehicle motion is admitted as a bounded trajectory or manoeuvre. A vehicle-side motion-admission Finality Sink positioned between the automated-driving or planning component and steering, braking, propulsion, torque, or drive-by-wire control MUST independently derive the trajectory, manoeuvre, or control envelope actually presented for effectuation and admit it only when it matches the protected act binding.
6. EP-19 — Remote movement does not bypass vehicle-local finality. A remotely selected route, fleet command, remote-assistance instruction, or application-originated movement request MUST remain non-effective until the vehicle-local motion-admission boundary verifies the concrete trajectory or control envelope that will actually be admitted to vehicle control. Authentication of the remote source alone is insufficient.

Detect-and-Avoid Enforcement

1. EP-20 — DAA resolution is conflict-set-bound. A proposed avoidance manoeuvre MUST be bound to a deterministic commitment over the policy-relevant intruder set, ownship state, validity condition, current resolution epoch, and target motion-admission sink. Immediately before motion admission, the protected path MUST obtain a current conflict state and reject or recompute when the required conflict-set equivalence or safety predicate no longer holds.
2. EP-21 — Newly relevant traffic invalidates stale resolution. Appearance of a newly policy-relevant intruder, unvalidated disappearance of a required track, excessive track staleness, or uncertainty growth beyond a protected threshold MUST cause the earlier manoeuvre authority to be withheld, narrowed, or recomputed before motion admission.
3. EP-22 — A resolution must remain safe across the relevant set. The protected DAA finalization step MUST evaluate the candidate manoeuvre against the relevant intruders and MUST NOT admit a manoeuvre that resolves one conflict while violating the configured separation margin with another relevant intruder.
4. EP-23 — Resolution epochs prevent stale-controller reuse. Selection of a replacement DAA resolution or a resolution from another authorized DAA source MUST advance protected resolution state so that a previously valid manoeuvre capability cannot remain usable merely because the earlier source credential is still valid.

Emergency-Scene Temporary-Authority Enforcement

1. EP-24 — Emergency authority is scene-bound, motion-bounded, and temporary. A temporary road-rule exception MUST bind the vehicle, incident, scene, permitted exception class, bounded motion envelope, and expiry condition. The vehicle-local protected boundary MUST verify the actual proposed motion against both that envelope and protected local evidence of the physical scene.
2. EP-25 — Higher-risk scene exceptions require protected corroboration. A profile MAY require two or more independent evidence classes before releasing a higher-risk temporary exception. Loss of required corroboration, incident closure, scene exit, expiry, authority revocation, policy-generation change, or single-use consumption MUST invalidate the temporary expansion of motion authority.
3. EP-26 — Perceived responder gestures remain evidence. A perceived hand signal, gesture, voice instruction, light pattern, or other non-verbal responder indication MUST NOT directly become motion authority. It may contribute evidence only after the protected finality path associates it with independently verified responder or incident authority and current scene state.

Atomic Controller-Handover Enforcement

1. EP-27 — Every ordinary control act is controller- and epoch-bound. For each governed motion or actuator sink, protected authority state MUST identify the current ordinary controller and a monotonic authority epoch. An otherwise authenticated ordinary control act MUST be rejected when its controller identity or authority epoch does not match the protected state for that sink.
2. EP-28 — Handover is a protected prepare/commit transaction. A controller handover MUST validate the proposed new controller's scope before atomically advancing the authority epoch and changing the current controller. Queued or precomputed ordinary commands from the prior epoch MUST become unusable after commit, and failure before commit MUST NOT grant ordinary effect authority to the proposed new controller.
3. EP-29 — Split-brain is prohibited per governed sink. Protected authority state MUST prevent more than one ordinary controller from holding effect authority for the same governed sink and epoch. A separately defined safe-action controller MAY remain permitted to issue only stabilizing or risk-reducing actions, including during crash, rollback, reset, or failover recovery.

Informative Satellite and Non-Terrestrial-Network Enforcement The following points apply the same effect-boundary invariant to satellite and non-terrestrial communication systems. They are included as cross-domain examples and do not change the civil UAS and autonomous-motion scope of the remainder of this document.

1. EP-30 — RF and beam activation is exact-operation-bound. A communication Finality Sink associated with a baseband processor, modem, beamformer, phased-array controller, RF chain, gateway-selection function, or transmit-enable path MUST determine the actual communication operation presented for activation and withhold effect unless it matches a binding over the selected satellite or terminal, beam, frequency or channel, transmit-power scope, geographic service region, time scope, and designated communication sink as required by the profile.
2. EP-31 — Satellite, beam, gateway, and path changes are new effect decisions. A transition to a different satellite, beam, gateway, RF configuration, terrestrial-versus-satellite path, or inter-satellite next hop MUST be treated as a different Candidate Act or undergo protected revalidation before effectuation. Previously valid authority for the old communication path MUST NOT automatically authorize the new path when visibility, obstruction, spectrum permission, policy, revocation, or device context has materially changed.
3. EP-32 — NTN verification preserves a bounded communication safe set. Failure to verify a permission-expanding satellite or NTN operation MUST NOT force unsafe expansion of communication authority. A protected communication Safe-Action Set MAY permit continuation of an already verified link, reduced transmit power, receive-only operation, bounded reacquisition, a previously verified fallback link, or communication shutdown according to local policy.

UAS Candidate Act Classes and Finality Sinks Act classes, sinks, and enablement conditions

Act class (code); reuse	Example	Finality Sink	Withheld condition
ARM (0x01); SINGLE_USE	Arm motors for take-off	ESC arming register / enable line	ESC enable asserted
KINETIC_ENVELOPE (0x02); ENVELOPE	Fly segment k within corridor at speed <= v_max	Motor output register bank, thrust limit	Write window for setpoints inside envelope
VOLUME_ENTRY (0x03); SINGLE_USE	Enter geo-zone Z or next corridor segment	Envelope expansion at PED	New envelope released
PAYLOAD_RELEASE (0x04); SINGLE_USE	Lower or release a delivery parcel at drop zone D	Latch solenoid or winch driver	Solenoid power window
SENSOR_ACTIVATE (0x05); ENVELOPE	Camera on, resolution R, field of view F, area A	Camera power rail or sensor-output key	Rail enable or output key
RF_EMIT (0x06); ENVELOPE	Transmit video downlink on band B at power P	Power amplifier enable, frequency register	PA enable, register permit
MODE_TRANSITION (0x07); SINGLE_USE	Switch from assisted to autonomous BVLOS mode	Flight-mode register	Register write permit
RID_CHANGE (0x08); SINGLE_USE	Change RID transmission state	RID module enable and configuration	Configuration write permit
COORDINATED (0x09); Composite child	Formation change across N aircraft	Each aircraft's kinetic sink	Per-child release after composite commit
SAFE_STATE (0x3F); n/a	Hover, loiter, descend, land, return-to-home	Flight controller safe-state path	Pre-authorized (no handle)

RID_CHANGE requests that would suppress legally required RID transmission MUST be denied unless an authority object explicitly permits the change, since the enforcement domain is the component that must not be coercible into making the aircraft anonymous.

Objects Objects are encoded as deterministic CBOR (Section 4.2 of that document) when carried onboard or over constrained links, and MAY be encoded as JCS JSON off-board. Signatures use COSE . The CDDL below uses text keys for readability. The compact integer-key mapping in is the encoding RECOMMENDED on onboard buses. Implementations that speak only the text-key form MUST still produce the same deterministic digest over the integer-key encoding when computing d(U), or declare that they use the text-key encoding for digesting and never mix the two.

UAS Candidate Act Descriptor any } ]]> The descriptor digest is d(U) = SHA-256(det-CBOR(U)) . Only load-bearing fields are included; fields that do not change the effect MUST NOT be added, so that the sink can reconstruct the descriptor from the pending act rather than trusting a caller-supplied digest.

Compact Integer Keys When the compact profile is used, text keys MUST be replaced by the following major integers before deterministic encoding. Unknown keys are rejected. Compact CBOR keys for U-CAD and AAO

Text key	Integer	Object
v	1	U-CAD, AAO, handle, receipt, anchor
act_class / act_classes	2	U-CAD / AAO
ua_det	3	all UA-bound objects
sink_id	4	U-CAD, handle
act_id	5	U-CAD
params	6	U-CAD
ctx_digest	7	U-CAD, receipt
g_air / g_air_min	8	U-CAD / AAO
g_rev / g_rev_min	9	U-CAD / AAO
g_pol	10	U-CAD
aao_digest	11	U-CAD
composite	12	U-CAD
issuer	13	AAO
corridor	14	AAO
envelopes	15	AAO
t_start / t_end	16 / 17	AAO, params
quorum	18	AAO
offline	19	AAO
reuse	20	handle (0=SINGLE_USE, 1=ENVELOPE)
expiry	21	handle
nonce	22	handle
act_digest	23	handle (= d(U))
decision	24	receipt (0=DENY, 1=ALLOW, 2=SAFE)
n	25	receipt counter
prev	26	previous receipt digest
handle_digest	27	receipt
code	28	receipt deny code

Airspace Authority Object any }, ; per act class bounds "g_air_min" : uint, ; lowest acceptable g_air "g_rev_min" : uint, "t_start" : uint, "t_end" : uint, "quorum" : { * uint => uint }, ; act class => required signers "offline" : { "t_max" : uint, "classes" : [* uint] } } corridor = [+ prism] prism = { "poly" : [3* [lat_e7: int, lon_e7: int]], "h_min_dm" : int, "h_max_dm" : int } ; carried inside COSE_Sign1; multiple issuers => COSE_Sign ]]> The AAO is resolved by the PED and never by the mission computer. Possession of an AAO by any software component confers no authority.

Execution Handle and Finality Receipt An Execution Handle in this profile is a COSE_Sign1 (or COSE_Sign, when the AAO quorum requires it) object that binds at minimum:

• d(U) (field act_digest), sink_id, ua_det;
• g_air, g_rev, g_pol as known to the issuer at issuance;
• reuse policy (SINGLE_USE or ENVELOPE), expiry, and a nonce;
• for ENVELOPE, the envelope parameters and any aggregate ceiling (for example D_max).

The handle is non-bearer: possession without a successful consume at the named sink confers no effect. Identical SINGLE_USE handles MUST be refused on the second consume. A Finality Receipt is a PED-signed COSE_Sign1 that binds the decision, d(U) when known, the handle digest when a handle was presented, ctx_digest when a context snapshot was taken, the selected safe state on deny, a monotonic receipt counter n, the previous receipt digest, and, when evidence is emitted, the same 8-octet AER header that was queued. A receipt MUST NOT be accepted as a handle (deny code EF-008). A protected receipt chain may authenticate each committed receipt against the preceding receipt. One representative construction, preserving the provisional receipt-chain invariant, is: Here B_n is the applicable Binding Commitment or equivalent act-bound decision commitment. The exact authenticator is profile-specific; the required property is that deleting, reordering, substituting, or rolling back a committed receipt is detectable by the protected receipt state.

Constrained Execution Proof Capsules This section defines an optional compact transport profile for execution verification over links where the full AAO, full Execution Handle, or complete policy state is too large or too costly to transmit on every act. It is distinct from the Compact Broadcast Act Evidence mechanism of . A BPC is presented before effectuation as verification input. An AER, KDR, Anchor, or Finality Receipt is evidence about a decision and MUST NOT be accepted as a BPC or Execution Handle.

Act, Context, and Binding Commitments The U-CAD already provides the canonical Candidate Act U and d(U). For a BPC, the PED additionally forms a selected Context object Ctx containing only state material to the effect, for example corridor or geo-zone generation, geographic cell, altitude band, mission phase, payload state, flight mode, RF mode, and policy or revocation state. Exact coordinates need not be broadcast. K_bind is held or derived inside the PED and the verifying Finality Sink and is unavailable to the mission computer, ordinary transmitter, and other act-proposing components. A deployment may use an unkeyed binding only where the retained length is sized against the offline substitution budget in . Changing a load-bearing act field, sink, authority, generation, context, freshness value, or expiry therefore changes the expected binding. Binding(A, Sink_2) != Binding(A, Sink_1) except with the bounded cryptographic collision probability ]]>

Session-Key Derivation and Key Separation A deployment may derive distinct capsule-authentication and act-binding keys from a common protected root. A representative derivation is: The derivations intentionally use different domain-separation labels and different scope inputs. K_B authenticates the compact transport object; K_bind binds execution semantics to the act and Finality Sink. Disclosure or compromise of one derived-key role therefore does not intentionally collapse the two roles. Equivalent KDFs may be used where they provide the same separation property. Key evolution used for ordinary undisclosed session keys is distinct from the reverse chain used for delayed-disclosure evidence. A forward erasure ratchet may evolve as: Because disclosure of K_i would reveal all later values in that construction, a forward ratchet MUST NOT be used as the delayed-disclosure evidence chain of . That evidence chain runs in the reverse direction so that disclosure authenticates past intervals without revealing later undisclosed evidence keys.

Compact Authority References A BPC need not carry the AAO in full. The PED may maintain an authenticated local cache of AAOs and use a compact Authority Reference. A preferred keyed construction first derives a stable full digest of the deterministic AAO payload and then derives a short reference under a protected reference key K_R: K_R is not available to the mission computer or ordinary beacon transmitter. An unkeyed reference may be used only when r is selected using an applicable attacker-work budget. Resolution MUST occur in or under control of the PED or Finality Sink. Unknown, stale, ambiguous, revoked, or unresolved Authority References MUST NOT authorize effectuation.

Representative BPC and Field Compression A representative BPC contains the following logical fields. The precise byte layout is profile-specific; fields may be implicit from protected session state, dictionary-indexed, delta-encoded, or recovered from local state. This version defines no IANA allocation for BPC profiles. Non-limiting compression includes compact act and sink dictionaries, a 32- or 64-bit Authority Reference, expiry delta instead of an absolute timestamp, corridor or geo-cell references instead of coordinates, a compact Context Commitment, and bitmaps for authenticated predicate state. A predicate bitmap is advisory unless covered by the capsule authenticator and never substitutes for the sink's own protected checks.

Truncation, Collision, and Attacker-Work Budgets Truncation length is selected explicitly rather than by convenience. Let t be the retained number of Binding Commitment bits and q the approximate number of distinct commitments in the relevant collision domain. The birthday estimate for accidental coincidence is: = ceil( log2( q(q-1) / (2 * epsilon_c) ) ) ]]> For an unkeyed commitment whose inputs are known or predictable, an attacker may search offline for a substituted act producing the same short value. With W offline trials: = ceil( log2( W / epsilon_s ) ) ]]> For a keyed binding where offline search is unavailable without K_bind, a targeted attacker is limited to online attempts that encounter freshness and replay controls: These expressions size compact fields; they are not an airworthiness or total system-failure probability. The selected t therefore depends on safety class, act rate, fleet size, session lifetime, replay-cache lifetime, whether the binding is keyed, and the accepted attempt budget. Higher-consequence act classes may use longer compact commitments. If a receiver's protected cache or reconstruction process finds more than one full candidate consistent with the same short value, it MUST NOT choose one heuristically. It MUST deny the consequential act or escalate to a profile carrying a longer commitment or full proof. Ambiguous Ambiguous => Effectuate(CandidateAct) = FALSE ]]>

Capsule Authentication In addition to B_t, the BPC is authenticated as a complete transport object. A symmetric constrained profile may compute: K_B is a protected session or link key. For an expected aggregate attacker verification budget A and permitted aggregate forgery probability epsilon_f, a deployment can select: = ceil( log2( A / epsilon_f ) ) ]]> Other authenticated constructions may be used where their security and field sizes meet the applicable profile. The capsule authenticator protects the transport representation; B_t separately binds the execution semantics to the actual act and sink.

Authenticated Multi-Frame Reconstruction If a complete BPC or its referenced proof material does not fit one transport unit, it may be fragmented. Let P be the complete encoded proof and p_i its ordered fragments. A protected sender computes: No individual fragment is execution authority. The verifier MUST authenticate the required fragment set, require a common SessionID and Root, reconstruct the ordered proof, and verify the Root before continuing normal finality verification. A fragment from another session, root, fragment count, policy generation, or device context MUST NOT be mixed into the reconstruction. NoEffectuation FragmentsReceived < RequiredFragments => Effectuate(CandidateAct) = FALSE Verify(BPC) != TRUE => Effectuate(CandidateAct) = FALSE ]]> A missing or corrupted fragment, unknown Authority Reference, unresolved context reference, stale generation, invalid capsule tag, ambiguous sink, collision-guard trigger, absent freshness state, or incomplete reconstruction therefore leaves the consequential Candidate Act non-effective. Safe-State Set actions remain available.

Resolver-Assisted and Cache-Assisted Verification A protected resolver may be used when the constrained link carries only an Authority Reference and compact commitment. The PED supplies at least the Authority Reference, Binding Commitment or compact value, UA reference, current generation information, and requested act class. The resolver may return the resolved AAO and authenticated resolver proof. The resolver does not decide the physical act; the PED and Finality Sink still reconstruct the actual impending U-CAD and apply current local state. UNKNOWN is not EMPTY and is not authorization. A cache miss or resolver failure MUST result in no permission expansion; the PED may hold, request refresh, use a permitted Safe-State Set action, or require a full AAO over another authenticated path.

Sink-Side BPC Verification The sink never trusts an upstream description of the act merely because the BPC authenticated correctly. It independently reconstructs the pending U-CAD and recomputes the expected binding from actual local command and actuator state.

Separation of Execution Proof and Observer Evidence The BPC and AER mechanisms serve opposite directions of trust. A BPC is consumed before effectuation to help determine whether the exact impending act may become effective. An AER is emitted only after the PED has committed an allow, deny, or safe-state receipt and is later verified by Observers. Accordingly: x NOT IN {Receipt, AER, KDR, Anchor} TreatAsObserverEvidence(BPC) => FALSE unless separately profiled as evidence ]]> This role separation is load-bearing. Replaying a valid AER, KDR, Anchor, or Finality Receipt at a sink cannot create execution authority, and possession of a BPC cannot be used to claim that the corresponding physical act actually occurred.

Finality Sink Processing The following non-normative pseudocode shows the processing order. The order is normative: static verification, then reading current state and consuming inside one atomic section, then committing the receipt, then releasing.

Core Finality Predicate and Atomic Ordering A representative conjunction for the BPC path is: Additional act-class predicates may strengthen this conjunction. No omitted predicate is implied to be optional where another section requires it. The replay and receipt state transitions precede capability release: Accept(N) = FALSE CapabilityReleased => NonceConsumed AND ReceiptCommitted ReadCurrentEpochs <= ConsumeNonce <= CommitReceipt(n) < ReleaseCapability < Effectuate(A) Epoch_presented != Epoch_current(read inside commit) => Effectuate(A) = FALSE unless an explicitly defined compatibility rule applies ]]> Within the ordering artwork, X < Y means that X strictly completes before Y may occur, while X <= Y means that X occurs no later than Y and may be ordered within the same protected atomic transaction. These symbols express required happens-before relationships rather than wall-clock duration. Current policy and revocation state used for the deciding result are read inside the protected commit, not only during an earlier pre-check. Where the verifying PED and physical actuator boundary are separate, successful verification may derive a short-lived sink-local capability: Verify_KS(E) ]]> K_S is the protected sink-local capability-authentication key defined in . E is local bounded execution authority, not a transferable bearer token; it is scoped to the verified Binding Commitment, sink, actuator envelope, and protected counter state.

Reference Finalization Procedure A denial MUST NOT cause loss of controlled flight. Denial of a payload act keeps the latch locked and continues flight; denial of a sensor act removes sensor power while preserving navigation sensors; denial of a volume entry holds or reroutes; denial of a kinetic envelope clamps to the last valid envelope or begins a controlled descent according to .

Representative Hot-Path Cost Model For a locally cached authority path, a representative verification latency may be decomposed as: This is an implementation cost model, not a mandated latency target. It makes explicit why certificate-chain validation, resolver synchronization, and complex policy parsing are preferably cold-path operations while the actuation hot path uses bounded local checks.

Envelope Handles for High-Rate Streams Motor setpoints are issued at hundreds of hertz; per-setpoint handles are neither necessary nor practical. An Envelope Handle authorizes the set and every setpoint u_j at time t_j is admitted by the sink-side comparator if and only if u_j is in E and t_j is in W and the aggregate ceiling is not exceeded, for example cumulative distance D_j = sum over i <= j of |p_i - p_(i-1)| <= D_max. This check is a set of range comparisons that can be implemented in FPGA logic or a secure microcontroller within one control period. Leaving E, leaving W, or exceeding the ceiling ends the envelope; further motion requires a new handle or a safe state. Identical repeats of a SINGLE_USE handle MUST be refused.

Live-Context Predicates and Mathematics This section states predicates and conservative scheduling relationships used by the PED. They are protocol-policy inputs, not airworthiness or certification formulas. Notation: p(t) is the UA position in a local East-North-Up frame derived from trusted sources; Corridor_k is the permitted volume for segment k; d(t) is the signed horizontal-or-vertical distance from p(t) to the nearest boundary of Corridor_k (positive inside); v_max is the envelope speed bound; a_brk is a conservative guaranteed deceleration value established for the applicable airframe/state by protected configuration or attested safety data; tau is a conservative upper bound on sensing, PED, controller, and actuator reaction delay; and eps_pos is the position uncertainty bound.

Corridor Containment and Envelope Predicates Starred quantities are read inside the atomic section of . P_sensor uses the projected sensor footprint rather than aircraft position, because a camera outside a protected area can still image inside it.

Boundary-Proximity Revalidation Bound Envelope authority is revalidated at an interval Delta_r. Between two revalidations the aircraft can move at most v_max * Delta_r, and after a failed revalidation it needs a stopping distance For the aircraft never to leave Corridor_k undetected, the following condition is sufficient: Delta_r(t) <= ( d(t) - eps_pos - s_stop(v_max) ) / v_max ]]> When this scheduling profile is selected, the PED MUST use conservative, protected values for a_brk, tau, and eps_pos and schedule the next revalidation no later than the resulting Delta_r(t). A deployment MUST substitute a more conservative certified or safety-engineered stopping model where the point-mass expression is not adequate. If the right-hand side is less than or equal to zero, the PED MUST NOT release further outward motion and MUST either reduce v_max or select a safe state. The revalidation rate therefore rises near boundaries and may fall in the interior. Worked example: d = 60 m, eps_pos = 5 m, v_max = 15 m/s, a_brk = 5 m/s^2, tau = 0.1 s gives s_stop = 1.5 + 22.5 = 24 m and Delta_r <= (60 - 5 - 24) / 15 = 2.07 s; at d = 30 m the bound is 0.07 s and the PED instead lowers v_max to 8 m/s, giving s_stop = 7.2 m and Delta_r <= 2.23 s. Revalidation is also triggered by events, independent of Delta_r: arrival of a new generation, waypoint transition, altitude-band change, payload-state change, RF-mode change, sensor disagreement, and battery or thermal threshold crossings.

Multi-Source Position Consistency Given m independent position sources with estimates p_i and stated one-sigma uncertainties sigma_i, the PED computes the fused estimate p_hat and requires = q_min (q_min >= 2 RECOMMENDED) ]]> with k a positive profile-selected uncertainty multiplier (for example 3), q_min the minimum number of sufficiently independent or partially independent sources that must agree, and |.| denoting the profile's applicable spatial-distance norm. Disagreement is treated as insufficient location confidence: no envelope expansion, no volume entry, no payload release, no sensor activation over area-scoped permissions. A single spoofed GNSS source that diverges from visual-inertial odometry or barometric altitude beyond the bound therefore removes authority rather than steering it.

Ordering and Residual-Risk Decomposition For every allowed act the following ordering holds: The remaining risk is usefully decomposed, but this document does not assign a single numerical probability bound to the complete cyber-physical system. Relevant contributors include cryptographic collision or forgery risk (eps_hash, eps_sig), protected-state or crash-consistency failure (eps_store), an unmodelled or bypassing consequence path (eps_path), and trusted-context failure within the accepted tolerance (eps_ctx): The cryptographic terms may be made negligible under their stated assumptions; eps_path and eps_ctx are engineering and assurance quantities, not cryptographic constants. In particular, eps_ctx depends on sensor independence, q_min, stated uncertainty, environmental conditions, and the applicable threat model. The decomposition is intended to expose these assumptions rather than to present an airworthiness or certification probability.

Mid-Flight Generation Changes A new airspace generation g_air' (for example activation of a temporary restriction) can arrive through Network RID services, a USS or USSP, or a data link. On receipt, the PED verifies its signature and monotonicity (g_air' > g_air*), atomically updates g_air*, and evaluates the delta against every outstanding handle: A UA that has not received a generation cannot enforce it. This is why the offline bound of exists and why AAOs carry g_air_min: an authority can refuse to issue handles to an aircraft whose last acknowledged generation is stale.

Degraded Link and Bounded Offline Operation At link loss time t_L the PED enters offline mode. In offline mode it MAY continue to honour handles that were already issued, only for act classes listed in the AAO's "offline.classes", and only until after which only S_safe is permitted. New handles MUST NOT be created offline for SINGLE_USE classes other than those listed. PAYLOAD_RELEASE and SENSOR_ACTIVATE SHOULD NOT be listed as offline classes. Receipts are appended to a sealed local buffer protected by the monotonic counter and are reconciled when the link returns. The residual exposure to a revocation or restriction issued after t_L is therefore bounded and computable: Operators and authorities can choose T_off_max per operation class. This converts "the aircraft kept flying on cached authority" into a stated, auditable bound.

Fail-Closed Safe States Denial causes and default safe-state selection

Condition	Kinetic effect	Other subsystems
Volume entry denied / generation affects corridor	Hold (multirotor hover, fixed-wing loiter) or reroute inside last valid corridor	Unchanged
Payload predicate fails	Continue flight	Latch locked, solenoid unpowered
Sensor predicate fails	Continue flight	Camera power removed; navigation sensors kept
RF predicate fails	Continue flight	Payload radio silent; command-and-control and RID links kept
Location confidence low	Hold, then controlled descent if not recovered in T_loc	Payload locked, area-scoped sensors off
Envelope exceeded	Clamp to envelope, or controlled landing if clamping is unsafe	Unchanged
Offline window expired	Return-to-home or land at nearest pre-approved site	Payload locked
Consume or receipt store unavailable (EF-081)	Hold, then land	All non-safety sinks disabled

S_safe is fixed in PED firmware or FPGA logic and is part of the attested measurement. It cannot be widened by the mission computer. Safe-state manoeuvres use the flight controller's existing stabilization and landing logic. Available(a) regardless of Verify(BPC) ]]> The invariant applies only to the pre-authorized stabilizing or risk-reducing action set; failure of ordinary authorization therefore does not itself remove the protected means to maintain or reach a safe state.

Commands from Authenticated Sources A command from a ground station, fleet service, or remote pilot that is correctly signed is treated as a Candidate Act, not as authority. The PED evaluates it against the same predicates. A validly signed command to enter a restricted volume, release a payload outside a drop zone, exceed an envelope, activate a sensor over a protected area, disable RID, or join an unauthorized coordinated act is denied. For act classes that the AAO marks with a quorum, the handle MUST carry the required COSE_Sign signatures (for example remote pilot plus fleet safety authority plus payload authority). | { A_i : Verify(A_i) = TRUE } | >= k ]]> The threshold result is still only one input to finality: the exact act, sink, freshness, current epochs, and live context remain independently verified.

Multi-Aircraft Coordinated Acts A coordinated act across N aircraft (formation change, synchronized handoff of an inspection segment, simultaneous corridor swap) follows with the ALL_REQUIRED join rule and the following UAS-specific constraints.

1. Prepare never moves an aircraft. Prepare reserves consume state for the child handle and verifies predicates for the post-act envelope; the current envelope stays in force.
2. Each child PED releases its new envelope only after reading COMMIT for the composite identifier from the composite decision log.
3. HOLD is a physical holding manoeuvre within the current envelope, not an idle software state. A fixed-wing child holds by loitering inside its current corridor.
4. If the decision log is reachable and empty when a child's reserve expires, the child writes ABORT by compare-and-swap (first writer wins). If the log is unreachable, the child holds (EF-048) and never commits on silence.
5. Compensation (for example returning to the original formation) is a new Candidate Act with new handles, never a reuse of consumed ones.

Composite states for a coordinated act PREPARED --log COMMIT--> EFFECTUATED | | \ | any prepare fails | \--log unreachable--> HOLD v v | ABORTED <-- CAS ABORT on reserve expiry (log reachable) <------+ (log returns) ]]>

Each participating unit also derives its own act/sink/context binding. One representative per-unit construction is: A common high-level coordinated proposal therefore does not create transferable authority between units; a proof valid for unit i does not automatically authorize unit j. For the informative autonomous-road-vehicle application, a cooperative manoeuvre negotiated between vehicles or roadside infrastructure may use a more specific participant binding: D_M is the digest of the agreed manoeuvre and TrajDigest_v is the trajectory envelope assigned to vehicle v. The vehicle motion-admission sink reconstructs the trajectory actually produced by its planner and admits it only on match. For an all-required cooperative manoeuvre, the protected HOLD state is the current lane-and-speed envelope or another profile-defined minimal-risk state. No-split property: because every child release requires reading the same committed log entry, and the log accepts exactly one of COMMIT or ABORT per composite identifier, no execution exists in which one child effectuates under COMMIT while another effectuates under ABORT. Liveness depends on log reachability; safety does not.

Conflict-Set-Bound Detect-and-Avoid Maneuver Finality

Technical Problem A DAA system can correctly identify an intruder and compute a valid resolution maneuver at an initial time, while the traffic picture changes before that maneuver reaches the motion-admission boundary. A second intruder can become relevant, a track can move or be reclassified, uncertainty can expand, a surveillance source can become stale, ownship state can diverge, or another DAA source can supersede the earlier resolution. Authentication of the original DAA output proves neither that its safety basis is still current nor that the trajectory actually presented to the flight controller is the trajectory that was evaluated. The profile therefore does not reduce DAA finality to "check for collisions before moving". It binds the accepted resolution to the complete policy-relevant Conflict Set, ownship state, Resolution Epoch, motion sink, and validity horizon on which the resolution was computed. Immediately before motion admission, the protected domain reconstructs the current Conflict Set and the actual impending motion and refuses effectuation if the accepted safety basis is no longer equivalent.

Architecture and Protected State

Conflict-set-bound DAA finality +----> Safe-Action Set ]]>

The DAA engine may remain ordinary or high-performance software. It computes proposed resolutions but does not itself hold the final actuator authority. The protected DAA Finality Domain maintains at least the canonical Conflict Set or an authenticated membership representation, its Conflict-Set Root, protected ownship state, source-health and freshness state, the current Resolution Epoch, nonces or sequence state, and the receipt state used by the motion-admission sink. For each policy-relevant intruder j, a canonical descriptor may include track reference, source class, cooperative or non-cooperative class, relative position, relative velocity, acceleration estimate where used, covariance or bounded uncertainty, freshness, closest-point-of-approach quantities, track confidence, provenance reference, and an encounter or right-of-way class. Descriptors are deterministically sorted before the Conflict-Set Root is computed.

Conflict-Set and Safety Mathematics A DAA Resolution Descriptor binds at least C_root, an ownship-state commitment, the proposed maneuver or trajectory-tube digest, the Resolution Epoch, the motion-admission sink, a validity horizon, the applicable safety profile, sensor-source epochs, policy and revocation state, freshness, and a nonce. One non-limiting constant-velocity safety check for intruder j is: min_j m_j(M) >= 0 ]]> r_j and v_j are relative position and velocity, T is the prediction horizon, D_req,j is the required separation for the encounter class, and epsilon_j is a conservative margin for surveillance uncertainty, state-estimation error, latency, and applicable model error. This document does not require constant-velocity CPA; a certified DAA algorithm, reachable-set method, probabilistic conflict model, velocity-obstacle method, well-clear logic, or another deterministic safety predicate may replace it. The load-bearing requirement is multi-intruder atomicity: a maneuver accepted to resolve one conflict does not obtain authority if it creates or leaves an unacceptable conflict with another policy-relevant track.

Current Conflict-Set Equivalence Exact set equality is the strongest profile, but an implementation may define a deterministic equivalence predicate that admits bounded changes proven not to invalidate the resolution. A newly relevant intruder, a removed track without a trusted termination reason, stale source state, material uncertainty expansion, or a changed encounter class SHOULD force recomputation unless the selected profile defines and verifies a safe equivalence rule.

Resolution Epoch and Competing DAA Sources When airborne DAA, ground-based DAA, UTM conflict services, autopilot obstacle avoidance, or a remote pilot can each propose a resolution, the protected domain maintains a monotonic Resolution Epoch. Superseding the accepted resolution increments the epoch and invalidates all ordinary motion capabilities bound to the prior epoch. M.resolution_epoch == CurrentResolutionEpoch ]]> This prevents two individually authenticated or individually valid DAA outputs from simultaneously steering the aircraft under different traffic snapshots.

DAA Finality Workflow

1. Acquire protected ownship state and cooperative and non-cooperative traffic state, including source provenance, freshness, uncertainty, and source health.
2. Classify policy-relevant tracks for the applicable horizon, canonicalize their descriptors, and compute the Conflict-Set Root.
3. Allow the DAA engine to compute candidate resolutions, but keep each resolution non-effective.
4. Bind the selected resolution to the Conflict-Set Root, ownship state, Resolution Epoch, motion sink, trajectory digest, safety profile, horizon, freshness, and current authority state.
5. Evaluate the selected maneuver against every relevant intruder and create a prepared finality record if the selected safety predicate succeeds.
6. Immediately before motion admission, rebuild the current policy-relevant Conflict Set and current ownship state from protected sources.
7. Reject or recompute if the Resolution Epoch changed, the Conflict Set is not equivalent, required source state is stale, or any current safety margin fails.
8. Atomically commit the finality record and release a trajectory-envelope capability bound to the current Resolution Epoch and motion-admission sink.
9. The sink reconstructs the actual trajectory envelope presented by the planner and admits it only when it matches the authorized envelope and the epoch is still current.
10. Any later conflict-set change, source-health failure, policy change, epoch advance, or expiry invalidates the outstanding motion capability and leaves the Safe-State Set available.

DAA Finality Pseudocode = 0 PREPARE_DAA_FINALITY(descriptor) BEGIN ATOMIC own_now := READ_PROTECTED_OWNSHIP() C_now := BUILD_CURRENT_RELEVANT_CONFLICT_SET() epoch := CURRENT_RESOLUTION_EPOCH() IF epoch != descriptor.resolution_epoch: ABORT RECOMPUTE("RESOLUTION_EPOCH_CHANGED") IF NOT CONFLICT_EQUIVALENT(C_auth, C_now): ABORT RECOMPUTE("CONFLICT_SET_CHANGED") FOR EACH intruder j IN C_now: IF SAFETY_MARGIN(candidate_M, own_now, j) < 0: ABORT RECOMPUTE("CURRENT_MARGIN_FAIL") R := COMMIT_DAA_RECEIPT( descriptor_digest = HASH(descriptor), current_conflict_root = ROOT(C_now), resolution_epoch = epoch) END ATOMIC actual_M := RECONSTRUCT_ACTUAL_TRAJECTORY(sink) IF NOT MATCHES_AUTHORIZED_MOTION(actual_M, candidate_M): RETURN SAFE_DENY("DAA_TRAJECTORY_SUBSTITUTION") RELEASE(sink, MOTION_CAPABILITY(HASH(actual_M), epoch, HASH(R))) RETURN ALLOW ]]>

Emergency-Scene Temporary Authority Finality

Technical Problem This subsection is an informative cross-domain application to autonomous road vehicles. At an emergency scene, a police officer, firefighter, road worker, or other authorized responder may legitimately request a vehicle to perform a motion that ordinary road policy would reject: cross a lane marking, reverse, stop in an unusual position, enter a temporarily restricted lane, or follow a temporary path around an incident. Simply authenticating the responder does not establish that the instruction applies to this vehicle, this incident, this scene, this concrete motion, or the present time, and should not create unrestricted remote-driving authority. The profile therefore creates temporary authority that is incident-bound, scene-bound, vehicle-bound, act-bound, sink-bound, time-bounded, independently corroborated by local scene evidence, and automatically extinguished when the applicable scene condition ends.

Emergency Scene Authority Capsule

Scene-bound temporary motion authority invalidate authority ]]>

An Emergency Scene Authority Capsule (ESAC) may bind the vehicle identifier, responder role and authority reference, incident identifier and incident epoch, emergency-scene identifier, scene polygon or scene commitment, instruction class, permitted path or trajectory digest, speed and acceleration envelope, explicit traffic-rule exception class, start time and expiry, scene-evidence commitment, policy and revocation epochs, motion sink identifier, and nonce. The responder identity is necessary but not sufficient. The protected vehicle domain independently derives local scene state from available protected or corroborated sources, for example emergency-vehicle presence, responder presence, temporary signs, lane closure, cone geometry, road blockage, fire or smoke scene, infrastructure state, or another profile-defined scene signal. Perception output alone is evidence and does not directly unlock steering, throttle, or braking authority.

Scene and Authority Mathematics The emergency-scene profile preserves separate mathematical treatment of scene commitment, corroboration, temporary-authority validity, geographic scope, motion admissibility, and automatic authority extinction. These predicates are conjunctive at the finality boundary; responder authentication alone is not sufficient. A representative scene commitment is: Local physical corroboration may be represented by q-of-n protected validation results. Let v_i be 1 when independent evidence channel e_i satisfies its profile-defined validation rule and 0 otherwise: sum_i v_i >= q ]]> A profile SHOULD prevent multiple messages or observations derived from the same physical source from being counted as independent evidence. Higher-consequence exception classes may require both valid responder authority and at least one independent local physical confirmation. Let E(t) denote whether the temporary emergency authority is effective at time t. One representative validity rule is: For a location-bounded emergency scene, localization uncertainty may be incorporated by dilating the authorized scene polygon by a conservative margin delta_loc: The Candidate Emergency Maneuver M may become effective only when temporary authority remains valid, the requested traffic-rule exception is explicit, the actual reconstructed motion lies within the emergency envelope, hard safety predicates remain satisfied, and finality-specific sink and epoch checks succeed: ActualMotionMatch(M) is evaluated over the motion reconstructed at or adjacent to the motion-admission Finality Sink, rather than solely over an upstream responder instruction or planner description. SinkMatch requires that the temporary authority name the same governed motion-admission sink that would make the act effective. PolicyEpochCurrent and RevocationEpochCurrent are evaluated against protected current state. The temporary exception is narrowly scoped. It authorizes only the concrete exception and motion envelope expressed by the ESAC; it does not disable ordinary hard safety predicates or create a standing override. TemporaryAuthority := INVALID ]]> Automatic extinction is load-bearing. A cryptographically valid ESAC that is replayed outside its incident, scene, vehicle, epoch, path, validity window, or named Finality Sink cannot authorize effectuation. Loss of required local corroboration also removes the temporary permission expansion while preserving the applicable Safe-State Set.

Emergency-Scene Workflow

1. Receive or resolve a responder or incident authority artifact and verify the responder role, authority reference, revocation state, incident identifier, and incident epoch.
2. Construct or receive an ESAC that states the vehicle, scene, permitted instruction class, concrete path or envelope, bounded traffic-rule exception, sink, expiry, epochs, and nonce.
3. Keep the requested exception non-effective while the vehicle derives protected local scene state independently of the responder message.
4. Verify that local scene evidence sufficiently corroborates the incident and scene commitment required by the ESAC.
5. Reconstruct the actual planned motion at the motion-admission sink rather than trusting an upstream path label.
6. Verify that the actual motion is within the emergency envelope, that every traffic-rule departure is expressly covered by the exception class, and that ordinary hard safety predicates still hold.
7. Atomically consume freshness, commit an emergency finality receipt, and release a single-use or short-lived motion capability bound to the incident, scene epoch, actual motion digest, exception class, and sink.
8. At the sink, re-check expiry, incident and scene epoch where applicable, and the actual motion before admission.
9. On completion, expiry, scene exit, incident closure or change, revocation, required-corroboration loss, or policy change, invalidate all temporary scene capabilities and restore ordinary road authority.

Emergency-Scene Pseudocode

Atomic Control-Authority Handover and Split-Brain Prevention

Technical Problem An autonomous motion platform can have multiple controllers that are each individually legitimate: an autonomy stack, remote pilot, remote-assistance service, fleet controller, DAA safety controller, local human operator, emergency authority, or minimal-risk controller. The critical failure is therefore not only an unauthorized controller. Network delay, partial handover, retry, failover, duplicated sessions, stale credentials, or recovery can leave two authorized controllers believing that each controls the same steering, thrust, braking, trajectory-admission, or mode-transition boundary. This profile treats control transfer itself as a Candidate Act. Protected state records the Current Controller and Control Authority Epoch for each governed sink or sink class. PREPARE, COMMIT, and ENABLE semantics change this state transactionally, and every ordinary control command is accepted only when its controller identity and epoch match current protected authority state.

Protected Authority State

Atomic controller handover COMMIT(epoch e+1) -> ENABLE(B) partial failure -> Safe-Action Set ]]>

The state may be maintained per vehicle, actuator class, motion-admission sink, or another control domain. Independent non-conflicting sinks may have different Current Controllers, but sinks whose simultaneous control can conflict MUST enforce exclusivity through the same protected authority state.

Exclusivity and Acceptance Mathematics Let A(c,s,e,t) be 1 when controller c has ordinary effectuation authority over sink s in epoch e at time t and 0 otherwise. The exclusivity invariant is: A separately defined Safe-State Set does not violate this invariant when it is restricted to stabilizing or risk-reducing actions and cannot expand ordinary authority. cmd.controller_id == CurrentController[s] AND cmd.epoch == CurrentEpoch[s] AND cmd.sink_id == s AND cmd.act IN CurrentEnvelope[s] AND Fresh(cmd) ]]> A credential that remains cryptographically valid after a handover does not preserve actuation authority if its controller identifier or epoch is stale.

Transactional Handover A preferred handover has three logical phases. PREPARE verifies the proposed new controller, its requested sink set, authority basis, freshness, revocation state, and requested control envelope while the old controller remains responsible for bounded continuity. COMMIT atomically increments the Control Authority Epoch, marks the old ordinary-control binding stale, records the new Current Controller and envelope, and commits a handover receipt. ENABLE permits the new controller to submit ordinary commands under the committed epoch. ACTIVE(A,e) or SAFE | v COMMIT(B,e+1) | +--> all A/e ordinary commands become stale v ENABLE(B,e+1) ]]> If the system fails after PREPARE but before COMMIT, the proposed new controller has no effectuation authority. If COMMIT occurred but readiness of the new controller cannot be established, the system enters a bounded Safe-State Set or requires a new handover; it does not resurrect the prior epoch merely because an old controller continues transmitting.

Control-Handover Workflow

1. Maintain protected per-sink state identifying the Current Controller and Control Authority Epoch.
2. Receive a handover request naming the proposed new controller, governed sink set, act classes, control envelope, duration, authority basis, and reason.
3. Authenticate or attest the proposed controller or remote session and check role, revocation, and freshness.
4. Validate the requested control envelope against current vehicle or aircraft state, operational domain, safety limits, and policy.
5. Enter PREPARE and persist the proposed controller and envelope without granting ordinary effectuation authority.
6. Optionally freeze authority expansion by the old controller while preserving bounded continuity and the Safe-State Set.
7. Confirm readiness of the proposed controller and establish fresh proof-of-possession when required.
8. Atomically increment the Control Authority Epoch, invalidate the old ordinary-control binding, install the new Current Controller and envelope, and commit a handover receipt.
9. Only after COMMIT issue or enable the new controller capability.
10. Every governed sink rejects a command whose controller, epoch, sink, act class, envelope, expiry, or freshness state differs from protected authority state.
11. Queued or precomputed commands from prior epochs are rejected unless they are separately reclassified as Safe-State Set actions under current state.

Control-Handover Pseudocode

Compact Broadcast Act Evidence for DRIP

Technical Problem DRIP lets an Observer verify that Broadcast RID messages come from the registered owner of a DET, including when the Observer has no Internet access . The Observer still cannot verify whether an act it can see was decided by the aircraft's enforcement domain before it became effective. Four constraints make a direct approach impractical:

1. Size. Broadcast RID messages are 25 octets. A per-act public-key signature (64 octets for Ed25519) plus identifiers and timestamps spans several Authentication Message pages.
2. Loss. Legacy transports lack forward error correction; paged Authentication Messages can lose pages, and DRIP FEC recovers only a single lost page .
3. Rate and cost. Consequential acts and decisions (envelope renewals, sensor toggles, denials) can occur several times per second; public-key signing at that rate is a material computational and energy load for small onboard controllers.
4. Origin. The DET key is often held by the RID module or the flight software. Evidence signed with that key shows that the aircraft's software sent it, not that the enforcement domain decided it. A compromised mission computer holding the RID key could broadcast "authorized" evidence for acts the PED never allowed.

The mechanism below addresses all four: fixed 16-octet records, loss-tolerant delayed key disclosure, symmetric per-record authentication, and a protected master seed that never leaves the PED.

Design The design applies the TESLA delayed key disclosure principle to act-decision records. The default profile uses a distinct PED evidence-signing key; the aircraft's DRIP/HI identity endorses that evidence key once for its validity interval. The mission computer and RID module do not hold the undisclosed evidence-chain keys. At the start of an evidence epoch the PED generates a random master seed K_seed that is never disclosed, derives the terminal chain value K_N from K_seed and epoch_id, and then derives the reverse one-way chain down to K_0. K_seed may be erased after K_N and the chain state are securely established. Time is divided into intervals of length Delta starting at T_0 (GNSS or UTC time). K_0 is a public chain commitment carried in the signed Anchor and is never used directly or through F' as an AER tag key. Records emitted in zero-based interval i are authenticated with K'_i = F'(K_(i+1)). K_(i+1) is broadcast d intervals later. An Observer accepts a record only if it arrived before the key for its interval could have been disclosed, and verifies it once the key arrives. A signed Anchor and Evidence Key Endorsement bind the chain to the PED evidence key and to the UA's DET.

Evidence key chain and delayed disclosure K_N --F--> ... --F--> K_1 --F--> K_0 K_seed is never disclosed; K_0 is the public chain commitment. use (time runs left to right): interval: | 0 | 1 | 2 | 3 | 4 | 5 | ... records: AER AER AER AER AER AER tagged with: K'_0 K'_1 K'_2 K'_3 K'_4 K'_5 derived from: K_1 K_2 K_3 K_4 K_5 K_6 disclosed: K_1 K_2 K_3 (d = 3) Anchor (signed once, repeated): {DET, PED key id, T_0, Delta, d, N, K_0, ...} A lost disclosure for interval i is recovered from any later interval j: K_(i+1) = F^(j-i)(K_(j+1)) ]]>

Default Endorsement Path The default, and the only path specified as interoperable in this version, is:

1. The PED generates and seals a distinct evidence-key pair. That key never leaves the PED. It is not the DET / Host Identity key.
2. The UA Host Identity key (the key corresponding to the DET) signs an Evidence Key Endorsement binding ua_det, ped_kid, and ped_pub for a validity window. That endorsement is a DRIP-compatible statement of "this PED evidence key speaks for this DET".
3. The PED signs each epoch Anchor with the evidence key.

This document does not use "PED holds the DET key" as a default. On typical airframes the DET key is in the RID module or flight software, which is the component whose compromise this mechanism exists to survive. An implementation in which the PED is also the DET key holder is a degenerate case of the same endorsement (self-endorsement) and adds no Observer-visible format.

Construction HMAC is as defined in , SHA-256 as in . Domain-separation strings prevent the master-seed derivation, chain function, tag-key derivation, and record MAC from being confused with one another or with other protocols. K_seed is not a chain value and is never included in an Anchor, KDR, AER, receipt, or ordinary transmitter state. Chain values K_1 through K_N may become public only according to the disclosure schedule. K_0 is deliberately commitment-only. Because K_0 is public in the Anchor, using F'(K_0) as an interval tag key would make the corresponding interval forgeable by any Observer. The zero-based AER interval i therefore uses K_(i+1), while K_0 remains solely the authenticated chain root.

Record Formats

Act Evidence Record (AER), 16 octets

Key Disclosure Record (KDR), 19 octets

A 16-octet AER and a 19-octet KDR each fit within the data area of a single 25-octet Broadcast RID message before transport framing. The first page of an F3411 Authentication Message carries additional header fields; exact page packing and carriage are left open in this version (see ). The Interval Index is an unsigned 16-bit index within one evidence epoch, not a perpetually wrapping global counter. This profile deliberately avoids 16-bit wrap ambiguity rather than attempting to infer a wrapped index: an epoch MUST contain no more than 60000 intervals and a new Anchor and chain MUST begin before index reuse. An Observer MUST reject an AER or KDR whose index is greater than or equal to the Anchor's n_len. T_0, Delta, d, n_len, and the Observer's receive time provide the expected interval; if the received index is not consistent with that expected interval within the configured receive-delay and clock-error allowance, the record is not eligible for real-time verification. An implementation that permits index wrap requires an unambiguous lifting rule and is outside this profile.

Emission Rules = d: q := j - d # AER interval whose key becomes public QUEUE_TO_RID_MODULE(PACK_KDR(idx = q, key = K_(q+1)), repeats = r_kdr) PED EVERY T_anchor AND AT EPOCH START: QUEUE_TO_RID_MODULE(ANCHOR_SIGNED_ONCE) # same bytes, no re-sign ]]> The RID module forwards queued evidence without the ability to compute tags, because it never holds K_(i+1) before disclosure for interval i. Evidence traffic MUST NOT displace messages that regulation requires; it is sent in remaining capacity. Receipt n in the PED's signed receipt chain MUST contain the same 8-octet header, so that broadcast evidence and later-audited receipts can be matched one-to-one.

Observer Verification Let delta_max be an upper bound on the difference between the Observer clock and the time base used for T_0. An Observer with GNSS-derived time can generally use a tighter delta_max than an Observer relying only on network time. If only NTP, cellular time, or another network-derived clock is available, delta_max MUST conservatively bound that source and its uncertainty; otherwise the Observer MUST NOT claim the real-time pre-disclosure property and may retain the record for later audit only. = a.n_len: DISCARD(rec, "INDEX_OUT_OF_EPOCH"); RETURN expected := FLOOR((t_r - a.t0) / a.delta) IF NOT INDEX_PLAUSIBLE(i, expected, receive_delay_bound, delta_max): DISCARD(rec, "INDEX_TIME_INCONSISTENT"); RETURN x := FLOOR((t_r + delta_max - a.t0) / a.delta) IF x >= i + a.d: DISCARD(rec, "UNSAFE_LATE") # key may be public PENDING[i].add(rec) # safe; wait for K_(i+1) OBSERVER ON KDR(kd, t_r): a := chain[det, epoch]; IF a IS NONE: BUFFER(kd); RETURN IF NOT CLOCK_ERROR_BOUNDED(delta_max): STORE_FOR_AUDIT_ONLY(kd); RETURN q := UINT16(kd.idx) # AER interval index IF q >= a.n_len: RETURN key_index := q + 1 # disclosed chain key is K_(q+1) IF key_index <= a.last_key_index: RETURN expected_disclosure := FLOOR((t_r - a.t0) / a.delta) - a.d IF NOT INDEX_PLAUSIBLE(q, expected_disclosure, receive_delay_bound, delta_max): DISCARD(kd, "INDEX_TIME_INCONSISTENT"); RETURN IF ITERATE(F, kd.key, key_index - a.last_key_index) != a.last_K: DISCARD(kd); RETURN FOR i FROM a.last_key_index TO q: # recover any lost interval keys K_interval := ITERATE(F, kd.key, q - i) # equals K_(i+1) FOR rec IN PENDING[i]: K_tag_i := F'(K_interval) # equals K'_i IF TRUNC64(HMAC_SHA256(K_tag_i, "UAS-AFE-rec" || det || epoch || rec.hdr)) == rec.tag: MARK_VERIFIED(rec) # PED decided (class, dec, n) in I_i ELSE: MARK_INVALID(rec) a.last_key_index := key_index; a.last_K := kd.key ]]> With Delta = 1 s and d = 3, and an Observer clock whose error is bounded by delta_max = 1 s, a record becomes verifiable roughly 3 to 4 seconds after emission. These values are RECOMMENDED starting points, not requirements. If the Observer cannot establish a clock-error bound -- for example, it has only an unsynchronized or untrusted local clock -- it may retain records for later audit but MUST NOT claim the TESLA real-time property that the record arrived before key disclosure. Delayed disclosure authenticates PED origin and pre-disclosure reception; it does not, by itself, prove physical location. A still-safe AER can be relayed to another Observer before disclosure. Correlation with DRIP-authenticated Location/Vector messages from the same interval is therefore a mitigation against location confusion, not a cryptographic proof that the observed physical act occurred at the reported coordinates. The signed receipt chain remains the authoritative detailed audit record.

What a Verified Record Does and Does Not Establish A verified AER establishes that the holder of the anchored key chain -- the PED endorsed for that DET -- emitted, during interval I_i, decision record n with the stated act class, decision, and sink class. Combined with DRIP-authenticated Location/Vector messages from the same interval, an Observer can associate the decision with where the aircraft was. It does not establish that the physical effect occurred, that every decision was received (broadcast is lossy; counter gaps are visible but are not by themselves evidence of misconduct), or anything about the content of the authority object beyond the optional hint. Full detail is in the signed receipt chain, which an authorized auditor can later obtain and match to broadcast headers by counter n. Broadcast evidence is never authority. A sink, PED, or service MUST NOT accept an AER, KDR, or Anchor as a handle, and a receipt presented as a handle is refused (EF-008).

Size and Cost Comparison Per-act evidence cost (indicative)

Approach	Per-act octets on air	Per-act onboard operation	Loss behaviour	Origin
DET-signed structure per act	>= 64-octet signature plus identifiers and timestamps; multi-page on legacy transport	One public-key signature	Lost page may lose the record	Key holder of DET (often RID module or flight software)
AER with delayed disclosure (this document)	16 (plus one 19-octet KDR per interval, shared by all records)	One HMAC-SHA-256	Lost KDR recovered from any later KDR	PED only

Forgery resistance per record is bounded by the 64-bit tag (success probability about 2^-64 per attempt) and by one-wayness of F. A 64-bit tag is chosen because the record is evidence rather than authority; deployments that need more MAY use a 24-octet AER variant with a 128-bit tag.

Carriage and Open Issues for DRIP

• Carriage. This version intentionally does not request a DRIP Frame Type or Specific Authentication Method allocation. Candidate carriage approaches may require ASTM/ICAO coordination, an applicable future IETF standards effort, or use over Network RID. The byte-level AER/KDR construction is separable from the eventual carriage decision.
• Manifest interaction. AERs and KDRs are ordinary payload and can also be covered by a DRIP Manifest; delayed-disclosure verification still adds PED-origin that a Manifest signed with the DET key cannot provide on its own.
• Endorsement. The default profile uses a distinct PED evidence key endorsed by the aircraft's DRIP/HI identity. The RID module may relay the Anchor, endorsement, AERs, and KDRs but does not receive undisclosed chain keys. This document does not require the PED to hold the DET private key.
• Network RID. The same records can be relayed through Network RID services, where size is less constrained but the PED-origin property is still useful.

Onboard Bus Considerations Where the sink is reached over a bus, the enablement condition SHOULD be a physical line or gated rail controlled directly by the PED (for example ESC enable, latch solenoid supply, PA enable), because a gated condition is not bypassed by a forged bus frame. Where a sink can only be reached by bus messages (for example ESCs on CAN or DroneCAN, where classic CAN frames carry 8 data octets and CAN FD frames up to 64), the PED MAY establish a per-arming session key with the sink and send envelope releases carrying a freshness counter and a truncated MAC. That arrangement authenticates the release but places part of enforcement in the sink's firmware; it is a mitigation-class profile unless the sink's firmware is itself within the attested PED boundary. This profile does not assume that current off-the-shelf or consumer ESC firmware is a PED; such a sink qualifies for the stronger profile only when its relevant firmware, key state, and bypass resistance are within the attested enforcement boundary.

Relevance to IETF and IRTF Work This document crosses several existing protocol and security work areas, but it does not assert that any one Working Group or Research Group owns the complete execution-finality problem. The mappings below identify reusable IETF/IRTF mechanisms and review communities. They are not statements of adoption, charter expansion, or venue assignment.

Why This Is an Internet-Protocol Boundary Problem The mechanisms in this document do not standardize aircraft aerodynamics, steering geometry, braking control, ESC control laws, or collision-avoidance algorithms. Those remain functions of avionics, vehicle-control, autonomy, and safety systems. The Internet-facing problem arises because identity, authority, attestation, revocation, freshness, remote-assistance instructions, responder credentials, UTM/U-space state, V2X or air-to-air coordination, and audit evidence can originate across network and administrative boundaries, while the consequence occurs later at a local physical sink. The protocol question is how that network-originated state remains cryptographically and semantically bound to the exact act that is about to become effective.

Internet-originated authority carried to a physical finality boundary | - epochs / freshness | | - exact-act binding | | - receipt state | +-----------+-----------+ | scoped release only v +-----------------------+ | Finality Sink | | motor / steering / | | brake / latch / RF / | | motion admission | +-----------------------+ | v physical effect ]]>

The architectural boundary is therefore between a network/control-plane assertion and local effectuation. Authentication of the upstream message is necessary but not sufficient: the sink must determine whether that assertion is still current, applies to this device and sink, and still describes the actual impending act. This is the same separation expressed throughout this document as computation or communication not being, by itself, release authority.

Mapping of the Three Extended Embodiments

Conflict-Set-Bound DAA Finality ():

The Internet-relevant state includes authenticated aircraft identity, cooperative traffic reports, remote or network DAA inputs, freshness, attestation of the protected DAA/finality component, and evidence of the resolution that was admitted. DRIP/tm-rid is relevant to aircraft identity and Observer association; RATS is relevant where a relying party needs Evidence or Attestation Results about the protected component and its reference state; COSE/CBOR is relevant to compact deterministic representation and authentication of Conflict-Set Commitments, Resolution Objects, and receipts; ACE patterns are relevant where constrained sinks consume narrowly scoped authorization; SCITT-style transparency may be useful for later registration or audit of resolution receipts; and T2TRG is relevant to constrained, multi-source, stateful enforcement. None of these mappings asks DRIP or another IETF group to standardize the collision-avoidance algorithm itself.

Emergency-Scene Temporary Authority Finality ():

The Internet-relevant problem is the transport and interpretation of a temporary responder authority across organizations while preventing a valid credential from becoming general remote-driving authority. COSE/CBOR is relevant to compact signed or MAC-protected Emergency Scene Authority Capsules; RATS is relevant where responder-side or vehicle-side protected state must be attested; ACE concepts are relevant to narrowly scoped, time-bounded authority for a constrained motion-admission sink; SCITT-style receipts can support post-event accountability without participating in the live driving decision; and T2TRG is relevant to constrained devices with multiple legitimate masters or stakeholders. Where UAS public-safety operations use the same construction, DRIP identity and tm-rid Observer mechanisms can associate temporary authority and later evidence with a particular aircraft.

Atomic Control-Authority Handover ():

The Internet-relevant problem is not controller scheduling but transfer of effect authority between independently authenticated controllers across delayed, duplicated, failed, or recovered sessions. ACE is relevant to constrained authorization and scope; RATS is relevant to attestation of Current Controller, Control Authority Epoch, and protected handover state; COSE/CBOR is relevant to Handover Objects, epoch-bound actuation objects, and receipts; SCITT-style transparency can record completed authority transfers; and T2TRG is directly relevant to constrained Things with multiple masters or stakeholders. For UAS, DRIP/tm-rid can provide the aircraft identity and Observer context but does not itself determine which controller currently owns an actuator sink.

Group-by-Group Relevance

DRIP Working Group / tm-rid community:

DRIP supplies a trustworthy aircraft identity and Broadcast/Network RID context. This document can bind Compact Broadcast Act Evidence, DAA-resolution evidence, selected temporary-authority evidence, and handover evidence to a DET without changing the principle that DRIP identifies and authenticates rather than decides physical actuation. Possible future work, if the community finds it useful, includes compact carriage, Observer verification, and correlation rules.

RATS:

RATS is relevant where an authority issuer or relying party needs confidence that the PED, Finality Sink path, safe-state implementation, DAA finality logic, scene-corroboration logic, or handover state is running in an expected protected configuration. Candidate attested state includes PED measurements, reference values, bypass-resistance claims, Current Controller, Control Authority Epoch, current policy/revocation generations, and the protected components that calculate or verify Conflict-Set Roots. This document does not define new RATS Evidence or Attestation Result claims; such claims would require separate profiling and review.

COSE and CBOR:

Deterministic CBOR and COSE are directly relevant to AAOs, Execution Handles, BPCs, Finality Receipts, evidence anchors, DAA Resolution Objects, Conflict-Set Commitments, Emergency Scene Authority Capsules, Control Handover Objects, and epoch-bound actuation objects. Compact canonical representation is important because semantic binding fails if producer and verifier hash different encodings of the same logical object.

ACE:

ACE is relevant to constrained authorization patterns where a protected resource server or actuator-side verifier must accept only narrowly scoped, time-bounded authority. The DAA, emergency-scene, and handover embodiments add a further local condition: authenticated authorization is not released to the physical sink until the exact impending act, current epoch, freshness, and local context also match. This document therefore treats ACE-style authorization as a potential input to finality rather than as proof that actuation has already been authorized at the physical boundary.

SCITT:

SCITT-style transparency services are relevant to publication or later audit of AAO issuance, Finality Receipts, DAA Resolution Receipts, Emergency Scene Authority issuance, and committed controller handovers. Transparency evidence is deliberately outside the live effectuation path: registration, receipt, or inclusion in a transparency service does not itself create execution authority.

T2TRG (IRTF):

T2TRG is relevant to constrained-device security, state/event semantics, intermittent connectivity, devices with multiple legitimate masters, bounded local enforcement, and reference/evaluation environments. The three extended embodiments provide concrete cross-domain cases: a UAS with multiple traffic information sources, a vehicle temporarily directed by an external responder, and a device transferring effect authority between autonomy, remote assistance, and safe-state controllers.

Security Considerations Threats and mitigations

Threat	Effect without this profile	Mitigation	Residual
Compromised mission computer writes actuators	Unauthorized motion, release, sensing	No path to enablement conditions except via PED (path completeness)	eps_path if a bypass exists in hardware design
Stolen or replayed handle	Repeat of an authorized act	Non-bearer, act- and sink-bound, atomic consume	eps_store
Stale authority after restriction	Entry into restricted volume	Generation read inside consume; event-triggered revalidation; offline bound	T_off_max when offline
GNSS spoofing	False containment	Multi-source consistency; disagreement removes authority	eps_ctx if all sources falsified consistently
Coerced but validly signed command	Unsafe act by authenticated source	Command treated as Candidate Act; quorum for marked classes	Colluding quorum
Partial coordinated act	Separation loss	Composite decision log; prepare never moves; HOLD	Liveness when log unreachable
Stale DAA conflict basis or superseded resolution	An avoidance maneuver can become unsafe before motion admission	Conflict-Set Root, current-set revalidation, multi-intruder check, and monotonic Resolution Epoch	Depends on integrity, freshness, and completeness of the protected traffic inputs
Replayed or over-broad emergency-scene authority	A temporary traffic-rule exception can be reused for another vehicle, scene, incident, path, or time	Incident/scene/vehicle/act/sink binding, independent local scene corroboration, explicit exception class, nonce, expiry, and automatic authority extinction	Residual risk if all required local scene evidence is consistently falsified
Split-brain controller handover	Two valid controllers can issue conflicting ordinary actuation commands	Protected Current Controller state, monotonic Control Authority Epoch, transactional PREPARE/COMMIT/ENABLE, and stale-epoch rejection at the sink	Availability can fall back to the Safe-State Set during incomplete handover or recovery
Truncated BPC commitment collides or is searched offline	Wrong act or authority could appear to match a short value	Keyed binding preferred; explicit collision and attacker-work sizing; ambiguity causes deny or longer proof	Deployment-selected t and online-attempt budget
Mixed, missing, or corrupted BPC fragments	Partial proof could be mistaken for authority	Per-fragment authentication, common SessionID and Root, ordered reconstruction, root verification; incomplete evidence means no effectuation	Availability loss under packet loss or jamming
Unknown or stale compact Authority Reference	Reference substitution or stale cached authority	Protected keyed reference, authenticated cache/resolver, current generation checks at finality; UNKNOWN never means authorized	Resolver/cache availability
Forged broadcast evidence by RID module or third transmitter	False appearance of authorized conduct	Key chain seed sealed in PED; tag keys disclosed only after safety window	2^-64 per record; Observer clock outside delta_max
Late replay or relay of evidence	Old or remote decision presented as locally current	Interval index bound in tag; pre-disclosure receive-time condition; correlate with DRIP-authenticated Location/Vector from the same interval	A relay inside the disclosure window remains possible; if location evidence is also forged or unavailable, act-evidence verification alone does not prove local physical presence
Receipt presented as handle	Authority laundering	Refused (EF-008)	None expected
Denial of evidence broadcast (jamming)	Observer sees nothing	None at the broadcast layer; receipts remain for audit	Loss of real-time observability

A PED that is itself compromised defeats this profile; its isolation, non-extractable keys, and attested measurement are therefore load-bearing assumptions. Denial and safe-state selection are designed so that the failure mode of the enforcement layer is a controlled holding, descent, or landing manoeuvre, never uncontrolled flight.

Privacy Considerations Broadcast act class values can reveal operational details (for example that a camera is active). Deployments MAY use the UNSPECIFIED act class (privacy mode), broadcasting only decision, sink class, counter, and tag, with full detail confined to receipts available to authorized auditors. The optional AAO hint SHOULD NOT be broadcast where it would link flights to customers. Receipts SHOULD omit imagery, customer identity, and raw sensor data, carrying digests instead. Whether and how act evidence is broadcast is subject to regional regulation; this document does not assume a mandate. The DAA profile can involve sensitive traffic tracks and the emergency-scene profile can involve responder, incident, and scene information. Implementations SHOULD keep raw track sets, responder identities, and detailed scene observations inside protected local state where possible, carrying commitments, pseudonymous references, coarse classes, or auditor-only receipt fields instead. Control-handover receipts SHOULD avoid exposing operator identity beyond what is necessary to prove the authority transition.

IANA Considerations This document has no IANA actions. It does not request a DRIP Frame Type, a Specific Authentication Method value, or an IANA act/sink registry. If the compact evidence mechanism progresses in a future standards effort, carriage and registry work would require the process appropriate to the selected transport, including coordination with ASTM/ICAO where applicable.

Reference Implementation, Red-Team Harness, and Reproducibility An accompanying non-normative reference repository, UAS-Autonomous-Vehicle-Execution-Finality-Reference, instantiates the principal state machines, cryptographic bindings, and negative-control cases in this document. The repository is intended to make the architectural claims falsifiable and reproducible rather than to serve as production flight, vehicle, or actuator software. It is not a normative dependency of this specification. The public repository is available at . Related public background records by the author are , which describes the broader execution-finality authority problem; , which provides hardware-enforcement context; and , which discusses purpose-bound execution finality in another application domain. These resources are informative only and are not normative dependencies of this UAS/AV profile. The current packaged snapshot contains 68 files. Its principal contents are:

• reference Python modules for Candidate-Act/finality processing, BPC binding and authentication, replay and receipt state, authenticated fragmentation, corrected AER/KDR delayed-disclosure processing, DAA conflict-set finality, emergency-scene temporary authority, control-authority handover, and spatial revalidation;
• explicit configuration files for cryptographic field sizes, collision and attacker-work budgets, AER disclosure timing and packet loss, UAS and road-vehicle parameters, DAA variables, and constrained-compute profiles;
• positive and adversarial tests covering act substitution, sink substitution, replay, policy/revocation races, receipt-store failure, concurrent single-use consumption, fragment deletion/corruption/cross-session mixing, delayed-disclosure forgery and late-record cases, stale DAA conflict sets, superseded Resolution Epochs, correlated emergency-scene evidence, and control-handover crash states;
• deterministic BPC, AER/KDR, and fragmentation test vectors, together with a seeded randomized red-team campaign so a failing schedule can be replayed;
• threat-model, architecture, system-variable, test-matrix, fault-injection, benchmark, security, and IPR documentation; and
• a CI configuration and a local benchmark harness that report the execution environment together with measured software-path latency.

How the Reference Harness Was Produced The reference harness was produced by translating the equations, state transitions, object bindings, and pseudocode in this document into a small, deterministic software model. The implementation uses Python and, for the packaged cryptographic paths, standard-library SHA-256, HMAC-SHA-256, and a minimal HKDF construction. Test cases were then derived from the stated invariants and from explicit adversarial mutations: each load-bearing field or state transition is changed, replayed, reordered, made stale, made unavailable, or subjected to a modeled crash point, and the expected outcome is checked before any simulated capability release. The red-team methodology therefore follows the traceability pattern architectural invariant -> adversarial mutation -> expected protected failure -> automated test. For control-authority handover, the packaged campaign additionally executes seeded randomized crash schedules and checks the invariant that no modeled state gives two ordinary controllers simultaneous effectuation authority over the same governed sink. The code was written as a clean-room reference model of the mechanisms described in this document. It was not extracted from, reverse engineered from, or validated against any proprietary OEM flight controller, autonomous-driving stack, vehicle ECU, secure element, actuator controller, or named industrial platform.

Current Packaged Test Status In the packaged snapshot used while preparing this revision, the automated suite reports 66 passing tests. A seeded control-handover red-team campaign using seed 20260918 executed 5,000 modeled schedules and reported zero dual-authority violations. These numbers describe that particular repository snapshot and software model; they are not conformance certification and may change as the harness and test set evolve. The repository also records local Python benchmark measurements for BPC generation, finality verification/consume/receipt/capability processing, AER generation, and fragmentation/reassembly. Those measurements are environment specific and are reported together with the machine and interpreter details. They exclude network delay, secure-element or HSM access, durable storage fsync, certified real-time scheduling, bus arbitration, and physical actuator I/O.

Interpretation and Limitations Passing the reference harness demonstrates only that the included software state machine and cryptographic bindings satisfy the tested properties under the modeled inputs and adversary. It supports reproducibility and engineering plausibility of those software-level mechanisms; it does not establish physical non-bypassability, airworthiness, automotive functional safety, real-time deadline compliance, RF interoperability, secure-element extraction resistance, resistance to all correlated sensor failures, or production readiness. In particular, a real platform must separately demonstrate that no actuator, DMA, debug, maintenance, alternate bus-master, emergency, firmware-rollback, or failover path can create the protected effect without traversing the applicable Finality Sink. Hardware testing should additionally inject reset, brownout, torn-write, persistent-state rollback, HSM/secure-element timeout, bus and DMA bypass attempts, clock rollback, packet burst loss, controller partition, and actuator-acknowledgement failures at each protected transition. The repository does not substitute for system hazard analysis, flight testing, airworthiness approval, automotive safety engineering, cybersecurity certification, standards conformance, or regulatory approval. It also does not demonstrate that any named industrial platform implements this architecture. Results from the pure-software harness should therefore be described as reference-implementation evidence, not as production-platform validation.

Assumptions, Limitations, and Invitation for Review

• The numerical example in is illustrative and is not an airworthiness or certification formula. Real stopping behavior depends on airframe, wind, mass, rotor/propulsion lag, control law, and actuator delay; a_brk and tau must therefore be conservative guaranteed values from protected or attested safety configuration, or a more conservative deployment-specific model must be substituted.
• The compact BPC sizing expressions are engineering security-budget inputs, not a complete cyber-physical safety probability. Deployments must choose q, W, A_online, epsilon_c, epsilon_s, epsilon_f, commitment length t, and tag length m for the relevant act rate, session lifetime, fleet scale, and risk class; high-consequence acts should use longer values or a full-proof profile where the budget cannot be justified.
• The evidence mechanism assumes a bounded Observer clock offset. An Observer that cannot establish delta_max, including one relying only on an untrusted or unsynchronized local clock, may retain records for later audit but cannot assert the delayed-disclosure real-time safety property.
• No flight-test, actuator, secure-element, or production-hardware results are claimed. Any measurements reported by the accompanying reference repository are local software-harness measurements on the stated environment and exclude network, durable-storage, certified real-time scheduling, secure-element/HSM, bus, and physical-actuator latency.
• F3411 page layouts and DRIP carriage details are to be confirmed against the editions in use; this version intentionally leaves carriage open.
• Known unsolved items: guaranteed delivery of generations to aircraft in radio-shadowed areas; standardized derivation of sensor footprints for P_sensor; and evidence semantics for acts decided by the flight controller's internal safety logic without PED involvement.

The author's understanding of DRIP, F3411, and airframe practice may contain inaccuracies. Critical technical review, especially from DRIP participants and autopilot developers, is invited.

References Normative References Informative References ASTM International ASTM International Tesla BYD DJI Enterprise Boeing Lockheed Martin

Appendix: Industrial Deployment Context and Complementarity This non-normative appendix gives industrial deployment context only. The descriptions are based on publicly available material and are intended to explain where an execution-finality boundary could sit relative to existing products and architectures. No implementation from any named organization was used, simulated, reverse engineered, or tested in preparing this document, and no affiliation, endorsement, adoption, infringement conclusion, or claim of technical deficiency is stated or implied. Corrections from the organizations concerned are welcome. The complementarity rule is deliberately narrow: existing perception, planning, localization, DAA, ADAS, geofencing, flight-control, braking, steering, remote assistance, authenticated messaging, and fail-safe logic continue to perform their present functions. This profile does not replace them. Instead, those components produce or support a Candidate Act. A protected execution-finality component then verifies the concrete act actually pending at the motion-admission or actuator boundary against current authority, freshness, policy, revocation, context, conflict set, scene, or control-authority state before releasing only the bounded enablement required for that act.

Complementary placement relative to an existing autonomy stack | state + act binding | | stabilization / minimal-risk logic | | + receipt + consume | +-------------------+-----------------+ +-----------+-----------+ | | | existing safe-state path | bounded release v v +-------------+ +-------------+ | safe control| | motion / | | remains | | actuator sink| +-------------+ +-------------+ The finality layer does not replace perception, planning, stabilization, braking, steering, DAA, ADAS, or vendor safety logic. ]]>

Illustrative industrial ecosystems and complementary role

Ecosystem	Publicly described role	Complementary role of this profile
Tesla	Camera- and AI-based driver assistance, including Autopilot and Full Self-Driving (Supervised); Tesla states that currently enabled features require active driver supervision and do not make the vehicle autonomous.	The existing perception and driving-assistance stack can continue to compute a trajectory or manoeuvre. A protected motion-admission sink can, as an additional layer, bind the concrete pending manoeuvre to current authority, scene, control-authority epoch, freshness, and safety state before admitting a bounded steering, braking, propulsion, or mode transition. This profile does not replace Tesla's driver-monitoring, planning, braking, steering, or safety logic.
BYD	DiPilot intelligent-driving assistance and vehicle-domain architectures integrating sensing, decision, and control functions.	The vehicle's existing sensor fusion, intelligent-driving planner, AEB, lane-control, and motion-control functions remain unchanged. Execution finality can be placed after planning and before motion admission so that a remotely approved path, emergency-scene exception, cooperative manoeuvre, or controller handover is effective only when its act, scene, vehicle, epoch, and sink bindings still match current protected state.
DJI Enterprise	Enterprise drone mission planning and flight automation across waypoints, inspection missions, cameras, and multiple aircraft.	Mission automation can continue to generate waypoints, camera requests, payload operations, and flight plans. The PED can sit below the mission-planning layer and gate only the final arming, envelope expansion, payload, sensor, RF, or other consequential enablement after reconstructing the actual impending act. Existing flight-controller stabilization and failsafes remain available as the Safe-State Set.
Boeing autonomous and uncrewed systems	Publicly described autonomous and uncrewed aircraft, collaborative systems, secure communications, and human-operated AI/autonomy architectures.	For civil or dual-use architectural discussion only, conflict-set-bound DAA finality can sit downstream of a DAA or autonomy planner so that an accepted avoidance resolution remains bound to the conflict-set basis on which it was computed. Control-authority handover finality can additionally ensure that only the controller named by the current protected authority epoch can admit motion. Existing flight-control, safety, and mission systems remain primary.
Lockheed Martin / Sikorsky autonomy	Publicly described autonomous and uncrewed systems, human-machine teaming, autonomous mission execution, and Sikorsky MATRIX autonomy.	The profile can complement such autonomy patterns by treating planner or operator output as a Candidate Act rather than final authority. DAA conflict-set revalidation, monotonic control-authority epochs, and sink-local verification can be added at the final motion or actuator boundary while leaving perception, mission planning, vehicle stabilization, and certified safety functions intact. This document's scope remains civil and excludes weapon, targeting, and counter-UAS effectuation.
PX4 and ArduPilot (open-source autopilots)	Flight control, geofence, mission, and failsafe logic.	PED gates arming, envelope, payload, sensor, and RF enablement beneath the autopilot; autopilot failsafes remain a Safe-State implementation rather than being displaced by the finality layer.
Wing, Amazon Prime Air, Zipline	Automated delivery operations using route planning, fleet operations, airspace services, and payload delivery mechanisms.	Payload release can be represented as a single-use, drop-zone-bound Candidate Act whose concrete latch or winch operation is reconstructed and verified at the payload sink before release, with optional receipt and observer evidence.
NVIDIA Jetson-class and Qualcomm robotics/vehicle compute	High-performance onboard AI, perception, connectivity, and planning compute used in robotics, vehicles, and edge systems.	Accelerator output remains computational input to a Candidate Act. A smaller protected controller or safety domain can hold final authority state and release the actuator or motion-admission capability only after independent verification.
USS/USSP providers under ASTM F3548 and U-space	Flight authorization, conformance monitoring, geo-awareness, and operational information exchange.	These services can remain upstream issuers of authority and current-generation information. The aircraft PED consumes that information at effectuation time, and optional receipts or evidence can be returned to authorized operators or auditors.

The same complementarity principle applies to the three narrower embodiments in this document. For DAA finality, the DAA engine continues to detect and resolve conflicts; the new step is revalidation that the accepted manoeuvre is still bound to the current conflict set at motion admission. For emergency-scene authority, the vehicle's normal ADAS/autonomy and minimal-risk functions remain active; the new step is a temporary, scene-corroborated, vehicle- and act-bound exception that extinguishes automatically. For control-authority handover, existing controllers continue to compute commands; the new step is protected exclusive-controller state and a monotonic epoch that rejects commands from superseded controllers at the finality sink.

End-to-End Example: Parcel Delivery with a Mid-Flight Restriction

1. Before take-off, the operator's USS issues an AAO for corridor segments 1-4, drop zone D7, v_max 15 m/s, offline T_off_max 60 s, act classes ARM, KINETIC_ENVELOPE, VOLUME_ENTRY, PAYLOAD_RELEASE, RF_EMIT, at g_air 412.
2. The PED verifies the AAO, anchors a new evidence epoch, and the RID module broadcasts the Anchor and the Evidence Key Endorsement alongside DRIP authentication.
3. ARM handle consumed; receipt n=1 committed; ESC enable released; AER (ARM, ALLOW, n=1) broadcast.
4. Envelope handle for segment 1 consumed; the comparator admits setpoints inside E. Revalidation interval shrinks near the segment boundary per .
5. At 14:07 a restriction arrives as g_air 413 intersecting segment 3. The PED invalidates the segment-3 handle before it is used. On reaching the end of segment 2 the VOLUME_ENTRY request for segment 3 is denied (EF-061); the aircraft holds and requests a reroute; AER (VOLUME_ENTRY, DENY, n=9) broadcast.
6. A new AAO at g_air 413 authorizes segments 3a-3b. Flight continues.
7. Over D7, P_payload holds (inside zone, h below limit, speed and tilt within bounds, positions consistent). PAYLOAD_RELEASE handle consumed, receipt committed, latch solenoid powered for its window. A police officer nearby sees the parcel lowered and, about three seconds later, the Observer app shows a verified record (PAYLOAD_RELEASE, ALLOW) from the enforcement domain of the identified aircraft.

Test Vector Classes The accompanying reference repository includes deterministic byte-level vectors for selected BPC, AER/KDR, and authenticated-fragmentation cases. Future revisions of this document are expected to include or normatively reference a broader set of vectors for the following classes: (1) U-CAD canonical encoding and digest using both the readable text-key representation and the compact integer-key profile; (2) handle bound to wrong sink; (3) SINGLE_USE replay; (4) envelope exit by position, speed, altitude, window, and aggregate ceiling; (5) generation advance affecting and not affecting the corridor; (6) revocation read inside consume; (7) GNSS/VIO disagreement; (8) offline window expiry; (9) composite COMMIT, CAS ABORT, and HOLD on unreachable log; (10) keyed BPC Binding Commitment computation; (11) compact Authority Reference resolution, including UNKNOWN and stale-reference denial; (12) BPC truncation at selected collision and attacker-work budgets; (13) collision guard ambiguity causing deny or escalation; (14) authenticated fragment generation, cross-session mixing rejection, missing-fragment denial, ordered reconstruction, and Root verification; (15) BPC capsule-authenticator computation and forgery-budget sizing; (16) sink-side reconstruction of the actual pending act and compact-binding comparison; (17) master-seed derivation of K_N and reverse-chain derivation through K_0; (18) AER tag computation; (19) Observer safety condition at the boundary x = i + d; (20) lost KDR recovery across several intervals; (21) evidence-epoch renewal before 16-bit index reuse; (22) Observer using network time with insufficient delta_max; (23) receipt presented as handle; and (24) AER, KDR, Anchor, or BPC evidence presented as execution authority.