Image Forensics
A vision model can describe what a picture shows. It cannot see whether the pixels were resaved, spliced, resampled or rendered rather than scanned, because those are signals below the image. Paddock can measure them and hand the findings to the model to reason about.
What Gets Measured
Around forty analyzers run over an attachment, grouped by what they look at:
| Family | What it looks for |
|---|---|
| Pixel | Compression-level differences, noise and sensor-pattern consistency, splices, resampling, JPEG ghosts. The evidence that an area of an image has a different history from its surroundings. |
| Metadata | What the file claims about itself, and whether those claims agree with each other and with the pixels. |
| Documents | Rendered against scanned: a PDF page that was generated looks different at the signal level from one that went through a scanner. |
| Generated imagery | Signals associated with synthetic images. |
The output is a set of findings with a risk score, plus overlays marking where on the image each finding sits.
It Answers To The Model, Not To You
The findings go into the model's context. The model, which can also see the picture, does the interpreting.
That division is the point. A forensic signal is evidence and not a verdict: heavy compression in one region is consistent with an edit and equally consistent with a screenshot of a screenshot, and a tool that returned "manipulated: true" would be wrong often and confidently. A model that can weigh a signal against what the image actually depicts, and against what you asked, is in a better position to say something useful, including that the evidence is inconclusive.
Original Bytes Only
Analysis runs on the bytes as they arrived, never on a re-encoded copy. This is not a preference: compression-level analysis, sensor-noise correlation and JPEG-ghost detection all measure artifacts of the file's own encoding history, and re-saving or resizing an image destroys exactly the evidence they read. A pipeline that normalised images first would produce clean, confident, meaningless results.
Off Until You Turn It On
Forensics is disabled by default. When the master switch is off the runtime is never built and there is no cost on the request path at all.
Enabling it is a two-step decision, deliberately. A server operator turns the capability on for an endpoint in its configuration, and then it applies per conversation rather than to everything that arrives. Running forty analyzers over every holiday photo somebody pastes into a chat would be a waste of a GPU and a surprise to the person who pasted it.
Where It Runs
Every analyzer has a GPU implementation and a CPU implementation of the same algorithm, and the two are held to agreement by a parity test rather than by assumption. The GPU path is used when a build has it and falls back to CPU on any error, so a forensics run degrades in speed rather than disappearing.
The forensic GPU work is deliberately kept off the inference path: it loads its own kernels through its own context rather than sharing the engine's, so analysis cannot disturb serving.
What It Deliberately Does Not Do
Several capabilities from the analyzer set this was ported from were left out, and the reasons are worth stating because their absence is a choice rather than a gap.
- A separate manipulation-detection neural network. It would mean another runtime dependency and a several-hundred-megabyte model, to add a second opinion to a local model that is already the judgment layer.
- A large dedicated forensic vision model. Roughly 27 GB of VRAM for a model working outside its domain, disabled even in the system it came from.
- Deepfake detection. There was no working capability to port.
- A bundled OCR engine. The model reading the document already does OCR.
What remains is signal extraction: the part a model genuinely cannot do for itself.