Evidence you can prove

Evidence you can prove

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.

Summary

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:

Why an audit log is not enough

Most systems keep an activity log in their own database. That log is useful, but as evidence it has three weaknesses:

• You have to trust whoever runs the database. A log row can be edited or deleted by anyone with enough access, and nothing outside the system would notice.
• It proves nothing about time. A timestamp written by the same server that wrote the event is only as reliable as that server's clock and its operators.
• Deletion is an ordinary operation. Files can be removed, replaced by a "corrected" version, or lost when an account is closed, often by automated clean-up rather than by any decision.

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.

A tamper-evident custody record

What is recorded

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:

• the content fingerprint of the file exactly as uploaded;
• the stored fingerprint of the bytes actually kept, which differs once a file is encrypted;
• the delivered fingerprint of a download that had location metadata written into it.

How sealing works

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:

• includes the fingerprint of the anchor before it, so the anchors form one unbroken chain;
• is digitally signed with the deployment's own key: anyone can check the signature with the published public key, but only the deployment can make it;
• is timestamped by an independent public timestamp authority (DigiCert, with Sectigo as a fallback), which certifies that the anchor existed at that time.

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.

Private by design

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 certificate reveals only what its reader needs: who had custody, not the name of every viewer.
• Some private details can be erased later without breaking the record: a person's name in a finding's history or on an AI-result check when their account is deleted, and a comment its author deletes. Nothing is erased while a legal hold covers it.
• Network details such as IP addresses never appear in an ordinary certificate. They go only into a separate network appendix, which the file's owner can request.

Certificates anyone can verify

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.)

Finding certificates

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:

• Every sealed step of the finding's history up to one signed anchor, with proof that no step was left out. Changes made after that anchor are not covered, and the certificate says so.
• Who did each step: a person by name, an automatic analysis and the person who started it, an API token and the person who created it, the system itself (with its reason, for example a folder move), or a shared link.
• The fingerprints of its evidence images, as sealed when each image was made.
• Each evidence source file as it was when the evidence was attached, never its current state. Each is backed by that file's own sealed events, which disclose no names or file names.
• The finding itself (status, severity, category, assignee, location, evidence, comments), rebuilt from the sealed events alone, so anyone holding the certificate can recompute it.

Who can request one:

• A signed-in person who can see the finding and open every folder its evidence comes from, since the certificate discloses all of it. The history is anchored at the moment of the request, so it covers every step up to then.
• An API token (a key for connecting other software) of the organization or vault the finding belongs to, when all of its evidence comes from inside that organization or vault.
• A visitor using a shared link that includes findings, when the finding and all of its evidence are inside what the link shares.

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.

Three ways to check one

1. Online. Every certificate carries a verify link. The page shows whether the certificate is valid, when it was timestamped, and that its anchors match the ones the deployment published. For a file certificate you can also pick the file on your own computer: its fingerprint is calculated in your browser and compared, and the file is never uploaded. For a finding certificate the page shows counts only (steps in the history, evidence fingerprints, evidence source files), never the finding's reference, title, the people involved or its evidence. The page shows no names, file names or personal data.
2. Offline. Everything needed is attached to the PDF: the certificate data, its signature, the signing key, the timestamp authority's root certificate and a small checker program. The checker runs on any computer with Python 3 and OpenSSL, both free; no account, internet connection or Omniris app is needed. For a finding certificate it also proves that no step of the history was left out, and checks every evidence source file and evidence fingerprint against the sealed events. Given a file, it says which evidence image or source file it matches.
3. By hand. The certificate's last page gives the OpenSSL command that checks its signature, and the checker prints the exact OpenSSL command it uses to check the timestamp, so an independent expert can repeat both without relying on Omniris's checker.

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).

Daily self-checks

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.

Between them, the two checks catch:

• an event that was edited, removed or reordered after it was sealed, even by someone with direct access to the database;
• an anchor that was altered or deleted, or no longer links to the one before it;
• a signature or timestamp that no longer checks out;
• damage to the stored record, or a restore from a backup that does not match what was sealed;
• a fault in the software that seals new events, within a day of the first event it affects.

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.

Legal holds

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.

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.

Four layers of protection

Holds are enforced in four independent places, so a gap in one is caught by the next:

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.

Retention policies

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.

• Overlaps are explicit. If a new policy covers files another policy already covers, the user sees each overlapping policy and the outcome before saving. A file is deleted only when every policy covering it has ended and all of them say delete.
• Holds always win. A file under a legal hold is never deleted by a retention policy.
• Locking is permanent. A locked policy can never be removed, its period can only be extended, and "delete" can only change to "keep".
• Nobody is surprised. The policy's creator and the data's owners are warned 90, 30 and 7 days before files reach the end of their retention.
• Changes give notice too. Shortening a policy that deletes, or switching a policy from keep to delete, first shows how many files would become due and asks for confirmation. Nothing is deleted sooner than seven days after the change, so the final warning always goes out first.
• Retained files can't be deleted early or moved out of the policy's folder.

What users see

Protection is visible where people work, and every refusal says exactly why, before anything happens, never as an error afterwards.

• A trusted-timestamp stamp on every file. Once a file's custody history is timestamped, a green stamp follows its name in the file's detail view; hovering names the timestamp authority and the time. The top of the file's Chain of Custody panel says the same in words ("Trusted timestamp — DigiCert, <time>") and explains what it proves. Until the next hourly anchor it says the history is sealed and that the timestamp is coming. Everyone who can see the file sees this.
• Icons after every name. In the file browser, the Browse panel's folder list and breadcrumb, search results and Favorites, the Move / Copy folder picker, the Recycle Bin and a file's title, a red gavel marks a legal hold and an amber hourglass a retention policy, with a small lock when the policy is locked. Both appear when both apply. Hovering shows which hold or policy it is, where it was set and, for a file, the date it is kept until. On a folder, a dimmer icon means the protection comes from above it (a parent folder, its job or its site).
• Names only for those allowed to see them. The holds a viewer may see are named. Others see only that something is on "a legal hold you can't view".
• Deleting. A protected item is never put behind an "are you sure?". The user is told straight away what protects it: the policy, how long it keeps files and what happens then, where it is set, and the date the file is kept until, or the legal hold. If nothing in the selection can be deleted, the only choice is OK. If some of it can, "Delete the other N" removes the rest and keeps the protected items with the folders that hold them.
• Moving. After the destination is picked and before anything moves, the user is told which items the rules keep out of it and why, and where they can go: any folder inside the retention policy's folder, or anywhere in the same vault for held items.
• Everything else that would change protected evidence (deleting a held job or any of its records, reprocessing over protected results, rewriting a protected file, replacing it with an upload, emptying the Recycle Bin, deleting an account or organization whose data is protected) is refused up front with the same detail, instead of failing after a confirmation.
• Reprocessing. Re-running a stitch or 3D model over protected results offers only to keep the old results and put the new ones in a fresh folder. Re-running a panorama or LiDAR job over protected results is refused before it starts, and replacing a protected export isn't offered; each time, the user sees what protects the results.
• Transferring a folder to another account leaves protected files with the sender. Both sides are told beforehand, with the holds and policies involved as far as each may see them, and must confirm.
• A new delivery on a held job arrives alongside the held one instead of replacing it.
• Accounts. An account whose own data is held, or under a retention policy, cannot be deleted. When someone who only took part in a held job leaves (a pilot, for example), their messages and flight records for that job are kept without their account details. A held organization job doesn't stop the account that created it from being deleted: the job passes to the organization's owner, and the change is recorded in the organization's activity log.

Cloud, data center and on-premises

The same capabilities run wherever Omniris runs. What changes is where the signing key and the locked escrow copies live.

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.

What the record claims, and what it doesn't

Evidence is only as good as the honesty of its claims. Every certificate states its limits in plain language, including:

• Views are recorded on a best-effort basis and merged per person, per file, per 10 minutes. They appear as counts.
• Events recorded before a deployment's ledger was set up were sealed when it was. Their times are the times recorded then, and the certificate says they were not proven by a timestamp authority.
• On an on-premises installation, legal holds bind the application, not the operating system: the server's all-powerful "root" user is outside them. On-premises certificates also say that the times of events during an offline period rest on the local clock (recorded as synchronized or not), and that they cannot prove the operator did not rewrite history recorded while offline.
• The signing certificate is issued by the deployment itself. It is trusted through the published key list and the independent timestamps, not through a public certificate authority.
• The ledger's running event numbers reveal how many events a deployment recorded between anchors.

Where it matters

Standards

For technical reviewers: every proof uses published standards, so it can be checked with independent tools.

Glossary

Anchor

A signed, timestamped record that seals a batch of events and the latest event of every chain of custody, linked to the anchor before it.

Chain of custody

The complete history of who did what with a file, from upload onwards.

Content / stored fingerprint

The fingerprint of a file as uploaded, and of the bytes as kept in the vault. They differ once a file is encrypted.

Digital signature

A mark made with a private key that anyone can check with the matching public key. It proves who signed and that nothing changed afterwards.

Escrow

A write-once copy of held evidence, locked by the storage service so that nobody can change, delete or shorten the lock on it.

Fingerprint (hash)

A short code (SHA-256) calculated from every byte of a file. Any change to the file gives a completely different fingerprint.

Legal hold

A protection that keeps everything in its scope from being changed or deleted until it is released.

Merkle tree

A standard way of combining many fingerprints into one, so that any single item can later be proven part of the batch with a short chain of fingerprints.

Retention policy

A rule that keeps files for a set period and then keeps or deletes them.

Self-check

The deployment's own check of its custody record: a check of everything new every day and a full rebuild every week, run separately from the application, with an alert to the people who run it on any mismatch.

Timestamp authority

An independent service that signs a statement that a given fingerprint existed at a given time.