Remote ID Solved "Who Is Flying." It Never Solved "Who Allowed That."

Actuator-Level Execution Finality and 16-Octet Broadcast Act Evidence for UAS and Autonomous Vehicles

Sangam Das · Independent Inventor · Balasore, Odisha, India · info@sangamdas.com Companion disclosure to Internet-Draft draft-das-drip-uas-act-finality-00 License: CC BY 4.0 (text) · Patent rights expressly reserved — see §7

 

Abstract

Problem. An uncrewed aircraft is a moving actuator. Its outputs are physical, immediate and usually irreversible: a rotor that spins up near people, a payload that leaves its latch, a camera frame captured over a private garden, a transmitter keyed on a protected band. Current UAS governance authorizes the flight, identifies the aircraft, and records what happened. It does not make an individual consequential act depend on authority verified at the actuator at the moment of effect. Authorizations are granted before or at take-off; acts are executed continuously, thousands of times per flight, by mission computers and autonomy stacks that can be compromised, misled, coerced with validly signed commands, or cut off from the authorities that issued them. An Observer on the ground — a police officer, a facility operator, a bystander — can cryptographically verify which registered entity owns the aircraft overhead, and can verify nothing at all about what it is doing.

Where present solutions fail. Broadcast and Network RID answer "who is this?". DRIP answers "is that identity and this message genuine?". UTM, U-space and LAANC answer "may this flight take place here and now?". Geo-awareness answers "am I inside a permitted volume?" — usually in software co-located with the stack that can fail. MAVLink 2 signing and SecOC-style MACs answer "did a key holder send this?" — a valid key holder may still command a contextually unauthorized act. Secure boot and remote attestation answer "did the expected software boot?" — runtime deviation, coercion and stale authority all remain possible afterwards. Flight logs answer "what happened?" — after the effect. Each of these is necessary and well engineered. None of them, alone or stacked, makes one specific act non-effective until authority for that act is verified against current state and consumed at the actuator. The gap is structural, not a matter of stricter policy.

Solution. Every safety-significant or externally consequential act remains a Candidate Act with no physical effect until a Protected Enforcement Domain (PED) — positioned on every command-to-enablement path — verifies an act-bound, sink-bound Execution Handle against live trusted context, atomically consumes current authority state, commits a Finality Receipt, and only then releases the physical enablement condition at the Finality Sink: the ESC enable line, the latch solenoid power window, the camera power rail, the PA enable, the mode register. A compromised command source cannot synthesize actuator authority, because it never physically held it.

What is new here. Principally, Compact Broadcast Act Evidence: fixed 16-octet Act Evidence Records authenticated with a TESLA-style one-way key chain sealed inside the PED and anchored once through the aircraft's DRIP identity, letting an Observer verify — inside the 25-octet Broadcast RID budget, with no public-key signature per act, and with loss tolerance — that the enforcement domain made an allow, deny or safe-state decision before the corresponding key could have been disclosed. Around it: a mapping of nine UAS act classes to concrete sinks and withheld conditions; envelope handles for hundreds-of-hertz control streams; a boundary-proximity revalidation bound; a bounded offline exposure model; composite multi-aircraft semantics whose prepare step moves no aircraft; and three cross-domain profiles for detect-and-avoid resolution finality, emergency-scene temporary authority for road vehicles, and atomic control-authority handover.

Status. Patent pending (§7). Submitted to the IETF standards process as an individual Informational Internet-Draft; runnable reference implementation published (§8). Civil scope only — weapons, weapon release, targeting and counter-UAS engagement are excluded.

 

1. Problem Space

1.1 The officer who can verify everything except the thing that matters

A drone is hovering over a stadium car park at 40 metres. Its camera is live. A payload is being lowered.

An officer standing underneath, holding a phone, can do something genuinely impressive: using Broadcast RID and DRIP, with no Internet connection, she can verify that these messages originate from the registered holder of a specific DRIP Entity Tag, and that they have not been spoofed or replayed. Identity is solved. The plumbing works.

She now asks the only operational question she actually has: was that camera allowed to be on, here, right now? Was that drop authorized at this coordinate?

Nothing in the stack answers her. The aircraft is broadcasting who it is, forever, at 1 Hz, and broadcasting nothing whatsoever about whether its conduct was permitted before it occurred. She can subpoena logs tomorrow. The frames were captured today.

This is not an edge case. It is the normal state of every compliant drone flying right now.

1.2 Six civil situations, each inside a validly authorized flight

The gap is easiest to see in cases where nobody did anything wrong at the flight level.

(1) The restriction that arrives at 14:07. 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 and will remain valid. The next corridor segment is no longer lawful. Whether the aircraft enters depends entirely on whether new geo-zone data reached — and was obeyed by — software that may be stale, misconfigured, or compromised. Validity and lawfulness have silently diverged, and nothing at the actuator notices.

(2) The owned mission computer. The perception or planning stack is fed adversarial input, runs a faulty update, or is under an attacker with root. If that process has effective write access to motor output registers, ESC arming, the payload latch driver, or the camera power rail, a software failure has become a physical event. Critically, a software-only geofence running on the same processor is subject to the same failure — it can be patched out, starved, or simply lied to. The safety mechanism and the thing it restrains share a fate.

(3) The validly signed, unsafe command. A ground station, fleet service or remote pilot sends a correctly authenticated command: release the payload at this unapproved coordinate, disable RID transmission, enter that volume. MAVLink 2 signing does exactly what it promises — it establishes that the command came from a key holder. It was never designed to establish that this act is permitted in the present context. Authentication is an origin claim, and origin is not permission. An insider, a stolen key, a coerced operator, and a compromised fleet service all produce perfectly valid commands.

(4) Degraded or lost link. The aircraft loses contact with its operator, its USS/USSP and its revocation source. A revocation issued after link loss cannot be learned — there is no channel on which to learn it. Without an explicit bound, cached authority may continue permitting acts indefinitely. "It kept flying on cached authority" is currently an unbounded, unquantified, unauditable condition.

(5) The half-executed coordinated manoeuvre. Several aircraft must change formation or hand off an inspection segment together. If some commit and others do not, the separation assumptions underlying the whole operation are violated — and the retries and compensations intended to fix it are themselves new physical acts, issued into a state nobody has re-verified.

(6) The unverifiable Observer view. As in §1.1. Broadcast RID messages are 25 octets. A per-act Ed25519 signature is 64 octets before identifiers and timestamps, spanning several Authentication Message pages on a transport where pages are routinely lost and DRIP FEC recovers only one. Per-act public-key evidence is not merely expensive here; at realistic decision rates it does not fit.

1.3 Why this is structural

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

Three properties make the gap resistant to being closed by better policy or more careful engineering within the existing layers:

• Authority is granted early; consequence occurs late and continuously. The interval between "cleared" and "acting" is where restrictions activate, revocations issue, conditions change, and compromise happens. Every existing check lives at the start of that interval.
• The checker shares a failure domain with the thing being checked. Software geofences, mode logic and command validation typically run on the same processor as the autonomy stack. A single compromise removes both the capability limit and the limiter.
• Nothing is withheld physically. Today the actuator is always capable of acting; software merely chooses not to. Safety is therefore a property of correct software behaviour rather than of unavailable capability. Under compromise, correct behaviour is exactly what is missing.

The consequence is a governance model that authorizes flights, identifies aircraft and audits the past — while leaving the instant of physical effect ungoverned.

 

2. Where Present Solutions Fail — Layer by Layer

Mechanism	Question it answers well	Why it does not close the gap
Broadcast / Network RID (ASTM F3411; 14 CFR Part 89; EU 2019/945)	Who is this aircraft, where is it, who operates it?	Identity and telemetry only; carries no act-level authority and no statement about permission
DRIP: DET (RFC 9374), architecture (RFC 9434), authentication (RFC 9575), DET/DIME in DNS (RFC 9886)	Who controls the claimed DET; can its material be resolved and verified?	Establishes trustworthy identity, resolution and message provenance — not whether a physical act was authorized before it occurred
UTM (ASTM F3548), U-space (EU 2021/664), LAANC	May this flight or operation take place in this airspace and time?	Strategic and tactical flight authorization; onboard enforcement is delegated entirely to the aircraft
Geo-awareness, ED-269 geo-zone data, autopilot geofences and failsafes	Is the aircraft inside a permitted volume, and what if not?	Software-mediated, co-located with the stack that can fail; movement-centric, so payload, sensor and RF acts are uncovered; not bound to consumable per-act authority
MAVLink 2 signing; SecOC-style truncated MAC with freshness	Did this message come from a key holder, and is it fresh?	Authenticates channel and sender; a valid key holder may still request a contextually unauthorized act
Secure boot, measured boot, remote attestation (RFC 9334)	Is the software that booted the expected software?	Establishes platform state at boot; runtime deviation, coercion and stale authority persist afterwards
Flight logs, post-flight analysis, Network RID records	What happened?	After the fact. The effect has already occurred

Read down that right-hand column and the shape of the hole is exact: identity without conduct, flight-level permission without act-level enforcement, origin without context, boot-time assurance without runtime finality, and accountability only in retrospect.

The proposal here adds nothing to those layers' jobs and takes nothing away. It occupies the one position none of them holds: after all of them have finished, before the actuator moves.

 

3. Solution: Execution Finality at the Actuator

3.1 The invariant

An authenticated or correctly computed instruction remains a Candidate Act until the current effectuation boundary independently verifies the state on which that instruction depends.

Computation does not itself confer authority for consequence. Neither does authentication, nor a valid token, nor a correct plan.

3.2 The sequence

A safety-significant act is non-effective until, at the sink:

1. an act-bound and sink-bound Execution Handle is presented (non-bearer: possession alone is not authority);
2. the PED reconstructs the concrete pending act and verifies the handle against it, not against a caller-supplied digest;
3. live trusted context is checked — corridor containment, multi-source position consistency, generation currentness, revocation state — with currentness read inside the atomic section, so that a revocation landing mid-check cannot be raced;
4. authority state is atomically consumed;
5. a Finality Receipt is committed;
6. only then is the physical enablement condition released at the sink.

Any failure fails closed into a safe state. The enablement condition is a physical line or gated rail wherever the sink is reached over a bus, so that a compromised bus master cannot assert it.

3.3 Act classes and the conditions withheld

Act class; reuse	Example	Finality Sink	Withheld condition
ARM; single-use	Arm motors for take-off	ESC arming register / enable line	ESC enable asserted
KINETIC_ENVELOPE; envelope	Fly segment k within corridor at v ≤ v_max	Motor output register bank, thrust limit	Write window for setpoints inside envelope
VOLUME_ENTRY; single-use	Enter geo-zone Z or next corridor segment	Envelope expansion at PED	New envelope released
PAYLOAD_RELEASE; single-use	Lower or release a parcel at drop zone D	Latch solenoid or winch driver	Solenoid power window
SENSOR_ACTIVATE; envelope	Camera on, resolution R, FOV F, area A	Camera power rail or sensor-output key	Rail enable or output key
RF_EMIT; envelope	Video downlink on band B at power P	PA enable, frequency register	PA enable, register permit
MODE_TRANSITION; single-use	Assisted → autonomous BVLOS	Flight-mode register	Register write permit
RID_CHANGE; single-use	Change RID transmission state	RID module enable and configuration	Configuration write permit
COORDINATED; composite child	Formation change across N aircraft	Each aircraft's kinetic sink	Per-child release after composite commit
SAFE_STATE	Hover, loiter, descend, land, RTH	Flight-controller safe-state path	Pre-authorized — no handle required

Two of these rows are deliberate safety statements rather than mechanism. SAFE_STATE is never blocked for lack of a fresh handle: a layer that can strand an aircraft is not a safety layer. And RID_CHANGE is hostile to its own operator by design — a request that would suppress legally required RID transmission must be denied unless an authority object explicitly permits it, because the enforcement domain is precisely the component that must not be coercible into making the aircraft anonymous.

3.4 Making it survivable in real flight

Envelope handles. Motor setpoints run at hundreds of hertz, so per-setpoint public-key work is not an option. An envelope authorizes a set — |v| ≤ v_max, |a| ≤ a_max, h_min ≤ h ≤ h_max, position in Corridor_k — over a window [t_s, t_e] with an aggregate ceiling such as cumulative distance ≤ D_max. Admission becomes a bounded set of range comparisons, implementable in FPGA logic or a secure microcontroller within one control period. Leaving the set, the window or the ceiling ends the envelope; further motion needs a new handle or a safe state.

Boundary-proximity revalidation. Re-checking authority on a fixed timer is either wasteful in open airspace or too slow near a boundary. Instead:

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

Delta_r(t)   <= ( d(t) - eps_pos - s_stop(v_max) ) / v_max

At d = 60 m, ε_pos = 5 m, v_max = 15 m/s, a_brk = 5 m/s², τ = 0.1 s: s_stop = 24 m and Δ_r ≤ 2.07 s. At d = 30 m the bound collapses to 0.07 s — so the PED does not revalidate faster, it lowers v_max to 8 m/s, restoring Δ_r ≤ 2.23 s. If the right-hand side goes non-positive, outward motion is not released at all. Revalidation is additionally event-triggered: new generation, waypoint transition, altitude-band change, payload-state change, RF-mode change, sensor disagreement, thermal or battery thresholds.

Bounded offline operation. Link loss stops being an open-ended condition and becomes a number:

t_off_end   = min( t_L + T_off_max, h.t_end for each handle h )

T_exposure <= T_off_max

D_exposure <= v_max * T_off_max

Operators and authorities choose T_off_max per operation class. Payload release and sensor activation should not appear on the offline class list at all.

Composite acts. For multi-aircraft manoeuvres, the prepare step is a consume-state reservation that moves no aircraft, HOLD is a physically safe holding manoeuvre rather than an abstract state, auto-commit on coordinator silence is forbidden, reserve TTL fails closed, and compensation is always a new Candidate Act with a new handle — never an undo on a consumed one.

 

4. What Is New Here

1. Compact Broadcast Act Evidence — the principal contribution.

The naive approach is to sign each act with the DET key. Four walls stop it: size (64-octet signature into a 25-octet message, spanning pages), loss (paged Authentication Messages, single-page FEC recovery), rate and energy (decisions several times per second on a small controller), and decisively origin — the DET key usually lives in the RID module or flight software, which is the very component this mechanism exists to survive. Evidence signed with it proves the aircraft's software sent it, not that the enforcement domain decided it. A compromised mission computer holding the RID key could broadcast "authorized" for acts the PED denied.

So: a TESLA-style one-way key chain generated and sealed inside the PED, with a distinct PED evidence key endorsed once by the aircraft's DRIP/HI identity — a DRIP-compatible statement that "this PED evidence key speaks for this DET."

K_seed --derive with epoch_id--> K_N --F--> ... --F--> K_1 --F--> K_0

K_seed never disclosed;  K_0 = public chain commitment, in the signed Anchor

records in interval i are tagged with  K'_i = F'(K_(i+1))

K_(i+1) is disclosed d intervals later

a lost disclosure is recovered from any later one:  K_(i+1) = F^(j-i)(K_(j+1))

Act Evidence Record (AER), 16 octets: version, kind, act class, decision (DENY / ALLOW / SAFE_STATE_SELECTED), sink class, 16-bit interval index, 32-bit receipt counter, 64-bit truncated HMAC-SHA-256. Key Disclosure Record (KDR), 19 octets: one per interval, shared by every record in it.

	Per-act octets on air	Onboard op per act	Loss behaviour	Origin proven
DET-signed structure per act	≥64-octet signature plus identifiers and timestamps; multi-page on legacy transport	One public-key signature	A lost page may lose the record	Key holder of the DET (often RID module or flight software)
AER with delayed disclosure	16 (+ one 19-octet KDR per interval)	One HMAC-SHA-256	Lost KDR recovered from any later KDR	PED only

Honest boundaries on the claim: a verified AER establishes that the endorsed PED emitted decision n during interval i with that act class, decision and sink class — and, combined with DRIP-authenticated Location/Vector messages from the same interval, 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 themselves evidence of misconduct), or anything about the authority object's contents beyond an optional hint. Forgery resistance is ~2⁻⁶⁴ per attempt, chosen deliberately because this is evidence, not authority — an AER, KDR or Anchor must never be accepted as a handle, and a receipt presented as a handle is refused. Act class 0x00 is UNSPECIFIED, a privacy mode, because a per-act behavioural stream broadcast over a city is its own hazard.

2. A constrained execution-proof transport profile — Beacon Proof Capsules with compact Authority References, keyed act/sink/context commitments, explicit collision and attacker-work sizing for truncated values, authenticated fragmentation, and fail-closed resolver semantics. A BPC is verification input and is never accepted as broadcast evidence merely because it arrived.

3. The act-class-to-sink-to-withheld-condition mapping of §3.3, which turns "enforce policy" into named physical conditions.

4. The placement rule: the PED sits on every command-to-enablement path, so a compromised command source cannot synthesize actuator authority.

5. Live-context enforcement: corridor containment, multi-source position consistency, generation currentness read inside the atomic consume, and the conservative revalidation scheduling policy of §3.4.

6. Envelope handles, bounded offline exposure, and composite semantics with a non-moving prepare and a physically safe HOLD.

7. Three cross-domain profiles, same invariant:

• Conflict-set-bound DAA finality — an accepted avoidance resolution is bound to the conflict set, ownship state, motion sink and a monotonic Resolution Epoch; the sink revalidates the current conflict set and all relevant intruders before admitting the manoeuvre, because a resolution computed against a world that has since changed is merely a well-formed instruction.
• Emergency-scene temporary authority (road vehicles, informative) — a responder's instruction is bound to incident, scene, vehicle, a bounded traffic-rule exception, a concrete motion, an expiry and independent local scene corroboration, and extinguishes automatically when the scene authority ceases to apply. The boundary is a protected motion-admission gate rather than a motor gate, so it coexists with existing perception, planning, braking, steering and minimal-risk-control functions.
• Atomic control-authority handover — protected current-controller state plus monotonic Control Authority Epochs, so two otherwise-valid controllers cannot simultaneously acquire ordinary effectuation authority over the same governed sink.

 

5. Why This Cannot Be One Vendor's Feature

Authority originates outside the aircraft: corridor approvals, temporary restrictions, geo-zone data, operator credentials, revocations and payload permissions come from USS/USSPs, U-space service providers, authority interfaces, fleet operators and customers. Every enforcement domain must interpret their outputs identically, or each airframe re-implements ad hoc checks that cannot be audited against one another.

Evidence must be verifiable by parties who did not issue the authority — regulators, insurers, investigators, Observers — which requires defined formats and verification rules rather than vendor telemetry. Constrained links force interoperable compactness: 25-octet broadcast messages, 8-octet classic CAN payloads. And multi-aircraft, multi-authority acts cross administrative domains, requiring common prepare, commit, abort and hold semantics.

IETF/IRTF relevance: DRIP (DET-anchored compact act evidence for Observers), RATS (attestation of the enforcement domain), COSE/CBOR (deterministic compact objects), ACE (constrained scoped authorization as input, never effectuation), SCITT (later audit of receipts), T2TRG (constrained things with multiple authorities).

 

 

 

FAQ — UAS / Autonomous-Vehicle Execution Finality

 

This FAQ addresses questions that standards reviewers, safety engineers, cryptographic reviewers, avionics engineers, autonomous-vehicle engineers, and red-team reviewers are likely to raise about the UAS-Autonomous-Vehicle-Execution-Finality reference architecture and harness.

The answers are intentionally conservative. They distinguish what the reference model demonstrates from what a production deployment would still need to prove.

 

1. Does execution finality sit inside the flight-control or drive-by-wire inner loop?

Not necessarily, and usually it should not.

The architecture is intended to separate:

● high-rate stabilization or control loops;

● lower-rate authorization, policy, and envelope decisions; and

● the final consequence-bearing boundary.

A 200–1000 Hz stabilization loop should not be forced to perform a full cryptographic authorization transaction for every control tick.

Instead, the preferred pattern is:

```text
slow / medium-rate authority decision
        |
        v
protected verification
        |
        v
bounded execution envelope / handle
        |
        v
high-rate local control within that envelope
```

The high-rate controller can continue operating locally as long as the current act remains inside the already verified envelope. Revalidation is required when the envelope expires, a protected generation changes, the act leaves the permitted range, or another load-bearing condition changes.

The reference architecture therefore distinguishes per-act finality from pre-authorized high-rate envelope execution.

A production system must still measure worst-case execution time on the target MCU/SoC/FPGA and demonstrate that the selected enforcement placement does not violate control-loop deadlines.

 

2. What is the exact latency overhead on a low-power microcontroller?

The repository does not claim a universal microsecond figure.

The correct answer depends on:

● processor architecture;

● clock rate;

● hardware crypto support;

● memory hierarchy;

● persistent-state mechanism;

● secure-element latency;

● serialization format;

● transport framing;

● number of protected lookups;

● receipt persistence method; and

● whether the decision is a cold-path authorization or a hot-path envelope check.

The reference implementation measures software-path latency only. Those measurements are useful for relative engineering comparison, but they are not a substitute for target-hardware WCET analysis.

A production implementation should report at minimum:

```text
T_verify =
    T_parse
  + T_lookup
  + T_hash
  + T_MAC
  + T_replay
  + T_current_state
  + T_receipt_commit
  + T_compare
```

and separately report worst-case and percentile results for the actual deployment hardware.

 

3. Could the finality layer destabilize an aircraft or vehicle if authorization becomes unavailable?

A correct deployment should not translate “authority unavailable” into “physically freeze the vehicle.”

The architecture distinguishes permission-expanding acts from a pre-authorized Safe-State Set.

Examples may include:

● hover;

● loiter;

● controlled braking;

● minimal-risk stop;

● controlled descent;

● return-to-home;

● reduced-speed mode;

● payload lock; or

● another platform-defined safety action.

The exact Safe-State Set is not defined universally by this repository. It must be supplied by the platform safety architecture.

The intended rule is:

> Loss of fresh authority must not silently expand authority, but it also must not remove a separately pre-authorized safety action that is required to reduce physical risk.

 

4. What happens if a coordinated multi-aircraft decision log becomes unreachable?

Silence must not be interpreted as approval.

However, “no commit on silence” does not require an unsafe stationary HOLD.

A deployment may define a bounded offline or degraded-mode policy such as:

```text
coordinated authority unavailable
        |
        v
do not accept new coordinated expansion
        |
        v
retain only previously authorized safe envelope
        |
        v
execute local deconfliction / loiter / return / landing
```

The important invariant is that loss of the coordination log cannot create new authority.

Liveness is handled by the Safe-State Set, bounded residual authority, local collision-avoidance rules, and deployment-specific degraded-mode policy, not by converting missing authorization into permission.

 

5. Is this safety-over-liveness design too conservative?

The architecture is deliberately conservative at the authority boundary, but it does not require the physical controller to stop functioning.

The design separates two questions:

1. May the system perform a new consequence-expanding act?

2. What safety-preserving behavior remains permitted if the answer is no?

A deployment that simply freezes an aircraft or vehicle in a hazardous environment would be poorly designed even if its authorization logic were cryptographically correct.

Execution finality is therefore intended to be composed with—not replace—the platform’s safety controller and minimal-risk behavior.

 

6. Does “privacy mode” defeat the transparency purpose of Act Evidence Records?

It can, if designed carelessly.

The purpose of an UNSPECIFIED or privacy-preserving act class is not to hide whether a protected decision occurred. It is to avoid broadcasting more sensitive operational detail than is necessary.

A privacy-preserving record can still expose:

● that a protected decision occurred;

● the decision class;

● the relevant device or epoch binding;

● timing information within the permitted granularity;

● an act commitment;

● a sink or sink-class commitment; and

● later-verifiable authenticity.

A privacy profile should therefore distinguish:

```text
publicly verifiable decision evidence
        !=
public disclosure of every act parameter
```

Where a regulator, auditor, or authorized investigator requires full detail, the deployment may retain a protected local receipt or selectively disclose the committed act under the applicable legal process.

The repository does not claim that one privacy profile is appropriate for all jurisdictions.

 

7. If observers cannot see the exact camera activation event, what is being audited?

Potentially three different layers:

1. Public evidence: a compact record showing that a protected decision occurred.

2. Protected local evidence: the full Candidate Act and receipt retained in protected storage.

3. Authorized later disclosure: a mechanism for proving that the full act matches the earlier public commitment.

This allows the system to separate public transparency from unnecessary real-time disclosure of sensitive operational detail.

The important cryptographic requirement is that later disclosure must match the earlier commitment and must not allow the historical record to be rewritten.

 

8. Does spatial finality require GNSS + VIO + odometry in every vehicle?

No.

The architecture should not mandate a fixed sensor stack.

A rule such as “q-of-n independent or sufficiently diverse agreeing sources” is a profile choice, not a universal requirement that every deployment use GNSS, VIO, odometry, radar, LiDAR, or any particular technology.

A vision-centric platform may instead use multiple independently evaluated sources or confidence channels within its own architecture, provided the deployment can justify the relevant independence and uncertainty model.

The core requirement is:

> The protected boundary must have a defined, auditable basis for deciding whether the context required by the act is sufficiently trustworthy.

The repository should not be read as prescribing a particular commercial sensor strategy.

 

9. What if one localization source becomes unavailable or degraded?

The profile should specify degradation behavior.

Possible responses include:

● reduce the permitted motion envelope;

● increase the uncertainty margin;

● require a shorter revalidation interval;

● prohibit outward motion near a protected boundary;

● switch to a lower-authority mode;

● use a Safe-State action; or

● deny the act if the minimum evidence threshold is no longer met.

A missing sensor must not automatically be treated as a zero-error sensor.

UNKNOWN and EMPTY are intentionally distinct states.

 

10. Could strict multi-source agreement become a denial-of-service vector?

Yes, if implemented naively.

An attacker may attempt to degrade one sensor, create disagreement, or force the system into repeated revalidation.

That is why the policy must separate:

● safety-critical disagreement;

● expected sensor degradation;

● source independence;

● source health;

● uncertainty expansion; and

● safe degraded operation.

The finality layer should not attempt to solve sensor fusion by itself. It consumes a protected context decision and applies explicit fail-safe policy to the consequence-bearing act.

 

11. How much memory does deterministic encoding and BPC verification require on a small MCU?

The repository does not claim one fixed footprint.

A constrained implementation does not need to instantiate a large general-purpose object model.

Possible implementation strategies include:

● fixed-layout structs;

● compact integer keys;

● streaming parsers;

● preallocated buffers;

● profile-specific field sets;

● fixed-size digests;

● precomputed authority tables; and

● hardware HMAC/SHA acceleration.

The IETF-facing canonical representation defines interoperability semantics. A production embedded implementation may use a fixed internal representation as long as the externally committed bytes are canonical and unambiguous.

The correct engineering question is not “Can a full desktop CBOR stack run at the actuator?” but:

> What is the smallest deterministic representation and verification path that preserves the required binding semantics on the target hardware?

 

12. Must every Finality Sink parse CBOR?

No.

A Finality Sink may consume a compact, pre-parsed, sink-local capability emitted by the protected enforcement domain.

For example:

```text
Candidate Act / BPC / richer object
        |
        v
PED verification
        |
        v
fixed-size sink capability
        |
        v
Finality Sink
```

The sink can therefore remain extremely small.

The full canonical object need not be decoded independently by every actuator microcontroller.

 

13. Can the BPC fit inside an 8-byte CAN frame?

Not in every profile, and that should not be claimed universally.

Possible deployment approaches include:

● a profile-specific reduced BPC;

● authenticated fragmentation;

● CAN FD;

● transport-layer segmentation;

● a short local Authority Reference plus protected local state;

● a sink-local capability instead of the original BPC; or

● a higher-layer gateway that verifies the larger object and emits a compact actuator token.

Classic CAN constraints are therefore an implementation/profile question, not a reason to weaken the binding semantics.

 

14. Why not simply use CAN authentication or a MAC on the command?

A MAC answers:

> Was this message created by an entity holding the key?

Execution finality asks additional questions:

● Is this the exact act that was authorized?

● Is it intended for this sink?

● Is the authority still current?

● Has the nonce already been consumed?

● Has policy or revocation state changed?

● Is the act still inside the authorized envelope?

● Is this controller still the current controller?

● Can an alternate path bypass the intended sink?

Message authentication is necessary in many deployments, but it is not equivalent to final effectuation authorization.

 

15. What happens when a high-rate trajectory envelope is revoked?

A production profile should define an immediate transition rule.

Conceptually:

```text
current envelope valid
        |
        v
high-rate execution permitted
        |
   revocation / epoch change
        |
        v
no new permission-expanding setpoints
        |
        v
enter Minimal-Risk / Safe-State behavior
```

The exact transition may depend on current speed, road geometry, airspace, obstacle state, braking distance, and controller architecture.

The important property is that revocation does not require continuing to honor stale permission merely to preserve liveness.

 

16. Does a revocation instantly remove every control output?

It should not remove outputs that are independently authorized as necessary safety actions.

For example, a vehicle whose forward-motion envelope is revoked may still need authority to brake.

This is why the architecture distinguishes:

● ordinary consequence-expanding authority;

● envelope authority; and

● pre-authorized safety-increasing actions.

Fail-closed at the authority layer should not mean “disable the laws of control.”

 

17. How is TOCTOU handled between an early authorization check and effectuation?

The deciding protected state is re-read close to the final commit.

A representative ordering is:

```text
static verification
        <
read current protected state
        <=
consume freshness / nonce
        <=
commit receipt / state update
        <
release bounded capability
        <
effectuation
```

An early successful check therefore does not guarantee later effectuation if a relevant generation changes before the protected commit.

This is one of the main differences between “fresh observation” and “commit-time guarantee.”

 

18. What if revocation changes one microsecond after the atomic commit?

No architecture can make a decision depend on information that does not yet exist.

The relevant property is a well-defined linearization point.

A deployment must define:

● when authority is considered consumed;

● when revocation becomes effective;

● whether a released capability has a bounded lifetime;

● whether the sink must recheck an epoch;

● and how much residual exposure is acceptable.

For high-risk actions, the capability can be extremely short-lived and sink-local.

 

19. What prevents replay of a valid execution handle?

Single-use handles are bound to protected replay state.

The reference model expects:

```text
nonce unused
        |
        v
atomic consume
        |
        v
receipt commit
        |
        v
capability release
```

Concurrent attempts against the same nonce must not result in multiple successful releases.

The repository includes adversarial concurrency testing for this property.

 

20. Why is the sink binding necessary if the act is already signed?

Because the same logical act may have different consequences at different sinks.

A valid authorization for:

```text
camera-enable sink
```

must not automatically be reusable at:

```text
payload-release sink
```

or:

```text
motion-admission sink
```

The sink is therefore a load-bearing part of the authority basis.

 

21. What if an attacker finds an alternate path around the Finality Sink?

Then the security claim for that consequence path fails.

This is not hidden by the architecture.

Path completeness is a protected assumption.

A production deployment must analyze:

● alternate buses;

● DMA;

● debug paths;

● maintenance interfaces;

● firmware update paths;

● redundant controllers;

● power-gating paths;

● emergency override paths; and

● direct actuator interfaces.

Execution finality only controls effects that actually traverse the protected boundary.

 

22. Does the repository prove hardware non-bypassability?

No.

The repository is a software reference model and red-team harness.

It can demonstrate:

● binding logic;

● state-machine ordering;

● replay behavior;

● generation checks;

● fragment handling;

● evidence-key behavior;

● authority-handover logic; and

● modeled fault behavior.

It cannot prove physical path completeness on an aircraft or vehicle it has never been integrated into.

 

23. Does a valid AER prove that the physical act occurred?

No.

A valid Act Evidence Record proves only what the evidence construction is designed to prove—for example, that the protected enforcement domain authenticated a particular decision record under the modeled key and timing assumptions.

It does not by itself prove:

● that a motor moved;

● that a payload physically released;

● that a camera actually captured an image;

● that a vehicle changed trajectory; or

● that a downstream actuator did not subsequently fail.

Evidence of a protected decision and evidence of physical occurrence are separate problems.

 

24. Why use delayed disclosure for AER/KDR instead of signing every act?

The design goal is compact observer-verifiable evidence on constrained broadcast links.

Delayed disclosure can reduce the per-record public-key overhead while preserving a temporal property:

> The observer can later verify that the record existed before the relevant secret was disclosed.

The trade-offs include:

● delayed verification;

● clock assumptions;

● disclosure scheduling;

● packet loss;

● key-chain management; and

● late-record rejection rules.

It is therefore an optional evidence profile, not a universal replacement for digital signatures.

 

25. Can the public chain anchor be used to forge interval 0?

It must not be.

The corrected construction separates:

```text
K_seed  = never-disclosed protected master seed
K_N     = terminal chain value derived from K_seed
K_i     = F(K_(i+1))
K_0     = public commitment only
K'_i    = F'(K_(i+1))
```

The public K_0 is not itself an AER authentication secret and must not be transformed into the first interval tag key.

The repository includes negative testing for this specific indexing error.

 

26. What if one or more KDR disclosures are lost?

A later disclosed chain value can recover earlier required chain values by repeated application of the one-way function.

This is one reason for the reverse-chain structure.

Packet loss therefore need not make all earlier AERs unverifiable, although the exact retention and recovery window is profile-dependent.

 

27. How much clock synchronization does delayed disclosure require?

The observer must have a bounded timing uncertainty model.

A receiver should reject or discard an AER when its arrival time is too late to establish that the record was received before the corresponding disclosure became usable by an attacker.

The exact Delta, disclosure delay d, and allowed clock uncertainty are deployment parameters.

The architecture should not pretend that delayed-disclosure evidence is secure without a defensible time model.

 

28. What happens if the protected receipt store fails?

For a profile that requires durable receipt commitment before release:

> no durable receipt -> no ordinary capability release

This prevents “effectuate first, discover later that the audit/consume state never committed.”

A separate Safe-State path may remain available if configured.

 

29. Could receipt persistence itself become a denial-of-service target?

Yes.

That is a real trade-off.

Mitigations may include:

● redundant protected storage;

● bounded in-memory protected journals;

● hardware monotonic counters;

● failover storage;

● preallocated log segments;

● degradation to a smaller Safe-State Set; and

● explicit availability profiles.

The architecture does not claim that persistence is free. It makes the failure semantics explicit.

 

30. Why distinguish UNKNOWN from EMPTY?

Because missing state and confirmed absence are different security conditions.

Examples:

```text
EMPTY
= the protected lookup completed and found no entries

UNKNOWN
= the lookup could not establish the state
```

Treating UNKNOWN as EMPTY can create authority from missing evidence.

For load-bearing authorization state, the conservative rule is generally:

```text
UNKNOWN -> no permission-expanding effectuation
```

 

31. How does the design handle DAA traffic that changes after a maneuver was computed?

The maneuver authority can be bound to a canonical conflict set and Resolution Epoch.

If:

● a new higher-risk intruder appears;

● an existing track materially changes;

● uncertainty grows beyond the permitted bound; or

● the Resolution Epoch is superseded,

the old maneuver authorization is no longer applicable at the motion-admission boundary.

The planner may recompute immediately, but computation alone does not preserve the old authority.

 

32. Could DAA revalidation cause oscillation or repeated denial?

Yes, if the environment changes rapidly or the policy is poorly tuned.

Execution finality does not solve trajectory planning stability.

A deployment may need:

● hysteresis;

● bounded hold intervals;

● local collision-avoidance priority;

● emergency safe maneuvers;

● uncertainty-aware envelopes; and

● profile-specific revalidation thresholds.

The finality layer ensures that stale basis does not silently remain authority.

 

33. How is q-of-n emergency-scene corroboration protected against correlated sensors?

The count should not blindly treat every message as independent evidence.

The profile should account for:

● common physical source;

● common upstream processor;

● same credential lineage;

● same sensor modality;

● same communication dependency; and

● known correlation domains.

Two channels carrying the same underlying observation should not automatically count as two independent confirmations.

The repository includes adversarial testing around correlated evidence.

 

34. What if all context sensors are consistently wrong?

Then a purely context-based protected decision can still be wrong.

Execution finality is not a magical source of truth.

If every trusted input feeding the protected predicate is coherently compromised, the protected boundary may authorize an act on false context.

This is a residual risk and should be stated explicitly.

The architecture reduces unauthorized effectuation relative to its trusted inputs; it does not prove those inputs are physically correct.

 

35. What if the PED itself is compromised?

If the protected keys, monotonic state, or verification logic are compromised, the security assumptions are violated.

Possible production mitigations include:

● secure boot;

● measured boot;

● hardware key isolation;

● attestation;

● redundancy;

● independent safety MCU;

● rollback resistance;

● protected update paths;

● tamper response; and

● key rotation.

The reference harness does not claim to solve compromise of the root of enforcement itself.

 

36. Why not rely only on remote attestation?

Attestation answers a different question.

Attestation can provide evidence about:

● software identity;

● measured state;

● device configuration; or

● execution environment.

Execution finality asks:

> May this exact pending act become effective at this sink under the current authority state?

A correctly attested system can still attempt an unauthorized act.

Attestation may therefore be an input to execution finality, not a substitute for it.

 

37. Why not rely only on OAuth, signed commands, certificates, or ACLs?

These mechanisms can establish important authorization context, but they often authorize:

● a principal;

● a session;

● an API;

● a resource class; or

● a general operation.

Execution finality narrows the final question to:

```text
exact act
+
exact sink
+
current authority state
+
freshness
+
current context
```

The architecture is intended to complement existing authorization systems rather than replace them.

 

38. Does the architecture require a trusted centralized authority online for every act?

No.

Profiles may use:

● cached bounded authority;

● local protected epochs;

● short-lived grants;

● pre-authorized envelopes;

● offline Safe-State behavior; and

● delayed synchronization.

The key requirement is that offline operation have an explicit bounded authority model rather than silently treating stale cached authority as indefinitely current.

 

39. What is the maximum offline window?

There is no universal value.

The acceptable residual exposure depends on:

● vehicle speed;

● stopping distance;

● airspace/road geometry;

● update frequency;

● revocation urgency;

● mission class;

● consequence severity; and

● available Safe-State actions.

The repository exposes such values as deployment parameters rather than claiming a single safe constant.

 

40. Does fail-closed create a denial-of-service vulnerability?

Potentially, yes.

Any security boundary that can withhold authority can become a target for availability attacks.

The architecture therefore requires explicit consideration of:

● safe degraded modes;

● bounded cached authority;

● local safety autonomy;

● redundant protected state;

● transport resilience;

● replay-safe retry; and

● distinction between permission-expanding and safety-reducing actions.

Security and liveness must be engineered together.

 

41. Can a malicious planner spam the PED with verification requests?

Yes.

A production implementation may need:

● rate limiting;

● admission control;

● priority classes;

● per-controller quotas;

● bounded queues;

● constant-space parsing;

● authenticated early rejection; and

● separate safety-critical and non-critical paths.

The repository focuses on authorization semantics, not full resource-exhaustion resistance.

 

42. What prevents a large Candidate Act from becoming a parser attack surface?

A constrained profile should define:

● maximum object size;

● maximum nesting;

● permitted fields;

● canonical types;

● integer ranges;

● fixed-length digests;

● deterministic ordering; and

● rejection of unknown or duplicate critical fields.

A safety-critical implementation should not use an unrestricted general-purpose parser at the actuation boundary.

 

43. Is deterministic CBOR mandatory?

The important requirement is deterministic, unambiguous canonicalization for whatever representation is normatively selected.

If the IETF profile uses deterministic CBOR, interoperability tests should verify the exact byte representation.

An implementation may use a different internal structure as long as the protected digest is calculated over the required canonical external representation.

 

44. What happens when two semantically equivalent encodings produce different bytes?

That is precisely why a canonical representation is required.

The authority basis must not depend on parser-specific formatting choices.

If two values are intended to be semantically identical under the profile, they must canonicalize to the same committed representation.

If the profile does not define that equivalence, they should be treated as different acts.

 

45. What if a compact truncated binding collides?

Truncation introduces explicit risk.

The architecture therefore models:

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

and requires the truncation length to be selected against the expected collision domain and risk budget.

A compact commitment should not be treated as collision-free merely because it is cryptographic.

Where ambiguity is detected, the safe response is to deny or request a longer proof rather than guess.

 

46. Why not simply use a full 256-bit digest everywhere?

Some target transports are severely constrained.

The architecture therefore separates:

● full internal protected digests;

● compact transmitted references; and

● risk-bounded truncation.

Where bandwidth is not constrained, a longer commitment may be preferable.

Compactness is a profile optimization, not a security requirement.

 

47. How is control-authority handover protected against split brain?

The protected state contains the current controller and a monotonic Control Authority Epoch.

A command is accepted only when:

```text
command.controller == CurrentController
and
command.epoch == CurrentEpoch
```

The intended invariant is:

```text
for each governed sink and time:
effective ordinary controllers <= 1
```

Crash injection is used to test PREPARE, COMMIT, and ENABLE boundaries.

 

48. What happens if the new controller crashes after the old controller is revoked?

The system may temporarily have zero ordinary controllers, which is safer than having two.

A Safe-State controller or pre-authorized fallback behavior may remain active.

The architecture prefers:

```text
0 ordinary controllers + safe fallback
```

over:

```text
2 simultaneously authoritative controllers
```

when atomic handover cannot complete.

 

49. Does the repository prove the handover protocol for all distributed-system failures?

No.

The finite crash campaign provides evidence about the modeled state machine and tested schedules.

It is not a formal proof over every network partition, storage failure, Byzantine controller, or hardware reset.

A production protocol may additionally require model checking or formal verification.

 

50. Why is “evidence is not authority” emphasized?

Because audit artifacts are attractive bearer objects.

If a receipt, AER, attestation result, or observer record can later be replayed as execution authority, the architecture has collapsed two different security roles.

The intended separation is:

```text
evidence -> proves something about a past protected decision

authority -> permits a current protected effect
```

One must not silently substitute for the other.

 

51. Can the architecture support existing autopilots and drive-by-wire systems without replacing them?

That is the intended deployment model.

The architecture is designed to sit around the consequence boundary, not replace:

● stabilization;

● perception;

● path planning;

● navigation;

● braking control;

● steering control;

● certified flight-control loops; or

● existing failsafes.

Existing controllers continue to compute.

The finality layer determines whether a proposed consequence may become effective under current protected authority.

 

52. Does the architecture require a new hardware chip?

No single hardware form is mandated.

Possible realizations include:

● safety MCU;

● secure MCU;

● TEE;

● secure element plus enforcement firmware;

● FPGA gate;

● protected hypervisor partition;

● isolated controller;

● network/actuator gateway; or

● a combination of these.

What matters is whether the deployment actually enforces the required trust and path-completeness properties.

 

53. Is this an IETF protocol, a hardware architecture, or both?

The work spans both protocol and enforcement concerns, but the IETF-facing material should remain clear about what is being standardized.

Potentially standardizable pieces include:

● compact evidence formats;

● BPC structure;

● canonical binding inputs;

● Authority References;

● evidence/key-disclosure records;

● interoperability semantics;

● failure signaling; and

● verification rules.

Hardware placement examples are architectural deployment guidance unless a specific interface is standardized.

 

54. Why is this relevant to RATS?

Remote attestation can provide trusted evidence about the state of a workload, device, or protected component.

Execution finality can consume that evidence when deciding whether a specific act may become effective.

The relationship is therefore potentially:

```text
attestation evidence
        |
        v
protected authority decision
        |
        v
act-bound execution finality
```

The repository does not assume that RATS alone provides actuation authorization.

 

55. Why is this relevant to COSE / CBOR?

Constrained deployments need:

● compact canonical representations;

● authenticated structures;

● deterministic serialization;

● key identifiers;

● algorithm agility; and

● interoperable test vectors.

Those are natural points of contact with CBOR/COSE engineering.

The execution-finality architecture itself, however, is broader than any one encoding or signature/MAC format.

 

56. What is the strongest claim this repository can responsibly make?

A narrow one:

> The repository provides an executable reference model and adversarial test harness showing how selected execution-finality invariants can be represented, attacked, and tested under explicit assumptions.

It does not establish:

● airworthiness;

● automotive functional-safety certification;

● hardware non-bypassability;

● universal cryptographic security;

● production readiness;

● regulatory compliance;

● real-world sensor correctness; or

● complete correctness under every distributed-system failure.

 

57. What would falsify the architecture rather than merely expose an implementation bug?

Examples include a reproducible demonstration that, under the stated assumptions:

● a materially different act can pass the same protected binding;

● a valid proof can be moved to another sink without detection;

● the same single-use nonce can produce two effective releases;

● stale revocation state can survive the final protected commit;

● a receipt can fail to commit while ordinary capability is still released;

● a public delayed-disclosure value enables pre-disclosure forgery;

● a stale controller epoch can still become effective;

● two ordinary controllers can become simultaneously effective under the modeled handover protocol; or

● an explicitly modeled consequence path bypasses the protected sink.

Such counterexamples are exactly what the repository is intended to invite.

 

58. What type of external review is most useful?

Useful review includes:

● counterexamples to invariants;

● alternate-path bypass analysis;

● low-power MCU timing measurements;

● CAN / CAN-FD mapping experiments;

● CBOR canonicalization edge cases;

● packet-loss traces;

● delayed-disclosure timing attacks;

● crash-consistency tests;

● model checking;

● formal proofs;

● DAA stale-state scenarios;

● Safe-State failure analysis;

● correlated-sensor attacks; and

● independent implementations using the same test vectors.

Corrections, negative results, adversarial cases, and implementation criticism are welcome.

 

59. Where are the public technical materials?

GitHub reference implementation and red-team harness

https://github.com/sangmdas/UAS-Autonomous-Vehicle-Execution-Finality

IETF Internet-Draft

https://datatracker.ietf.org/doc/draft-das-drip-uas-act-finality/

Broader architectural background

https://zenodo.org/records/22082995

The Internet Solved Communication. It Never Solved Authority.

 

60. What is the core principle in one sentence?

> **Computation, authentication, or possession of a token does not by itself create authority to make a consequential act effective.**

 

6. Scope, Non-Goals and Non-Endorsement

In scope: civil UAS in the specific and certified categories and comparable national regimes — delivery, infrastructure inspection, agriculture, mapping, emergency and public-safety support, urban air mobility support functions.

Out of scope: weapons, weapon release, targeting, counter-UAS engagement. This work 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 already been issued is technically enforced at the moment of effect, and how that enforcement can be evidenced.

It replaces nothing. Broadcast and Network RID, DRIP DETs and authentication, DET resolution through DNS, UTM and U-space services, geo-awareness, detect-and-avoid, flight-control safety logic, automotive ADAS and autonomy stacks, remote-assistance systems and authenticated command channels all remain in place. This layer operates later than all of them.

Non-endorsement. Publicly described software-defined or autonomy-enabled platform classes to which such a boundary may be complementary — PX4, ArduPilot, DJI, Wing, Amazon Prime Air, Zipline, NVIDIA, Qualcomm, Tesla driver-assistance systems, BYD DiPilot, Boeing autonomous and uncrewed aircraft systems, Lockheed Martin/Sikorsky autonomous aircraft systems — are named illustratively only. This document does not state or imply that any named organization uses, endorses, requires or has evaluated this profile.

 

7. Patent-Pending Concept

Patent pending. The execution-finality architecture described here — including the Candidate Act / Protected Enforcement Domain / Execution Handle / Finality Sink construction, actuator-level withheld enablement conditions, envelope-bounded high-rate actuation authority, boundary-proximity revalidation, bounded offline authority, composite multi-actuator finality, and PED-originated compact act evidence with delayed key disclosure — is the subject of pending patent applications filed by the author, who is a solo independent inventor and self-funds this portfolio without institutional backing.

This publication is a technical disclosure. The text is released under CC BY 4.0; patent rights are expressly reserved and are not licensed by this publication or by any accompanying repository licence. Reference implementation code is published under its own terms with an explicit patent carve-out.

Licensing posture: should any part of this architecture be adopted into an IETF standard, the author's declared position is licensing on fair, reasonable and non-discriminatory terms consistent with BCP 79. The intent of publishing the specification, the mathematics, the record formats and runnable code openly is adoption and review, not enclosure — but the underlying invention is the work of one person without a legal team, and is protected accordingly.

A sample filing copy is attached to this record for disclosure and prior-art purposes.

 

8. Resources

• Sample filing copy — attached to this Zenodo record (see the upload section of this deposit)
• IETF standards process submission — draft-das-drip-uas-act-finality https://datatracker.ietf.org/doc/draft-das-drip-uas-act-finality/
• Runnable reference implementation — UAS / Autonomous Vehicle Execution Finality https://github.com/sangmdas/UAS-Autonomous-Vehicle-Execution-Finality
• Companion disclosure: The Internet Solved Communication. It Never Solved Authority — DOI 10.5281/zenodo.22082995
• Companion disclosure: Declared Purpose Is Not Authorization: Capability Laundering and Execution Finality at the AI Inference Boundary — DOI 10.5281/zenodo.22719527
• Companion Internet-Drafts: draft-das-execution-handle, draft-das-ef-registries, draft-das-composite-execution-finality, draft-das-actuation-bound-execution-finality

 

9. Invitation to Review

This is offered for technical review, including hostile review. The construction is deliberately falsifiable: the chain derivation and domain-separation strings, the 64-bit tag length, the interval-index wrap rule, the revalidation bound and its stopping model, the offline exposure bound, and the composite commit semantics are all stated concretely enough to be attacked. Corrections to any aviation, automotive or cryptographic assumption in this document are welcome and will be incorporated in later revisions; the author's understanding of any given deployment domain may contain inaccuracies.

The question this work exists to answer is one sentence long, and no deployed layer answers it yet:

When that rotor spun up, had anything with hardware-rooted authority actually said yes?

 

How to cite

Das, S. (2026). Remote ID Solved "Who Is Flying." It Never Solved "Who Allowed That.": Actuator-Level Execution Finality and 16-Octet Broadcast Act Evidence for UAS and Autonomous Vehicles. Zenodo.

Zenodo metadata — Upload type: Publication → Preprint · License: CC BY 4.0 · Keywords: DRIP, Remote ID, UAS, drone, execution finality, finality sink, Candidate Act, TESLA, delayed key disclosure, detect and avoid, autonomous vehicles, control authority handover, actuator security, RATS, COSE, patent pending