Trust · a proposal, 17 October 2026, revised 22 October
Checking a figure against its data
A convincing image can now be made from nothing, and the metadata of any image can be changed in seconds. Signatures and detectors already exist for photographs. A scientific figure is something else: it is a claim about data. UDeep already declares how a figure's data became light, so it can do the one check that I could not find anyone else doing, which is to confirm that a figure follows from the data it claims to show.
Proposal. Nothing on this page is in the profile yet, and most of it is not built.
Principles
Nothing in the file is relied on for trust
- Anything attached to an image can be removed: metadata, signatures, identifiers. Removing proof only makes a file unverified. Nobody can add proof they do not hold.
- The original is verified, and copies point back to it. Sharing (screenshots, messaging apps, a journal's re-encoding) changes every byte, so a copy is never the evidence. It is a way back to the original.
- Forgery is made hard by a private key, not by something hidden in the pixels. Anything a writer can compute without a secret, a forger can compute too.
- Zero trust: every claim is checked when it is used, no single party is trusted (this project included), and keys are assumed to be stolen one day.
- Anyone can always look at a figure. Using it as evidence, in a journal's submission system, a lab pipeline or an archive, is what goes through verification.
- Existing standards are used wherever they exist. UDeep adds only what is missing.
What exists
Every part exists except one
| Who | Answers | Does not answer |
|---|---|---|
| C2PA (Content Credentials), JPEG Trust (ISO/IEC 21617-1:2025), cameras that sign at capture | Who made this file, and has it changed since? | Whether it shows real data |
| AI labelling (the EU AI Act's transparency rules apply from 2 August 2026) | Was this made by AI? | A fake made by a person |
| Journal screening (Proofig, ImageTwin) | Does this look duplicated or manipulated? | Proof: they flag for an editor |
| UDeep | Does this figure follow from this data, under its declared mapping? |
Why UDeep
No existing format does all of it
To be checked against its data, a figure has to do five things at once: open anywhere as an ordinary figure, say exactly how its data became light, say how precisely it holds the data, name the data it was made from, and be signed so that a change shows. Each format below does some of that. As far as I have found, none does all of it, which is why UDeep is a profile on top of existing formats and not a new image format of its own.
| Format | Opens anywhere | Declares data to light | States its precision | Names its data | Signed |
|---|---|---|---|---|---|
| Ordinary PNG or JPEG figure | yes | no | no (8 bits, unstated) | no | no |
| HDR photo formats (Ultra HDR JPEG, PQ AVIF) | yes | brightness only, with no data meaning | no | no | no |
| C2PA-signed image | yes | no | no | no | yes: who signed it, and that it is unchanged |
| PDF or SVG figure | yes | no | no | no | possible |
| Scientific data formats (FITS, HDF5, OME-TIFF) | specialist viewers | display settings, where kept, are not part of a standard figure | the data itself | it is the data | no |
| DICOM (medical) | medical viewers | yes, a window or lookup table | the data itself | it is the data | possible |
| UDeep | yes (gain-map JPEG, PNG) | yes, and invertible | yes, and checked | yes, by digest | C2PA, being tested |
DICOM comes closest: it declares how stored values are shown. But it stays inside medical viewers, has no place in a paper or a web page, and does not use the range of an HDR screen. The scientific data formats hold the data faithfully but not the figure; a reader of a paper never sees them. UDeep takes the parts that exist, the gain-map JPEG, the 16-bit PNG, XMP metadata and C2PA, and adds what none of them carries: the declared mapping, its precision and the link to the data.
How a figure is checked
Graded verdicts, never a green tick
Each level is reported on its own, as pass, fail or unverified. Anything not checked is unverified, never "fine". The report also names what was still trusted. A figure that is signed but does not reproduce from its own data is the most suspicious result there is.
| Level | Checked | Needs | Today |
|---|---|---|---|
| Declared | The file says how its data became light | the file | yes |
| Consistent | The declaration is complete and invertible; its stated precision is worked out again | the file | yes, udeep.validate |
| Plausible | The data behaves as its declared noise and instrument say it should: whole counts, the saturation level, the noise, the instrument's own artefacts | the data | no |
| Reproduced | The data is the one the file names; the pixels are the declared mapping of it; a data record reads back as its data | the file and the data | data records yes; whole figures not yet |
| Attributed | A signature over the file's bytes, a certificate naming the signer, a public log fixing the time | signature, log | no: a C2PA manifest is reported, not checked |
| Traced | The data was signed when it was measured, and each processing step signed its own record | signed data and steps | no |
From the measurement to a shared copy
The image carries a pointer; the proof lives in the record
The data as the instrument recorded it.
Sealed, with its digest, and timestamped.
The declaration as now (the mapping, the data digest, the SDR figure's digest), one new property saying where the provenance record is, and a C2PA signature over the file. A figure made for a light and for a dark page is two files with one declaration: the same data and the same data digests, each with its own SDR figure and its digest. Either is an original, and each is checked against the same data.
The original figure, its data, and every proof with the public keys needed to check it, archived with a DOI, so verifying never depends on a service still being online.
Stripped, re-encoded, screenshotted. They keep the picture and, often, its caption, which carries the identifier: enough to find the original, which is what gets checked. Without the caption, the picture's own content is the way back.
What this does not do
No watermarks, and no proof of truth
Invisible watermarks can be removed. A regeneration attack removed 93 to 99 % of the marks of one of the most resilient schemes (Zhao et al., NeurIPS 2024). A mark that any public detector can find can be studied and taken out (Miller, 2002). Marks also change pixels, which the profile forbids in a figure of record, so UDeep will not use them.
Cryptography shows where a file came from, not that it shows something real. Someone who fabricates data and signs it with their own key passes every signature check. What makes that hard is the physics of the data, independent witnesses and, in the end, another lab repeating the work.
For the long run
Checkable in a hundred years
A figure of record can be questioned long after every key, certificate, trust list and timestamp service of its day has gone, and after its signatures can be forged: a large quantum computer would break the kinds in use now. So nothing in a long-term check may depend on a live service, a trust list or a single algorithm. It rests on four things instead:
- Traceable, as a measurement is. An unbroken, documented chain from the figure to its data, to the paper, and through their records to the authors and institutions. Each link is a persistent identifier made to last (a DOI, an ORCID, a ROR), and each states how far it was checked.
- The digest in the paper. The data's digest, printed in the caption or the data statement, is kept by every library that keeps the paper. It covers both versions of a figure made for a light and a dark page, which share their data digests.
- Two hash families. SHA-256 and SHA3-256 of the same data. They are of unrelated designs, so the link holds if either is ever broken.
- Checkable from scratch. The profile, the reference code and its test vectors, deposited where they will last, so that a verifier can be written again without any of today's software.
A signature still says who made a file. To stay evidence after its key expires and its algorithm weakens, it needs an archive that keeps proof it was valid when made and renews that proof with stronger algorithms in time (the IETF's Evidence Record Syntax, RFC 4998). That is a duty lasting decades, for a repository or a national library rather than for this project.
The verifier
Open, run in the reader's browser, not trusted either
Given a file, a screenshot, a link or a DOI, a verifier finds the original, checks the chain and gives the graded verdicts as a page or as JSON for a journal's systems. The engine is open source so anyone can run it, and it can run in the reader's browser through UDeep's WebAssembly core, so the image never leaves their machine. Its report says what was checked and never calls anything fake.
Matches the original figure · signed with M. Newman's own key · reproduces from its data
data deposited 17 Oct 2026, 14:09 UTC
two checks unavailableAn example of the wording, not real output.
Where it stands
First experiment: C2PA signatures on UDeep files
On 17 October 2026 I signed two UDeep gain-map JPEGs and a 16-bit PNG with C2PA's own tool (c2patool 0.27.22) and its test certificate.
- Each signed file verified, and UDeep read it exactly as before signing. Google's libultrahdr decoded the signed JPEGs byte for byte the same as the unsigned ones.
- Changing one byte in the metadata, in the picture, or inside the hidden gain map was caught every time.
- With the signature stripped, the file read as unsigned, and the UDeep declaration and gain map survived.
- One problem: the tool inserts its data before the gain map but does not update the index (MPF) that says where the gain map is. Our reader and libultrahdr cope; a reader that trusts the index would look in the wrong place. The fix belongs in our own writer, which has to leave room for the signature before signing.
Decided on 22 October 2026. Signing is optional, and off unless asked for. It uses the author's own key (self-signed): no authority and no login is involved, and a viewer shows an unknown signer until a reader chooses to trust that key. The C2PA library becomes an optional part of UDeep's core, so the default build does not change. A figure's identifier goes in its caption and its metadata, never into the picture.
Next: signing from UDeep's own writer, declaring which pixels hold the data so whole figures can be reproduced, and checking supplied data against its declared noise.