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 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 record
- geofence_zones
- HOA / school / hospital / federal-property exclusions
The record 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 verifies, and what it doesn't
What this verifies
- ✓ GeoClear issued this operational evidence record 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 record later without contacting GeoClear servers.
What this does not verify
- × 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 evidence record are retained as part of the dispatch record.
- The post-flight pipeline packages the operational evidence record + 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.
Related: Autonomous Logistics solution overview · MCP protocol reference · Record Vault docs · Customer-held verification.