Reading a verdict
The verdict is the public specification's, copied verbatim into the response. Learn it in the specification's words: a simplified version would surprise you later, in production, on the one file that mattered.
Three fields, not one boolean
There is no OK/KO field and no score, and you should not build one. A boolean reconstructed outside the platform discards not_evaluated first, which is precisely the information that stops a reader from over-reading a verdict.
| outcome | What the evidence adds up to. One of seven values, listed below. |
| labels | Sorted §8 statements about what is present, absent or wrong. Most labels are absences, not failures: a file with no timestamp is not a bad file, it is a file without certain time, and the label says so. |
| not_evaluated | Top-level keys in the proof this verifier did not understand — a newer producer wrote something this reader is too old to judge. It is neither evidence for nor against; it is the honest statement that something was skipped. Never drop it. |
The eight outcomes
| authentic | The proof is well formed, the signature covers these bytes, and the labels say how strong the surrounding evidence is. |
| verified_clip | A verified excerpt of a longer recording: the segment chain proves this piece belongs where it says, without claiming the whole is present. |
| frames_not_compared | A video whose signatures hold, and in which no segment could be located in the file, or none was recomputed. Neither a clip nor tampered: nothing ties these frames to the proof. Send a video with recompute_segments: true to have them compared. |
| tampered | Evidence against the file: the bytes do not match what was signed, or the pixels contradict the signed core. |
| nested_proof | A proof inside a proof — a sealed file sealed again. Not judged as authentic; unwrap it first. |
| corrupted_proof | A proof structure that is there and broken (a bad checksum, a truncated payload). Different from a forged one, and different from none. |
| no_proof_found | Nothing to read. A plain photo answers this, and so does a sealed photo whose proof was stripped by a re-encode. It is an answer, not an error. |
| unsupported_format_version | A major version this verifier cannot read. Refusing to judge is the correct behaviour. |
Labels are the part that carries the meaning
authentic alone says the signature checks out. How much that is worth is in the labels. §7 and §8 of the public specification are the authority, and they are the only authority: the set is about forty strings today, it grows by addition, and a list copied into this page would be a shorter list than the one your code will meet — which is a worse answer than no list, because it reads as complete. Treat a label you do not recognise as a label, not an error, and look it up in the specification.
Two are worth calling out here because integrators misread them in opposite directions. revocation not checked means nobody could ask the transparency log whether the key has since been revoked — a proof cannot carry the absence of a later revocation, so an offline verifier stops there by design. And origin not hardware-attested means the capture did not prove it came from a secure element; it does not mean the file was altered.
A third reads as an accusation and is not one. integrity not proven means the key's hardware was proven but nobody proved the device around it intact: green requires Google Play Integrity's hardware-backed verdict, relayed and signed by the registry, and anything less holds the verdict at amber. Apple's App Attest says nothing about a jailbroken iPhone, so every iOS capture reads this way in the current version of the specification. It is a missing proof, not a failed check; a failed check is integrity failed. On Android it is also what every capture reads while the app has no Play Integrity keys: each app's pair comes from its own Play Console (App integrity → Response encryption, managed by you) and goes on the app's page under Apps, where the verification key is published to the transparency log before it is used.
A missing field is a weaker verdict, never an error
No timestamp means "no certain time", and the verdict says so. No attestation means "origin not hardware-attested". No watermark evidence means "watermark not evaluated". If you find yourself writing error-handling code for an absence, the absence was the answer.
Trusted time is RFC 3161, and it is not qualified
A proof may carry an RFC 3161 token, and this API validates it against configured roots — that is what trusted time means in a verdict, and it is worth exactly what the authority that issued it is worth. No qualified trust service provider is behind it, and no eIDAS claim is made anywhere in a verdict, a report or this portal: there is no qualified certificate here to make one with. Do not present a timestamped capture as carrying a qualified electronic time stamp, because it does not.
Green is green against a named trust set
The response carries trust next to the verdict: which transparency logs were accepted, how many timestamp roots were configured, whether the chain was consulted. A verdict without that set is not comparable with one from somewhere else, so it travels with the verdict rather than being implied by it. Where evidence proves a hardware level, level carries three values — claimed, proven and the ceiling the evidence allows — and the claimed level is never the answer.