EXIF source metadata is not the same as capture evidence

A gallery photo can arrive with a shooting-time tag, GPS information, orientation, and pixel dimensions already in the file. AuditIt calls the privacy-filtered subset it reads before normalization source metadata. That file context is different from capture facts recorded for a live camera photo and from import facts recorded when an existing file is added. Keeping those labels attached prevents three different events from being collapsed into one.

This guide is for someone reviewing a mixed photo record — a boom lift going out, a van coming back, or a one-visit damage note. It explains how to read the available file context without treating it as an authenticity certificate or privacy-law advice.

If you only need the three clocks — live capture time, import time, and file metadata — start with capture facts vs import facts. The narrower job here is which Exif field classes can become that file metadata, and which current AuditIt processing discards.

Four EXIF field classes worth separating

The Camera & Imaging Products Association's December 2023 Exif 3.0 overview describes metadata as additional data attached to image data, separate from the image itself. Shooting date and time is one of its examples. That explains what a file can carry. It does not mean every value is present or true.

For a condition record, four classes cover the useful review questions:

1. Shooting time, with a usable UTC offset. Exif 2.31 enabled a description of time difference with UTC. Current AuditIt processing keeps a shooting-time string only when the date-time pattern and a parseable offset both succeed. A time without that offset is discarded.
2. GPS Info as a pair. Exif 2.0 added a GPS Info field that can record location. Current processing treats latitude and longitude as one fact and discards both if either half is missing or incoherent. An optional GPS accuracy number is kept only when it is finite and not negative.
3. Orientation and decoded pixel size. These can be stored when present. Pixel width and height come from the decoded image, not from a claim that the file is authentic.
4. Fields outside AuditIt's current set. Camera serial numbers, owner names, Exif 3.0 annotation boxes, original-preservation images, and uniqueness IDs are not fields in the current source-metadata object. CIPA describes some of those as expected to contribute to authenticity work. AuditIt does not import them as capture evidence.

A file that fails a basic type check — magic bytes that do not match the declared type, or a decode that fails — contributes no source metadata at all. That is a read failure, not a finding that the photograph is fake.

Source metadata, capture facts, and import facts answer different questions

Source metadata carries the file's own surviving context. It may include a shooting time or GPS pair, but AuditIt treats every value as best-effort rather than proof that the fact is true.

Capture facts answer a different question: when AuditIt recorded a live camera capture, including the app-recorded time and, when enabled, a device location fix. Public copy reserves “Exif dump” as a term to avoid for that live clock.

Import facts answer when and how an existing gallery file entered the record. They never masquerade as the source file's capture time or location.

So a Monday shooting time still sitting in a file imported on Wednesday remains source metadata. Wednesday's import time documents the add-to-record action. Neither is a live Wednesday capture unless a live photo was actually taken in the app.

Gallery imports never use the phone location. If organization location policy is on and the file still has a complete coordinate pair plus a location-fix time, those coordinates can be stored as source metadata and labeled approximate. They are not the phone's GPS at import time, and they are not a live device fix. For the separate question of how to read a reported radius or precision class, see location accuracy in condition records.

A source-metadata time that sits after the import time is rejected in the current mobile factory. That is a consistency check. It does not prove that an earlier remaining time is the true shutter instant.

A practical review: one live photo and one gallery import

A fictional telehandler returns with a cracked work light. The record has one live AuditIt photo and one gallery import. The gallery file still shows 14:02 and coordinates near a yard gate.

A careful review keeps the mechanics separate from the conclusion:

1. Confirm the second photo is a gallery import, not a live capture.
2. Read 14:02 as source metadata only if a usable UTC offset survived the filter. If the offset was missing, do not invent a shooting time.
3. Read the coordinates as a GPS Info pair from the file, labeled approximate if they were stored, not as today's phone location.
4. Use the photographs, notes, and history to assess the work light.

The tags can help reconstruct how the record was assembled. They cannot decide when the light cracked, why it cracked, or who is responsible.

What AuditIt adds to the review

AuditIt can keep a privacy-filtered subset of file tags — time, location, orientation, and size — labeled as source metadata on a gallery import, while live capture facts stay on live photos. That helps a reviewer see what was submitted. It does not turn an Exif tag into a live clock or an authenticity certificate.

AuditIt creates tamper-evident, human-review-ready records. It is not legal certification and does not determine liability.

To start a structured condition record, create an AuditIt account.

• EXIF
• source metadata
• capture facts
• gallery import
• condition records