Evidence integrity

An auditor who intends to rely on Zindex provenance is entitled to ask how it is produced and protected. This page answers that question mechanism by mechanism. Nothing here is aspirational: each section describes what the platform does today, and where possible, how to verify it independently.

Immutable revisions

Scene history is append-only. Every change creates a new revision row; there is no API that mutates or deletes an existing revision’s content, and approvals are WHERE-guarded so a resolved proposal cannot be re-resolved. Automated retention is the one thing that removes old revisions, and legal hold exempts a scene from it entirely. Customer-initiated deletion still removes data - your right to delete outranks our retention - and exported packs remain valid and verifiable after the platform copies are gone.

Timestamps

Every revision, attestation, and approval carries a database timestamp stored as timestamptz - an absolute instant, not a wall-clock reading that shifts with a reader’s timezone. Timestamps are written by the server at event time; no API accepts a caller-supplied timestamp for any provenance field.

Identity

Approvals and attestations record the authenticated user who performed them. Both actions are human-session-only at the server: an API key (agent) calling the approve, attest, or unbind endpoints receives 403 SESSION_AUTH_REQUIRED, which is what makes “a named person did this on this date” a meaningful claim rather than a label an agent can self-apply.

Hash coverage

provenance.json in every evidence pack records the SHA-256 and byte size of each artifact (scene JSON, renders, changelog), and manifest.json hashes every file including provenance.json itself - the outermost integrity layer. Verify any of them with shasum -a 256 <file>.

Source lineage

Derive-created revisions record the schema snapshot’s dialect and SHA-256, computed by the API from the exact text it parsed - never accepted from the caller. This holds on the direct derive path and through derive-proposals on protected scenes. To corroborate a diagram against the environment, hash the schema snapshot from the period and compare it with the lineage.sourceSha256 in the pack.

Independent reproduction

An evidence pack is a pure function of the revision history, the parameters, and the generator version. Nothing in it reads a clock at export time, so re-requesting the same revision later reproduces byte-identical files - an auditor holding a pack can spot-check it by re-exporting and comparing hashes, or re-render scene.json through the public render endpoint and compare the output. Point-in-time exports (?asOf=) reproduce the same bytes as the equivalent revision-pinned export.

Encryption at rest

Scene content exists only as ciphertext in the database (AES-256, key held outside the database). This protects content confidentiality; it is independent of the integrity mechanisms above.

What this page does not claim

The mechanisms above establish that the evidence itself is controlled, reviewed, and historically reconstructable. They do not make a pack self-authenticating proof that the depicted architecture matches production - corroboration against the source environment is the auditor’s step, which lineage supports but does not replace - and they are not a substitute for the underlying change records an auditor samples when testing change-management controls.