Divine Inquisitor checks C2PA content credentials so you can see whether a file carries real provenance, who signed it, and what the verification run actually found. No pitch-deck fog. No slop-friendly shrugging.
Inquisitor reads C2PA content credentials and turns them into something you can use: a verdict, signer data, validation results, captured metadata, ingredient references, and a timestamped response you can pipe into your own systems.
This page is story first, lab second, docs third on purpose. People should understand why provenance matters before we throw them into a wall of fields. Builders still get the full contract below. We are not hiding the sharp edges. We are just introducing them like adults.
The live lab uses the same route your app would hit. The result view stays balanced on purpose: clear verdict up top, the important provenance and validation panels already open, and the deeper forensic trail a click away.
Upload bytes or point the service at a public asset URL. Both paths hit the same verifier. The result surface stays readable first and honest second.
Binary mode sends `application/octet-stream` and sets `X-Mime-Type` from the selected file or extension guess.
The verifier is running. If this is URL mode, the service is fetching up to its configured range window before inspection.
You will get a human-readable verdict first, then open provenance and validation panels, then the deeper sections like assertions, ingredients, content hash, and raw JSON.
Use the public service in one of two ways: send raw bytes, or send a JSON body with a URL. The same response schema comes back either way.
Use this when you already have the file in-hand and want direct verification without any remote fetch step.
Use this when the asset is already published and the service can fetch it. You can supply `mime_type` when URL inference is not enough.
This is the working contract on the page, not a teaser. Builders should be able to wire the service up from here without opening another tab.
Returns a small JSON payload with service name, status, version, and optional git SHA. Good for service checks and quick diagnostics.
Returns Prometheus-formatted metrics from the running process, including verification request counters.
`VerifyResponse` keeps the top-level answer simple and the deeper data explicit. These are the fields the live lab is rendering.
The high-level outcome. `validation_state` reflects the verifier state directly, while `valid` answers the blunt question fast.
Human-friendly identity and claim generator hints from the active manifest.
Heuristic flag for ProofMode-generated content based on claim generator text or assertion labels.
EXIF-derived capture details when the manifest exposes them.
Issuer, serial number, signing time, algorithm, and revocation status when signature metadata is available.
The manifest trail: action labels, raw assertion labels, and ingredient references from the active manifest.
Counts for passed and failed checks plus failure codes when validation details are available.
The SHA-256 hash the service computed and the timestamp for when verification was performed.
Transport, parsing, or verification error message when the run does not produce a normal inspection result.
These are the defaults the current service starts with. If you rely on them in automation, keep your deployment env vars in sync with what you document.