Drone Delivery Audit | Sample Evidence Bundle

The location verdict + receipt your dispatch system retains so a regulator, investigator, merchant, or internal reviewer can verify years later exactly what your autonomous routing decided at flight time.

Why drone-delivery teams care

Every autonomous landing is a decision the dispatch system made on behalf of the operator. Most of the time the package lands fine and nobody asks. The handful of times something goes wrong, a property-damage claim, a regulator inquiry, a chargeback from the merchant, the question is the same: what did the dispatch system know about that location at the moment it decided to fly there?

A log entry is not enough. Logs rotate, vendors migrate, dashboards disappear. An Evidence Bundle is the post-flight artifact that survives all of that, a tamper-evident, customer-held record of the location verdict that authorized the flight, packaged so a regulator, investigator, merchant, or internal reviewer can verify it years later in a browser.

Field shape

The featured bundle's signed verdict carries the location-substrate fields. For a drone-dispatch deployment, the bundle would also carry a vertical-tuned overlay (airspace classification, landing-zone confidence, deliverability boolean) sourced from the drone_deliverability tool path on /agent-protocol:

full_address: USPS-canonical address that authorized the landing
lat / lon: Rooftop-precision coordinates of the landing zone
airspace_class: FAA Class B / C / D / E / G (when overlay applied)
airspace_restrictions: Active NOTAMs, TFRs, prohibited zones at flight time
landing_zone_confidence: 0-1 confidence the address has a viable landing surface
drone_deliverable: Boolean dispatch decision
weather_at_decision_time: Weather snapshot at the timestamp on the receipt
geofence_zones: HOA / school / hospital / federal-property exclusions

The receipt is bound to these fields at decision time. Change a coordinate, flip an airspace class, alter a deliverability boolean, and the verification fails.

What this bundle is

The AZ-0001 sample is a customer-held evidence package. The address is a real arid-zone parcel in Yavapai County, Arizona, the kind of geography where autonomous logistics actually flies (Wing in Phoenix metro, Zipline in healthcare corridors). The result was emitted from the live /api/demo endpoint. The bundle verifies independently using retained verification material, no GeoClear server is required for the verification result.

Open the browser verifier. Drag the bundle in. Watch the verification turn green. The drone-overlay fields above are conceptual for v1 of this gallery; the verification substrate is real and verifiable today.

What this proves, and what it doesn't

What this proves

✓ GeoClear issued this receipt at the timestamp inside it.
✓ The recorded payload has not been mutated since issuance.
✓ The verification material traces to a stable, customer-verifiable trust anchor.
✓ The customer can re-verify the receipt later without contacting GeoClear servers.

What this does not prove

× That FAA airspace classification was current to-the-minute.
× That the landing was physically safe.
× That the dispatch decision was the right one.
× That the package arrived intact.

How a drone-ops team typically uses this

At dispatch decision time, the autonomous-logistics platform calls GeoClear (or its own MCP-tool wrapper of GeoClear) to verify the destination + retrieve airspace context.
The response + operational receipt are retained as part of the dispatch record.
The post-flight pipeline packages the operational receipt + retained evidence + verification material into a customer-held evidence bundle, indexed by flight ID.
The bundle lives in the operations-record store alongside the flight log + telemetry. If a post-incident review, regulator, investigator, internal QC, or merchant chargeback, asks what location result authorized the flight, the bundle answers later, independently.

Drone delivery: the post-flight artifact your dispatch system retains.