How Omniris keeps a tamper-evident record of every drone image and dataset that anyone can check for themselves, and lets you lock that evidence down for litigation, insurance claims and audits.
Drone imagery increasingly ends up as evidence: in an insurance claim, a construction dispute, a regulatory inspection or a lawsuit. When it does, the first question is rarely about the pixels. It is whether anyone can show where the files came from, who touched them, and that nothing was changed or quietly removed.
Omniris answers that question with five capabilities that work together:
Every action on every file is sealed into a record that is signed and timestamped by an independent authority. If anyone changes the history afterwards, it shows.
Signed PDF certificates that a court, insurer or auditor can check online, or entirely offline with free standard tools, without relying on Omniris.
Every day, each deployment re-checks its own custody record and alerts the people who run it if anything no longer matches what was sealed.
Freeze a file, folder, job, site, account or organization. Held evidence can't be changed or deleted, and a locked copy survives even a compromised account.
Keep data for a set period, then release or delete it, with a signed certificate proving what was deleted and when.
Most systems keep an activity log in their own database. That log is useful, but as evidence it has three weaknesses:
Omniris was built so that the custody record stands on its own: anyone can check it with keys that are published openly, its times are confirmed by independent timestamp services, and it is protected against deletion in several places at once.
Each file has its own chain of custody: the complete history of what happened to it. Omniris records uploads, views, downloads, shares (and each time a share is used), moves and renames, encryption and decryption, transfers between accounts, processing results (orthomosaics, 3D models, crops, panoramas, change-detection layers, exports), annotations, measurements, the AI detection results an image carried and each check or correction a person made to them, deletion and restoration. Each event records who acted, when, from where, and the file's fingerprints.
A fingerprint (technically, a SHA-256 hash) is a short code calculated from every byte of a file. Change a single byte and the fingerprint changes completely, so matching fingerprints prove two copies are identical. Omniris records up to three:
flowchart LR A[Something happens
to a file] --> B[Event sealed: public facts
+ hidden private details] B --> C[Each hour's events combined
into one fingerprint] C --> D[Anchor: that fingerprint
+ link to the previous anchor] D --> E[Signed with the
deployment's key] E --> F[Timestamped by an
independent authority] F --> G[Keys and anchors
published]
Every event is sealed into the custody ledger, a record that can only ever be added to. Every hour, or straight away when someone requests a certificate, the newly sealed events are combined into a single fingerprint using a Merkle tree: a standard structure that lets any one event later be proven part of the batch with a short chain of fingerprints. That fingerprint, together with one that captures the latest event of every chain of custody, forms an anchor. Each anchor:
What this means for you: every event can be proven to have existed by a given time, and no event can be altered, removed or reordered later without breaking a fingerprint that has already been signed and independently timestamped. Because the latest event of every chain is captured too, a certificate can show not only that its events are genuine but that none were left out.
A timestamp is only as durable as the authority's own certificate, which eventually expires. Before it does, Omniris renews the timestamps of every anchor affected in a single batch, so the proof stays valid over the long periods that litigation and records retention require.
A record that anyone can check must not reveal more than it should. Omniris splits each event into a public part (what happened, when, and the fingerprints) and private parts (who acted, the other people involved, file names and folders, network details, anything else). The ledger seals each private part without revealing it.
A custody certificate is a signed PDF that carries its own proof. It is digitally signed with the deployment's key, carries an independent timestamp, and is saved automatically in a Certificates folder in your vault. (A finding certificate requested through an API token or a shared link, which has no vault, is downloaded instead.)
| Certificate | What it shows |
|---|---|
| File | The file's complete custody history, its content and stored fingerprints, and who had custody. Views appear as counts, under stand-in names that differ on every certificate. |
| Folder manifest | Every file in a folder and its subfolders (up to 2,000), each with its latest proven event and fingerprints. Larger collections are certified folder by folder. |
| Network appendix | For the file's owner: the network details (IP address, app or browser) recorded with each of the file's events. |
| Disposition | For retention policies: each file deleted at the end of its retention, its last stored fingerprint, and the sealed record of its deletion. |
| Finding | A finding's complete sealed history, who did each step, the fingerprints of its evidence, and each evidence source file as it was when the evidence was attached. |
A finding is something on a site that needs attention, such as a damaged roof or a hot connector, tracked as a work item with its location, status, severity, assignee, comments and evidence images cut from the source imagery. Every change to a finding is sealed into its own chain of custody, just like a file's, and a finding certificate works like every other certificate: the same key, signature, independent timestamp, PDF, verify page and offline checker. It contains:
Who can request one:
A certificate requested through an API token or a shared link covers the history up to the most recent hourly anchor, and names people by display name only, never by email address or account. Erased details are never revealed: a comment its author deleted is shown as deleted, without its text, and the name of a person whose account was deleted is not revealed by any certificate issued afterwards.
What the offline checker prints for a file certificate that passes every check (example values). Each "ok" line is one independent check; any failure is printed as "FAIL" with the reason, and the result reads "NOT VERIFIED".
Encrypted files are handled openly. The certificate gives both fingerprints: the content fingerprint of the original file, and the stored fingerprint of the encrypted copy in the vault. The Evidence copy download gives you a file exactly as it is stored, with nothing added: the copy a certificate's fingerprint refers to (for an encrypted file, the encrypted copy).
A record that anyone can check only protects you if someone actually checks it. Omniris does not wait for an auditor or an opposing expert to look. Every deployment re-checks its own custody record every day, recalculating it from the stored records exactly as an outside checker would, and alerts the people who run that deployment if anything no longer matches what was sealed, signed and timestamped.
Every anchor's link to the one before it, its signature and its timestamp are checked. Everything recorded since the last check is recalculated in full: each new event, its hidden private details, its place in its chain of custody, and the anchors that seal it. It takes minutes.
The whole record is rebuilt from the beginning (every event, every fingerprint, every signature and every timestamp) without relying on any earlier result. A full rebuild also follows any check that finds a problem, and can be requested at any time.
Between them, the two checks catch:
Everything recorded since the previous day's check, and every anchor, signature and timestamp, is checked within 24 hours. A change to an older event is found by the next weekly rebuild, or sooner if a new event is added to that file's chain of custody.
These checks cover the custody record itself; they do not re-read every stored file. A file's contents are checked against its recorded fingerprint when someone checks the file against a certificate, and before a locked copy of it is made for a legal hold.
The checks run as their own scheduled job, separate from the application people use, on Omniris cloud, the data center edition and on-premises installations alike, so rebuilding tens of millions of events never slows anyone down. When the record was last checked, and how, is recorded, and a check can be run at any time.
The evidence never depends on this check. Every certificate carries its own signatures, proofs and independent timestamps, and anyone can check it without Omniris. What the daily check adds is timing: if the record is ever damaged or tampered with, the people responsible for it find out first, rather than a court, an insurer or an opposing expert.
A legal hold preserves evidence exactly as it is, for as long as it is needed. Account owners place holds on their own data, and organization managers on their organization's data. Releasing a hold requires the same authority that placed it, or higher.
| Hold on | Covers |
|---|---|
| File | That file. |
| Folder | Every file and subfolder in it, including anything added later or moved in. |
| Job | The job's folders and delivered results, plus its full operational record: mission plans, airspace (LAANC) authorizations, pre-flight checklists, flight logbook entries, tracked flights and their flight paths, messages, attachments and invoices. |
| Site | All imagery tagged with the site, including files tagged later. |
| Account or organization | Everything the account or organization owns: every file and folder in its vault, and every one of its jobs with the job's full operational record, including anything it gets later. |
While something is held it cannot be edited, replaced by a reprocessing run, moved into another account's vault, sent to the recycle bin or deleted, by anyone. Files that were already in the recycle bin when the hold was placed are restored. Moving files within the same vault stays allowed, and the hold follows them.
A hold never freezes another customer's data. If a held folder contains files that belong to someone else, they are listed as "not covered" rather than locked. When a client holds copies of results shared with them, those copies are protected as the client's own, so the original owner keeps control of their own files.
Holds are enforced in four independent places, so a gap in one is caught by the next:
Every operation that deletes, replaces or moves data checks for protection first and tells the user, before anything happens, what is protected and why. Deleting a folder that contains held files deletes everything else and keeps those files; if everything in it is protected, nothing is offered for deletion at all.
Every write, copy and delete in storage, and every upload link, passes through a guard that refuses to touch a protected file, whichever part of the system asks.
Rules inside the database itself refuse changes to protected records even if a request somehow bypasses the application. New items that fall within a hold join it automatically, at the moment they are created.
A copy of each held file goes into write-once storage (escrow), locked by the storage service itself. The lock can be extended but never shortened or removed, so the evidence survives even a compromised account or a rogue insider. For an encrypted file, its decryption key is also kept with the hold, itself encrypted under a separate recovery key.
Escrow copies are stored once per unique file and kept locked at least 90 days ahead for as long as the hold lasts; an outside monitoring service can watch their health. Every deployment creates its escrow storage write-once from the start, checks after every start-up that the storage service really enforces the lock, and alerts the people who run it if it does not. Escrow copies count toward the hold owner's storage, but a hold is never refused because of storage limits.
Before a file is copied into escrow, its bytes are checked against the fingerprint in its custody record, so the locked copy is provably the original. And because an upload link handed out shortly before a file became protected could in principle still be used afterwards, every newly protected file, whether held or retained, is checked once in storage after any such link has expired. If storage shows the file was written after it became protected, the people who run the deployment are alerted.
A retention policy keeps every file in a folder or site for a set period, counted from when each file came under the policy. When the period ends the files are either kept (they simply become deletable again) or deleted permanently, with a signed disposition certificate recording each file, its last stored fingerprint and the sealed record of its deletion.
Protection is visible where people work, and every refusal says exactly why, before anything happens, never as an error afterwards.
The same capabilities run wherever Omniris runs. What changes is where the signing key and the locked escrow copies live.
| Deployment | Signing key | Locked escrow | Proof published |
|---|---|---|---|
| Omniris cloud (Microsoft Azure) | Azure Key Vault; the key never leaves it | A separate storage account with a locked retention period on every stored version | In the deployment's public key and anchor lists |
| Omniris cloud (Google Cloud) | Cloud KMS; the key never leaves it | A dedicated storage bucket with a locked retention period on every copy | In the deployment's public key and anchor lists |
| Data center edition | The server's TPM security chip, or a protected key file | Write-once storage in compliance mode, with its own dedicated login | In the deployment's public key and anchor lists |
| On-premises | The server's TPM security chip, or a protected key file | Write-once storage in compliance mode, with its own dedicated login | Registered with Omniris |
Disconnected sites keep working. While an on-premises site can't reach a timestamp authority, its anchors are still made and wait in a queue. When the site reconnects, the next timestamped anchor proves that everything sealed before it existed by then. Registering the site's key with Omniris while it is connected lets its certificates prove that the key belongs to that site.
Evidence is only as good as the honesty of its claims. Every certificate states its limits in plain language, including:
Omniris provides verifiable records and the means to check them. Whether particular evidence is admissible, and what weight it carries, depends on the jurisdiction and the case. Your counsel should make that assessment.
Show adjusters and opposing experts that roof, crop or storm-damage imagery is unchanged since it was uploaded, and who handled it when, in a certificate they can check themselves.
Place a hold the day a dispute starts. Everything in scope, including files added later, is preserved, and the hold's record shows exactly what it covers.
Hold a job and its complete operational record together: mission plan, airspace authorization, pre-flight checklist, flight log and the delivered data.
Keep inspection imagery of utility, energy and transport assets for the period regulations require, then dispose of it with a signed certificate.
Prove that imagery of a site existed, unchanged, by a given date, with measurements and change-detection outputs that carry their own custody history.
Preserve incident imagery with encryption intact, while still being able to show that the stored evidence has not changed.
For technical reviewers: every proof uses published standards, so it can be checked with independent tools.
| Standard | Used for |
|---|---|
| RFC 3161 | Timestamps from independent public authorities |
| RFC 9162 | Merkle trees and inclusion proofs (as in Certificate Transparency) |
| RFC 4998 (approach) | Batch renewal of timestamps for long-term validity |
| RFC 8785 | Canonical JSON, so every party hashes the same bytes |
| ECDSA P-256 / SHA-256 (ES256) | Signatures on anchors and certificates |
| RFC 7638 | Key identifiers in the published key list |
| CAdES, PAdES | Signed and timestamped certificate files and PDFs |
| OpenTDF | Encryption of files at rest, with policy-based access |