Cleared to Fly or Drive Is Not Cleared to Act: Actuator-Level Execution Finality and Compact Act Evidence for UAS and Autonomous Vehicles

1.1. 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.¶

1.2. 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.¶

1.3. 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.¶

1.4. 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.¶

1.5. 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.¶

1.6. Contributions of This Profile

1. Compact Broadcast Act Evidence: fixed 16-octet per-act records authenticated with a TESLA-style [RFC4082] 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 (Section 19).¶
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 (Section 8). 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 (Section 6).¶
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 (Section 4).¶
5. Live-context enforcement including corridor containment, multi-source position consistency, generation currentness inside atomic consume, and a conservative boundary-proximity revalidation scheduling policy (Section 10).¶
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 (Section 9.4).¶
7. A bounded offline mode that converts link loss into a finite residual exposure rather than open-ended cached authority (Section 12).¶
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 (Section 15).¶
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 (Section 16).¶
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 (Section 17).¶
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 (Section 18).¶

1.7. 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 Section 13.¶

Section 17 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. Section 18 applies to UAS and may also be reused by other autonomous motion platforms.¶

1.8. 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 [DAS-HANDLE], registries [DAS-REG], composite finality [DAS-COMPOSITE], jurisdiction binding [DAS-JURISDICTION], actuation binding [DAS-ACTUATION], state continuity [DAS-STATE], revocation [DAS-REVOCATION], consequence-path completeness [DAS-PATH], and the general architecture [DAS-PROTOCOL]. 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.¶

3.1. 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.¶

3.2. 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.¶

3.3. 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 Section 19. 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.¶

  protected master seed:  K_seed    (never disclosed)
  terminal chain value:   K_N = Trunc_128(SHA-256(
                               "UAS-AFE-seed" || K_seed || epoch_id))
  reverse chain:          K_i = F(K_(i+1))
  public anchor:          K_0
  interval i tag key:     K'_i = F'(K_(i+1))
  disclosure:             K_(i+1) after delay d
  chain authentication:   F^((j+1)-k)(K_(j+1)) = K_k
  loss recovery:          K_(i+1) = F^(j-i)(K_(j+1)),  j > i

3.4. 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.¶

5.1. 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.¶

5.2. 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.¶

5.3. 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.¶

5.4. 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.¶

5.5. 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.¶

5.6. 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.¶

5.7. 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.¶

7.1. UAS Candidate Act Descriptor

u-cad = {
  "v"          : 1,
  "act_class"  : uint,              ; Table 2 code
  "ua_det"     : bstr .size 16,     ; DRIP Entity Tag of this UA
  "sink_id"    : bstr .size 8,      ; PED-local sink identifier
  "act_id"     : bstr .size 16,     ; random per Candidate Act
  "params"     : act-params,        ; load-bearing parameters only
  "ctx_digest" : bstr .size 32,     ; digest of live context snapshot
  "g_air"      : uint,              ; airspace/geo-zone generation
  "g_rev"      : uint,              ; revocation generation
  "g_pol"      : uint,              ; operator policy generation
  "aao_digest" : bstr .size 32,     ; authority object relied on
  ? "composite": { "id": bstr .size 16, "digest": bstr .size 32 }
}

act-params = kinetic-env / volume-entry / payload
           / sensor / rf / other

kinetic-env = {
  "corridor_id" : bstr, "segment" : uint,
  "v_max_cms"   : uint, "a_max_cms2" : uint,
  "h_min_dm"    : int,  "h_max_dm"   : int,
  "t_start"     : uint, "t_end"      : uint     ; seconds, GNSS time
}

payload = {
  "drop_zone_id" : bstr, "h_max_dm" : uint,
  "v_max_cms"    : uint, "tilt_max_cdeg" : uint
}

sensor = { "sensor" : uint, "res_class" : uint,
           "fov_cdeg" : uint, "area_id" : bstr, "t_end" : uint }

rf = { "band_id" : uint, "p_max_dbm" : int, "t_end" : uint }

volume-entry = { "zone_id" : bstr, "g_air" : uint }
other = { * tstr => any }

The descriptor digest is d(U) = SHA-256(det-CBOR(U)) [RFC6234]. 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.¶

7.2. 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.¶

7.3. Airspace Authority Object

aao = {
  "issuer"      : tstr,             ; operator, USS/USSP, authority
  "ua_det"      : bstr .size 16,
  "act_classes" : [+ uint],
  "corridor"    : corridor,
  "envelopes"   : { * uint => 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.¶

7.4. 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:¶

  R_n = Auth_K( Header_n || B_n || Counter_n || H(R_(n-1)) )

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.¶

8.1. 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.¶

  D_A = SHA-256( "UAS-BPC-ACT" || det-CBOR(U) )
  D_C = SHA-256( "UAS-BPC-CTX" || det-CBOR(Ctx) )

  B = HMAC-SHA-256(K_bind,
        "UAS-BPC-BIND" || D_A || sink_id || authority_ref ||
        g_air || g_rev || g_pol || D_C || freshness || expiry)

  B_t = Trunc_t(B)

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 Section 8.4. Changing a load-bearing act field, sink, authority, generation, context, freshness value, or expiry therefore changes the expected binding.¶

  Sink_2 != Sink_1
       => Binding(A, Sink_2) != Binding(A, Sink_1)
          except with the bounded cryptographic collision probability

  K_B = HKDF(K_root,
        "BEACON" || SessionNonce || DeviceID || PolicyEpoch || SinkClass)

  K_bind = HKDF(K_root,
           "BIND" || SessionNonce || DeviceID || SinkID)

  K_(i+1) = H(K_i)     ; erase K_i after use

8.2. 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:¶

  D_AAO = SHA-256( det-CBOR(AAO-payload) )
  R     = Trunc_r( HMAC-SHA-256(K_R,
              "UAS-BPC-AUTHREF" || D_AAO) )

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.¶

8.3. 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.¶

; Semantic BPC. Integer keys are illustrative profile-local labels.
bpc = {
  0  : 1,                  ; version
  1  : uint,               ; profile_id
  2  : uint,               ; act_class
  3  : uint,               ; sink class or compact sink id
  4  : bstr,               ; authority_ref, typically 4 or 8 octets
  5  : uint,               ; g_air or session-relative airspace generation
  6  : uint,               ; g_rev
  7  : uint,               ; g_pol
  8  : uint,               ; freshness / sequence
  9  : uint,               ; expiry delta or time-slot
  10 : bstr,               ; context_ref_or_digest
  11 : bstr,               ; B_t, compact Binding Commitment
  12 : uint,               ; flags / risk profile
  13 : bstr                ; capsule authenticator
}

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.¶

8.4. 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:¶

  P_coll ~= q(q-1) / 2^(t+1)

  for target epsilon_c:
  t >= 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:¶

  P_sub ~= W / 2^t

  for target epsilon_s:
  t >= 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:¶

  P_sub <= A_online / 2^t

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.¶

  Trunc_t(B_1) = Trunc_t(B_2) AND B_1 != B_2
        => Ambiguous

  Ambiguous => Effectuate(CandidateAct) = FALSE

8.5. Capsule Authentication

In addition to B_t, the BPC is authenticated as a complete transport object. A symmetric constrained profile may compute:¶

  Tag = Trunc_m( HMAC-SHA-256(K_B,
           "UAS-BPC-CAPSULE" || canonical(BPC_without_Tag)) )

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:¶

  A / 2^m <= epsilon_f
  m >= 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.¶

8.6. 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:¶

  P    = p_0 || p_1 || ... || p_(n-1)
  Root = SHA-256( "UAS-BPC-FRAG-ROOT" || P )

  F_i  = { SessionID, Root, i, n, p_i, Auth_i }

  Auth_i = Trunc_m( HMAC-SHA-256(K_frag,
             "UAS-BPC-FRAG" || SessionID || Root ||
             i || n || p_i) )

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.¶

  IncompleteEvidence  =>  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.¶

8.7. 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.¶

PROCEDURE RESOLVE_BPC_AUTHORITY(bpc):
  aao := PROTECTED_CACHE_LOOKUP(bpc.authority_ref)
  IF aao IS NOT NULL: RETURN aao

  IF authenticated_resolver_available:
      response := RESOLVER_QUERY(bpc.authority_ref,
                                 bpc.binding_commitment,
                                 SELF.det,
                                 CURRENT_GENERATIONS())
      IF VERIFY_RESOLVER_RESPONSE(response):
          CACHE_PROTECTED(response.aao)
          RETURN response.aao

  RETURN UNKNOWN

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.¶

8.8. 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.¶

PROCEDURE PED_FINALIZE_BPC(pending_act, bpc, sink):
  ASSERT sink.enable == DISABLED

  IF NOT BPC_COMPLETE_AND_AUTHENTIC(bpc):
      RETURN SAFE_DENY("BPC_INCOMPLETE_OR_INVALID")

  U_actual := RECONSTRUCT_UCAD(pending_act, sink)
  IF U_actual IS NULL:
      RETURN SAFE_DENY("BPC_ACT_RECONSTRUCT_FAILED")

  AAO_current := RESOLVE_BPC_AUTHORITY(bpc)
  IF AAO_current == UNKNOWN:
      RETURN SAFE_DENY("BPC_AUTHORITY_UNKNOWN")

  C_current := SNAPSHOT_TRUSTED_CONTEXT()
  D_A := SHA256("UAS-BPC-ACT" || DET_CBOR(U_actual))
  D_C := SHA256("UAS-BPC-CTX" || DET_CBOR(SELECT_BOUND_CONTEXT(C_current)))

  B_actual := HMAC_SHA256(K_bind,
                "UAS-BPC-BIND" || D_A || sink.id ||
                bpc.authority_ref || bpc.g_air || bpc.g_rev || bpc.g_pol ||
                D_C || bpc.freshness || bpc.expiry)

  IF TRUNC(B_actual, bpc.binding_bits) != bpc.binding_commitment:
      RETURN SAFE_DENY("BPC_BINDING_MISMATCH")

  BEGIN ATOMIC
    G := READ_CURRENT_GENERATIONS()
    IF NOT BPC_GENERATIONS_CURRENT_OR_PERMITTED(bpc, G, U_actual):
        ABORT SAFE_DENY("BPC_GENERATION_STALE")
    IF NOT CONSUME_BPC_FRESHNESS(bpc):
        ABORT SAFE_DENY("BPC_REPLAY")
    R := MAKE_RECEIPT(ALLOW, HASH(U_actual), HASH(bpc),
                      CTX_DIGEST(C_current), n := counter + 1, prev := r_last)
    COMMIT(R)
  END ATOMIC

  IF COMMIT_STORE_UNAVAILABLE:
      RETURN SAFE_DENY("BPC_RECEIPT_STORE_UNAVAILABLE")

  RELEASE(sink, SCOPED_ENABLEMENT(U_actual, AAO_current, bpc.expiry))
  EMIT_ACT_EVIDENCE(R)     # optional evidence output; never authority input
  RETURN ALLOW

8.9. 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:¶

  AcceptAsAuthority(x) => 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.¶

9.1. Core Finality Predicate and Atomic Ordering

A representative conjunction for the BPC path is:¶

  ALLOW =
      AuthValid
   AND ActMatch
   AND SinkMatch
   AND Fresh
   AND NotReplayed
   AND PolicyCurrent
   AND RevocationCurrent
   AND ContextMatch
   AND BeaconAuthentic
   AND EvidenceComplete

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:¶

  Consumed(N) = TRUE  =>  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:¶

  E = MAC_KS( B || SinkID || ActuatorEnvelope || Counter )

  Effectuate(A) => Verify_KS(E)

K_S is the protected sink-local capability-authentication key defined in Section 3.2. 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.¶

9.2. Reference Finalization Procedure

PROCEDURE PED_FINALIZE(pending_act, handle, sink):
  # 0. Default: enablement condition is withheld. Initialize audit fields
  # so any early denial can be recorded without dereferencing unset state.
  ASSERT sink.enable == DISABLED
  U  := NULL
  dU := NULL
  C  := NULL
  raw_handle_digest := HASH_IF_PRESENT(handle)

  # 1. Reconstruct; never trust a caller-supplied digest.
  U := RECONSTRUCT_UCAD(pending_act, sink)
  IF U IS NULL: DENY(RECONSTRUCT_FAILED)
  dU := SHA256(DET_CBOR(U))

  # 2. Static verification (no mutable state read).
  IF NOT VERIFY_COSE(handle, issuer_keys): DENY(SIG_INVALID)
  IF handle.act_digest != dU:              DENY(ACT_MISMATCH)
  IF handle.sink_id    != sink.id:         DENY(SINK_MISMATCH)
  IF handle.ua_det     != SELF.det:        DENY(UA_MISMATCH)
  IF U.act_class NOT IN AAO(handle).act_classes:
                                          DENY(CLASS_NOT_PERMITTED)

  # 3. Live context from trusted sources inside the PED.
  C := SNAPSHOT_TRUSTED_CONTEXT()     # GNSS/RTK, VIO, IMU, baro,
                                      # time, battery, ESC telemetry
  IF NOT POSITION_CONSISTENT(C):     SELECT_SAFE(LOC_CONFIDENCE_LOW)
  IF NOT PREDICATES_HOLD(U, AAO(handle), C): DENY(PREDICATE_FAILED)

  # 4. Atomic section: currentness + consume + receipt commit.
  BEGIN ATOMIC
    G := READ_CURRENT_GENERATIONS()   # g_air, g_rev, g_pol
    IF handle.g_rev < G.g_rev AND REVOKES(G, handle):
                                                  ABORT DENY(EF-062)
    IF handle.g_air < G.g_air AND AFFECTS(G.airspace_delta, U):
                                                  ABORT DENY(EF-061)
    IF handle.g_air < G.g_air AND NOT AFFECTS(G.airspace_delta, U):
        NOTE(GEN_ADVANCED_NOT_AFFECTING)  # only if AAO permits
    IF NOT CONSUME(handle, U, reuse_policy): ABORT DENY(CONSUMED)
    R := MAKE_RECEIPT(ALLOW, dU, raw_handle_digest,
                      CTX_DIGEST_IF_PRESENT(C),
                      n := counter + 1, prev := r_last)
    COMMIT(R)                         # crash-consistent, monotonic
  END ATOMIC
  IF COMMIT_STORE_UNAVAILABLE: DENY(EF-081)        # fail closed

  # 5. Release only after receipt commit.
  RELEASE(sink, SCOPED_ENABLEMENT(U, handle, t_expiry))
  EMIT_ACT_EVIDENCE(R)                # broadcast evidence, optional
  RETURN ALLOW

PROCEDURE DENY(code):
  # dU and C may be NULL for an early parsing or signature failure.
  # The denial receipt records only values already established by the PED.
  R := MAKE_DENY_RECEIPT(code = code,
                         act_digest = dU,
                         raw_handle_digest = raw_handle_digest,
                         ctx_digest = CTX_DIGEST_IF_PRESENT(C),
                         sink_id = sink.id,
                         n = counter + 1,
                         prev = r_last)
  IF COMMIT(R):
      EMIT_ACT_EVIDENCE(R)
  sink.enable := DISABLED             # unchanged
  SELECT_SAFE(MAP_TO_SAFE_STATE(IF_DEFINED(U.act_class), code))
  RETURN DENY

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 Section 13.¶

9.3. Representative Hot-Path Cost Model

For a locally cached authority path, a representative verification latency may be decomposed as:¶

  T_verify =
      T_parse
    + T_lookup
    + T_MAC
    + T_hash
    + T_replay
    + T_receipt
    + T_compare

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.¶

9.4. 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¶

  E = { u : |v(u)| <= v_max, |a(u)| <= a_max, h_min <= h(u) <= h_max,
            p(u) in Corridor_k }      over window W = [t_s, t_e]

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.¶

10.1. Corridor Containment and Envelope Predicates

 P_corr(t)  :=  p(t) in Corridor_k  AND  h_min <= h(t) <= h_max
 P_time(t)  :=  t_start <= t <= t_end
 P_vel(t)   :=  |v(t)| <= v_max  AND  |a(t)| <= a_max
 P_gen      :=  g_air(handle) = g_air*  OR
                (g_air(handle) < g_air* AND delta(g_air*) does not
                 intersect Corridor_k over [t, t_end])
 P_rev      :=  NOT revoked(handle, g_rev*)
 P_payload  :=  p(t) in DropZone  AND  h(t) <= h_drop_max
                AND |v(t)| <= v_drop_max AND tilt(t) <= tilt_max
 P_sensor   :=  footprint(p(t), attitude, fov) subset of PermittedArea
                AND res_class <= res_permitted

Starred quantities are read inside the atomic section of Section 9. P_sensor uses the projected sensor footprint rather than aircraft position, because a camera outside a protected area can still image inside it.¶

10.2. 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¶

   s_stop(v_max) = v_max * tau + v_max^2 / (2 * a_brk)

For the aircraft never to leave Corridor_k undetected, the following condition is sufficient:¶

   v_max * Delta_r + s_stop(v_max) + eps_pos  <=  d(t)

   =>  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.¶

10.3. 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¶

   for all i, j :   |p_i - p_j|  <=  k * (sigma_i + sigma_j)
   eps_pos      :=  k * max_i sigma_i
   count of agreeing sources  >=  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.¶

10.4. Ordering and Residual-Risk Decomposition

For every allowed act the following ordering holds:¶

   t_verify_static  <  t_read_current  <=  t_consume  <=  t_commit(R)
                    <  t_release       <   t_effect

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):¶

   residual_risk := {
       eps_hash, eps_sig, eps_store, eps_path, 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.¶

16.1. 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.¶

16.2. Architecture and Protected State

 +--------------------+       +--------------------+
 | Traffic sources    |       | Protected ownship |
 | cooperative /      |       | GNSS / IMU / VIO  |
 | non-cooperative    |       | time / flight state|
 +---------+----------+       +---------+----------+
           \                            /
            \                          /
             v                        v
          +------------------------------+
          | DAA computation engine       |
          | proposes resolution M        |
          +--------------+---------------+
                         | Candidate M
                         v
          +------------------------------+
          | Protected DAA Finality Domain|
          | ConflictSetRoot | ResEpoch   |
          | current-set revalidation     |
          +-----------+------------------+
                      | scoped motion capability
                      v
          +------------------------------+
          | Motion-admission Finality Sink|
          | reconstruct actual trajectory |
          +-----------+------------------+
                      | match + current safety
                      v
                 Flight controller
                      |
            deny ---->+----> 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.¶

16.3. Conflict-Set and Safety Mathematics

  C_root = H( CanonicalSort(I_1 || I_2 || ... || I_n) )

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:¶

  t_CPA,j = clamp( -(r_j . v_j) / ||v_j||^2, 0, T )

  d_CPA,j = || r_j + v_j * t_CPA,j ||

  m_j(M) = d_CPA,j(M) - (D_req,j + epsilon_j)

  MultiIntruderSafe(M) <=> 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.¶

  Eq(C_auth, C_now) =
       SameRelevantMembers
    AND FreshEnough
    AND DeltaUncertainty <= U_max
    AND NoNewHigherRiskTrack

  Accept(M) =>
      M.resolution_epoch == CurrentResolutionEpoch

16.4. 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.¶

16.5. DAA Finality Pseudocode

PROCEDURE FINALIZE_DAA_RESOLUTION(candidate_M, descriptor, sink):
  ASSERT sink.motion_expansion == DISABLED

  own_auth := READ_PROTECTED_OWNSHIP()
  C_auth   := LOAD_CONFLICT_SET(descriptor.conflict_root)

  REQUIRE descriptor.resolution_epoch == CURRENT_RESOLUTION_EPOCH()
  REQUIRE FRESH(own_auth)
  REQUIRE REQUIRED_TRACKS_FRESH(C_auth)
  REQUIRE HASH(candidate_M) == descriptor.maneuver_digest
  REQUIRE sink.id == descriptor.sink_id

  FOR EACH intruder j IN C_auth:
      REQUIRE SAFETY_MARGIN(candidate_M, own_auth, j) >= 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

17.1. 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.¶

17.2. Emergency Scene Authority Capsule

 +----------------------+       +----------------------+
 | Responder / incident |       | Vehicle-local scene  |
 | authority service    |       | perception / sensors |
 +----------+-----------+       +----------+-----------+
            | ESAC                         | corroboration
            v                              v
       +------------------------------------------+
       | Protected Vehicle Finality Domain        |
       | incident | scene | vehicle | exception   |
       | nonce | epochs | expiry | scene digest  |
       +-------------------+----------------------+
                           | temporary capability
                           v
       +------------------------------------------+
       | Motion-admission Finality Sink           |
       | reconstruct actual path and exception    |
       +-------------------+----------------------+
                           |
                           v
                     Vehicle motion

  completion / expiry / scene exit / revocation
                           |
                           +----> 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.¶

17.3. 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:¶

  S_scene = H(
      IncidentID             ||
      ScenePolygon           ||
      LocalEvidenceDigest    ||
      TemporaryControlDigest ||
      SceneEpoch )

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:¶

  SceneCorroborated <=> 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:¶

  E(t) =
      CredentialValid
    AND IncidentCurrent
    AND SceneMatch(S_scene)
    AND VehicleMatch
    AND t <= t_exp
    AND NOT Revoked
    AND NOT Consumed

For a location-bounded emergency scene, localization uncertainty may be incorporated by dilating the authorized scene polygon by a conservative margin delta_loc:¶

  position(t) IN Dilate(ScenePolygon, 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:¶

  Allow(M) =
      E(t)
    AND ExplicitExceptionMatch(M)
    AND M IN EmergencyEnvelope
    AND HardSafety(M, state)
    AND ActualMotionMatch(M)
    AND SinkMatch
    AND PolicyEpochCurrent
    AND RevocationEpochCurrent
    AND Fresh

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.¶

  completion OR expiry OR scene_exit OR incident_change
  OR revocation OR corroboration_loss OR policy_epoch_change
  OR revocation_epoch_change OR sink_mismatch

                  => 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.¶

17.4. 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.¶

17.5. Emergency-Scene Pseudocode

PROCEDURE FINALIZE_EMERGENCY_SCENE_ACT(esac, planned_path, sink):
  BLOCK_TEMPORARY_EXCEPTION_EXPANSION()
  KEEP_SAFE_ACTIONS_AVAILABLE()

  REQUIRE VERIFY_RESPONDER_AUTHORITY(esac.authority_ref)
  REQUIRE INCIDENT_CURRENT(esac.incident_id, esac.incident_epoch)
  REQUIRE VEHICLE_MATCH(esac.vehicle_binding)
  REQUIRE NOT_REVOKED(esac)
  REQUIRE NOW() <= esac.expiry

  local_scene := BUILD_PROTECTED_LOCAL_SCENE_STATE()
  REQUIRE SCENE_MATCH(esac.scene_commitment, local_scene)

  actual_path := RECONSTRUCT_ACTUAL_MOTION(planned_path, sink)
  REQUIRE PATH_WITHIN_EMERGENCY_ENVELOPE(actual_path, esac)
  REQUIRE EXCEPTION_EXPLICITLY_COVERS(esac, actual_path)
  REQUIRE HARD_SAFETY_PREDICATES_PASS(actual_path, local_scene)

  BEGIN ATOMIC
    REQUIRE NONCE_UNUSED(esac.nonce)
    CONSUME(esac.nonce)
    R := COMMIT_EMERGENCY_RECEIPT(
           esac_digest = HASH(esac),
           scene_digest = HASH(local_scene),
           path_digest = HASH(actual_path),
           decision = ALLOW)
  END ATOMIC

  RELEASE(sink,
          TEMP_MOTION_CAPABILITY(
              incident_id = esac.incident_id,
              scene_epoch = esac.scene_epoch,
              path_digest = HASH(actual_path),
              exception_class = esac.exception_class,
              receipt_digest = HASH(R),
              expiry = esac.expiry))
  RETURN ALLOW

ON completion OR expiry OR incident_change OR scene_exit
   OR revocation OR corroboration_loss OR policy_epoch_change:
  INVALIDATE_SCENE_CAPABILITIES()
  RESTORE_ORDINARY_AUTHORITY()

18.1. 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.¶

18.2. Protected Authority State

 +---------------+            +---------------+
 | Controller A  |            | Controller B  |
 | epoch e       |            | pending e+1   |
 +-------+-------+            +-------+-------+
         \                            /
          \                          /
           v                        v
        +------------------------------+
        | Protected Authority State    |
        | current_controller_id        |
        | authority_epoch              |
        | envelope | handover_state    |
        +--------------+---------------+
                       | current controller + epoch only
                       v
        +------------------------------+
        | Governed Finality Sink       |
        | reject stale controller/epoch|
        +--------------+---------------+
                       v
                   Actuator

   PREPARE(B) -> COMMIT(epoch e+1) -> ENABLE(B)
            partial failure -> Safe-Action Set

AuthorityState[sink] = {
  current_controller_id,
  authority_epoch,
  permitted_act_classes,
  current_envelope_digest,
  handover_state,
  prepared_new_controller_id,
  prepared_envelope_digest,
  expiry,
  revocation_epoch,
  monotonic_counter,
  prior_receipt_digest
}

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.¶

18.3. 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:¶

  for all s,e,t:

      sum_c A(c,s,e,t) <= 1

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.¶

  Accept(cmd) =>
       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.¶

18.4. 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)
      |
      v
  PREPARE(B,e+1) --failure--> 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.¶

18.5. 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.¶

18.6. Control-Handover Pseudocode

PROCEDURE HANDOVER_CONTROL(sink_set, old_id, new_id, request):
  FOR EACH s IN sink_set:
      REQUIRE AuthorityState[s].current_controller_id == old_id

  REQUIRE VERIFY_CONTROLLER(new_id, request.authority)
  REQUIRE NOT_REVOKED(new_id)
  REQUIRE ENVELOPE_SAFE(request.envelope, CURRENT_CONTEXT())

  BEGIN ATOMIC
    FOR EACH s IN sink_set:
        AuthorityState[s].handover_state := PREPARED
        AuthorityState[s].prepared_new_controller_id := new_id
        AuthorityState[s].prepared_envelope_digest :=
            HASH(request.envelope)
  END ATOMIC

  REQUIRE CONTROLLER_READY(new_id, request.fresh_session_proof)

  BEGIN ATOMIC
    FOR EACH s IN sink_set:
        e_new := AuthorityState[s].authority_epoch + 1
        AuthorityState[s].authority_epoch := e_new
        AuthorityState[s].current_controller_id := new_id
        AuthorityState[s].current_envelope_digest :=
            HASH(request.envelope)
        AuthorityState[s].handover_state := COMMITTED
    R := COMMIT_HANDOVER_RECEIPT(sink_set, old_id, new_id, e_new)
  END ATOMIC

  ENABLE_CONTROLLER(new_id, sink_set, e_new, HASH(R))
  RETURN COMMITTED


PROCEDURE ADMIT_CONTROLLER_COMMAND(cmd, sink):
  S := READ_PROTECTED_AUTHORITY_STATE(sink)

  IF cmd.controller_id != S.current_controller_id:
      RETURN SAFE_DENY("STALE_OR_WRONG_CONTROLLER")
  IF cmd.authority_epoch != S.authority_epoch:
      RETURN SAFE_DENY("STALE_AUTHORITY_EPOCH")
  IF cmd.sink_id != sink.id:
      RETURN SAFE_DENY("SINK_MISMATCH")
  IF NOT WITHIN_ENVELOPE(cmd, S.current_envelope_digest):
      RETURN SAFE_DENY("ENVELOPE_MISMATCH")
  IF NOT FRESH_AND_UNUSED(cmd):
      RETURN SAFE_DENY("REPLAY_OR_STALE")

  RETURN ADMIT(cmd)

19.1. 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 [RFC9575]. 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 [RFC9575].¶
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.¶

19.2. Design

The design applies the TESLA delayed key disclosure principle [RFC4082] 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.¶

 generation (inside PED, once per epoch):
      K_seed --derive with epoch_id--> 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))

19.3. 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.¶

19.4. Construction

 F(x)   = Trunc_128( SHA-256( "UAS-AFE-chain" || x ) )
 F'(x)  = Trunc_128( SHA-256( "UAS-AFE-tag"   || x ) )

 K_seed <- random 128 bits             (generated inside PED; never disclosed)
 K_N    =  Trunc_128(SHA-256(
              "UAS-AFE-seed" || K_seed || epoch_id))
 K_i    =  F(K_(i+1)),  i = N-1 ... 0
 K_0    =  public chain commitment in the signed Anchor

 I_i    =  [ T_0 + i*Delta ,  T_0 + (i+1)*Delta ), 0 <= i < N
 K'_i   =  F'(K_(i+1))                 (tag key for interval i)
 K_(i+1) is disclosed during I_(i+d)

 hdr    =  first 8 octets of the AER (header, below)
 tag    =  Trunc_64( HMAC-SHA-256( K'_i,
             "UAS-AFE-rec" || ua_det || epoch_id || hdr ) )
 AER    =  hdr || tag                                   (16 octets)

HMAC is as defined in [RFC2104], SHA-256 as in [RFC6234]. 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.¶

19.5. Record Formats

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Ver|Knd| Act Class |Dec| SinkC |      Interval Index (16 bits) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Receipt Counter n (32 bits)                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                    Tag (64 bits, truncated HMAC)              +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Ver   (2)  = 0
 Knd   (2)  = 0 (AER)
 Act Class (6) = Table 2 code; 0x00 = UNSPECIFIED (privacy mode)
 Dec   (2)  = 00 DENY, 01 ALLOW, 10 SAFE_STATE_SELECTED, 11 reserved
 SinkC (4)  = sink class (motor, latch, RF, sensor, mode, RID, ...)

  Octet 0                     Octets 1-2                 Octets 3-18
 +------------------------+--------------------------+------------------+
 |Ver(2)|Knd(2)|Rsvd(4)   | Interval Index (16 bits) | K_(i+1) (128 b) |
 +------------------------+--------------------------+------------------+

 Header = 24 bits (3 octets); disclosed key = 128 bits (16 octets).
 Total = 19 octets.  Knd = 1 (KDR).

; Anchor: signed once per epoch by the PED evidence key (COSE_Sign1),
; repeated periodically so late-arriving Observers can verify.
afe-anchor = {
  "ua_det"    : bstr .size 16,
  "epoch_id"  : bstr .size 4,
  "ped_kid"   : bstr .size 8,
  "t0"        : uint,             ; seconds
  "delta_ms"  : uint,             ; interval length
  "d"         : uint,             ; disclosure lag in intervals
  "n_len"     : uint,             ; chain length N
  "k0"        : bstr .size 16,    ; chain commitment K_0
  "n_start"   : uint,             ; first receipt counter in epoch
  ? "aao_hint": bstr .size 8      ; optional, privacy-dependent
}
; Evidence Key Endorsement: binds the distinct PED evidence key to
; the UA DET and is signed by the UA Host Identity / DRIP identity key.
afe-endorsement = { "ua_det": bstr .size 16, "ped_kid": bstr .size 8,
                    "ped_pub": bstr, "valid_to": uint }

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 Section 19.10).¶

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.¶

19.6. Emission Rules

PED ON RECEIPT_COMMITTED(R):     # from PED_FINALIZE / DENY
  IF R.act_class NOT IN evidence_classes: RETURN
  i   := INTERVAL_INDEX(now)          # floor((now - T_0) / Delta)
  hdr := PACK(ver=0, kind=0, class=MAYBE_COARSE(R.act_class),
              dec=R.decision, sinkc=R.sink_class,
              idx=i, n=R.counter)
  K_tag_i := F'(K_(i+1))             # K'_i; derived AER key for interval i
  tag := TRUNC64(HMAC_SHA256(K_tag_i,
                 "UAS-AFE-rec" || ua_det || epoch_id || hdr))
  QUEUE_TO_RID_MODULE(hdr || tag, repeats = r_aer)
  RECORD_IN_RECEIPT(R, hdr)      # receipt n carries same header

PED EVERY INTERVAL j >= 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.¶

19.7. 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.¶

OBSERVER ON ANCHOR(A, endorsement, drip_evidence):
  REQUIRE DRIP_VERIFY_DET(A.ua_det, drip_evidence)        # RFC 9575
  REQUIRE VERIFY(endorsement, HI(A.ua_det))    # PED evidence key <- DET
  REQUIRE VERIFY_COSE_SIGN1(A, endorsement.ped_pub)
  REQUIRE A.n_len <= 60000
  STORE chain[A.ua_det, A.epoch_id] :=
      { last_key_index: 0, last_K: A.k0, A }

OBSERVER ON AER(rec, t_r):             # t_r = trusted local receive time
  a := chain[det, epoch];  IF a IS NONE: BUFFER(rec); RETURN
  IF NOT CLOCK_ERROR_BOUNDED(delta_max):
      STORE_FOR_AUDIT_ONLY(rec); RETURN
  i := UINT16(rec.idx)
  IF i >= 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.¶

19.8. 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).¶

19.9. Size and Cost Comparison

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.¶

19.10. 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.¶

21.1. 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 / administrative side                 Physical system side

  +----------------------------+                  +-----------------------+
  | identity / DET / PKI       |                  | perception / planner  |
  | attestation / Evidence     |                  | DAA / ADS / autopilot |
  | UTM, U-space, V2X state    |                  +-----------+-----------+
  | responder / operator auth  |                              |
  | revocation / policy state  |                              | Candidate Act
  +-------------+--------------+                              v
                |                                 +-----------------------+
                | authenticated /                 | Protected Enforcement |
                | integrity-protected             | Domain                |
                | protocol objects                | - current authority   |
                +-------------------------------> | - 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.¶

21.2. Mapping of the Three Extended Embodiments

Conflict-Set-Bound DAA Finality (Section 16):

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 (Section 17):

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 (Section 18):

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.¶

21.3. 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.¶

25.1. 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.¶

25.2. 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.¶

25.3. 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.¶