The audit chain spec.

The audit chain is the set of records Plenoptary keeps to prove that a photo, thermal frame, or report PDF we handed you on a given date hasn't changed since. It's a database log surfaced as a "Provenance" view on each delivery in your portal. You can read it without us; a contractor or carrier you forward an asset to can recompute the hash and verify it without us too.

Three asset classes, all hashed at delivery: every photo we hand you, every thermal frame we hand you, every report PDF we generate. Reports also carry an Ed25519-signed metadata block — the same key your portal uses to verify station-to-cloud transport.

Every hash is recorded with the asset name, content type, delivery timestamp, source-capture lineage (so a derived finding traces back to its raw frame), and the staff member who delivered it. Rows are immutable: a later correction creates a new row alongside, never replaces the old one.

Open an asset in your portal. The provenance row next to it shows the SHA-256 hash recorded at delivery. Save the file to your device. Run `shasum -a 256 filename` on macOS or Linux, or `Get-FileHash filename` on Windows. Compare the string against the one in the portal.

If they match, the bytes you have are the bytes we delivered. If they don't, something's been changed; tell us, and we'll re-deliver from the original.

When you forward a report (or a photo, or a thermal frame) to a contractor or carrier, forward the hash too. The recipient runs the same shasum or Get-FileHash command and compares. The signature on the report PDF carries our public-key fingerprint; if the recipient wants to verify the signature directly, the public key is published on the trust page.

The point of the spec is that a third party never has to call Plenoptary to verify what they're looking at. They can. But they don't have to.

Three things. First: the bytes of a given asset haven't changed since the recorded delivery timestamp. Second: the report PDF was signed by Plenoptary's private key — which lives on the cloud server, not on a pilot's laptop. Third: every derived finding in the report traces back to a source capture whose own hash is in the chain.

It does not guarantee the report's interpretation. A flagged thermal anomaly might turn out to be a vent stack that's supposed to be warm. The chain proves we said what we said, when we said it, and that the bytes haven't moved — not that we were right.

If a finding is wrong, the dispute is editorial, not cryptographic. We'd rather hand you a finding you can argue with than a verdict you have to trust.

If you ask us to delete a delivery, we delete the originals and the derivatives. The audit row stays so the deletion itself is provable, but the imagery is gone: the row preserves the asset's hash, content type, delivery timestamp, and a "deleted at" entry; the asset itself is removed from cold storage and from the portal.

A later forensic question can answer "what was delivered, when, and who deleted it" without preserving the imagery itself.

Hashes and audit rows live in the same Postgres database that holds your account, scoped to your customer record with row-level isolation. Source assets are stored in S3 with a customer-keyed prefix; derivative assets (the report PDF, the cinema reel) sit alongside under the same prefix.

The audit log itself archives to cold storage on a daily schedule and can be re-verified against any archive manifest if a forensic question reaches that far back. Every archive manifest carries its own SHA-256 so the archive is its own chain.