Standard
The record standard names the metadata that must travel with a drone picture if a later viewer is going to trust the location.
The private ledger that will store these seals is still being built. Until that service is open, the fields below are the contract the demonstration registry already uses. A matching digest means the listed fields were not edited after sealing. It does not, by itself, prove the aircraft was airborne.
Sealed fields
| Field | Source | Sealed |
|---|---|---|
| Latitude and longitude | GNSS receiver on the aircraft | Capture |
| Altitude | Barometer, cross-checked with GNSS | Capture |
| Timestamp | Aircraft clock, compared with GNSS time | Capture |
| Platform | Drone model and flight identity | Capture |
| Sensor | Camera or payload that wrote the frame | Capture |
| Place label | Operator description of the site | Registration |
| Content digest | SHA-256 of the canonical metadata JSON | Registration |
Anti-spoofing check
Coordinates are only useful if they came from the aircraft that captured the frame. The check compares the submitted fix with the other readings from that pass, including altitude and the geometry of the picture. The Tehachapi sample is held as rejected because the submitted fix does not agree with the horizon. The Denver sample stays in review until a second GNSS observation arrives.
Private ledger
Seals are intended for a private ledger operated for the organisation that owns the imagery. That keeps flight context out of a public chain and avoids gas fees that move with a public network. Picture bytes can remain in the operator's own store. The ledger records the metadata digest and the review status.
You can compute a digest locally on the registry page. The result stays in the browser.