Method and limits

ChronoVerify answers one question: when and where was a photo captured, and does it show signs of editing. It returns one plain-language verdict, a 0 to 100 evidence-strength number, and the per-signal breakdown that produced it. It is provenance-first and works on any photo, signed or not. It is not a deepfake-only detector.

Two layers, kept separate. Every report has an integrity substrate (the file hash, the method version, the processing time) that is uncontested and reproducible, and a probabilistic verdict built from provenance, metadata, and pixel signals. The strong cryptographic facts are never used to imply the verdict itself is proven.

The verdicts

Provenance confirmed: valid Content Credentials (C2PA) are attached and validated.
Consistent: metadata is present and internally consistent, and no manipulation signals fired. This is not proof of authenticity.
Inconclusive: the image carries little or no provenance (common for screenshots and platform-stripped photos). The default when evidence is weak.
Metadata anomaly: the metadata contains an internal contradiction worth review.
Manipulation indicated: at least two independent signals are jointly consistent with editing. A triage flag for human review, never a determination.

By design the verdict biases toward inconclusive, and no single pixel signal can produce a manipulation verdict. At least two independent signals must agree.

The signals (method cards)

Content Credentials (C2PA)

For signed images, provenance is read from the embedded C2PA manifest and, where the validator is enabled, checked against the official Trust List. This is the strongest available authenticity signal.

Failure modes: most images in the wild are unsigned, so this fires rarely. Manifests are routinely stripped by social platforms, screenshots, and re-saves. A valid manifest proves what the signer asserted, not that the depicted scene is true. Absence of a credential is not evidence of anything.

EXIF / XMP internal consistency

We extract embedded metadata (capture time, device, GPS, software) and check whether its parts agree with each other. A real internal contradiction (for example a last-saved time earlier than the capture time) is flagged.

Failure modes: timestamps and GPS can be edited, so we report internal consistency only, never the truth of an embedded value. A later save time or an editor software tag is reported neutrally: re-saving and normal editing are common and are not evidence that content changed.

Error Level Analysis (localized)

The image is re-saved at a known quality and compared to itself. We look for a local region whose re-save error is far above the rest of the frame, which can indicate a region with a different compression history.

Failure modes: ELA is contested and unreliable on its own. It mislabels altered and authentic images in both directions, is meaningful mainly on JPEGs, and degrades on recompressed, resized, or screenshotted images. Used only as one corroborating signal and down-weighted accordingly.

Noise dispersion

A natural photo has fairly consistent sensor-noise texture. We measure how much local high-frequency energy varies across the frame; strongly inconsistent regions can corroborate a spliced area.

Failure modes: probabilistic and noisy on heavily compressed or low-texture images. Corroborating only; never decisive alone.

JPEG quality estimate

Estimated last-saved quality from the quantization tables, reported for context.

Reported neutrally. A low quality or evidence of re-saving is normal and is not evidence of content change.

Limits of use

ChronoVerify returns investigative triage and risk scoring. It is not courtroom proof and should never be a sole basis for an automated decision such as rejecting a claim, a listing, or an account. Route flagged results to human review.

Pixel forensics is probabilistic and degrades on recompressed, resized, screenshotted, or platform-stripped images. Absence of a signal is not proof of authenticity.
A "consistent" or clean result confirms provenance integrity, not that the scene depicted is true. Many edits leave no detectable trace.
The report authenticates the exact file we hashed. It does not establish where a photo came from, who took it, or how it was obtained: that foundation is a human's job.
For any contested or high-stakes use, a qualified examiner must interpret the signals and provide testimony. ChronoVerify supplies the reproducible, hashed substrate; the expert supplies the opinion.

What we have done, and what we have not

We state status as fact, not aspiration. As of this build: a deterministic verification pipeline and a signed-PDF report (Ed25519 over the canonical verdict, with an optional RFC 3161 trusted timestamp) are working. A synthetic regression benchmark is in place: on a synthetic corpus the tool currently shows a 0% false-positive rate on authentic and normally re-saved images, flags every synthetic splice, and returns "inconclusive" only on provenance-stripped images. Those are synthetic numbers, useful for calibration, and they are not a real-world result.

Not done yet: cryptographic C2PA validation is detection-only unless the validator is enabled in the deployment; a real-world, third-party-reproducible benchmark is still pending, and no comparative claim against any competitor is made before a shared-input test exists; SOC 2 Type II and ISO 27001 are not held; a self-hosted deployment is planned.

API

One endpoint. Send an image, get the verdict object. This works right now, no key required during the free preview.

curl -X POST https://chronoverify.com/v1/verify \
  -F "file=@photo.jpg"

You can also point it at an image already online:

curl -X POST https://chronoverify.com/v1/verify \
  -F "url=https://example.com/photo.jpg"

The response includes verdict, confidence, headline, summary, capture_time, capture_location, capture_device, a c2pa block, metadata_consistency, pixel_forensics, an auditable signals array, the integrity substrate (hashes, method version, UTC time), and a plain limits note. The same schema renders the public verifier, so what you see in the browser is exactly what the API returns.