Every mobile operation collects photos. Very few can answer the question a fleet customer actually asks, which is never "do you have a photo?" It is "prove this photo is of my vehicle, on that date, at that job, and that nobody has touched it since."
Those are different problems, and most job systems solve only the first. This page sets out the disputes that actually arise, what evidence resolves each, and where the usual approach quietly fails. We build software for this, so treat the last section as interested — but the six disputes below come from how this work is invoiced, not from a product roadmap.
Why a photo gallery is weaker evidence than it feels
Three specific weaknesses, worth understanding before deciding what to capture.
Metadata inside a photo is not proof
EXIF timestamps and GPS coordinates live in the file and can be edited with free tools. They are useful as a working record and worthless as proof of anything contested. If your position rests on "the photo says 14:07", you have no position — the other side can point out in one sentence that the field is writable.
A photo proves a photo exists, not what it belongs to
The link between an image and a job is usually the weakest part of the chain. A photo in a WhatsApp thread, or in a phone gallery, or dropped into a shared drive folder, is associated with a job by a filename, a folder or somebody's memory. Any of those can be wrong, and all of them can be changed after the fact without leaving a mark. The association has to be made at capture, by the system, and be as hard to alter as the image itself.
Tamper-evidence and truthfulness are different claims
Hashing each file and chaining it to the previous one — which is what we do, and what several serious systems do — proves the set has not been altered or reordered since capture. It does not prove the photo shows what you say it shows. Anyone selling you the first as if it were the second is overselling. What tamper-evidence buys you is that the argument moves off "did you edit these?" and onto the substance, which is where you want it.
The six disputes, and what closes each one
What to capture, as a standing rule
Assembled from the disputes above rather than from what is easy to collect:
- Before you start: vehicle registration and fleet number; the condition of each wheel and its surrounding bodywork; the odometer if the contract prices on distance.
- Per wheel position: tread depth before removal; the removed tyre showing its wear; the reason for removal as a coded value; the new tyre's DOT or serial; the torque applied and the source of that value.
- At completion: a photo of the finished position; the retorque status — done, or handed over, and to whom; the signature of the person on site, with their name and their relationship to the vehicle.
- Around the job: the authorisation, with value and PO; the arrival and completion times the system derived; any casing taken away, tied to the disposal record.
The person signing is worth a sentence of its own. On roadside work the driver is present, is not the payer, and often has no authority to accept anything. Capturing "signed by" without capturing "in what capacity" produces a signature that settles nothing. The useful record is the driver's name, that they were the driver, and separately the authorisation from whoever could actually give it.
Where operations lose these arguments
Four failure patterns, in rough order of how often they cost money.
The evidence is complete but nobody checked before invoicing
An incomplete evidence set discovered at invoicing is a credit note; discovered at the job it is thirty seconds of a fitter's time. The check has to sit between completion and billing, and it has to be able to hold the job, or it will be skipped exactly when the day is busy — which is exactly when evidence gets missed.
The gap is only visible per job, never across a period
Most systems can show you one job's photos. Very few can answer "across this contract, this quarter, how many jobs are missing a required checkpoint?" That is the number that matters, because it is the number your customer will eventually calculate for you.
The evidence is on the fitter's phone
If capture depends on the fitter remembering to upload, then evidence quality tracks how tired the fitter was. Capture has to happen inside the job, offline where necessary, and sync when it can — not as a separate act of diligence at the end of a shift.
Nobody can produce it eighteen months later
Disputes are not always prompt. A wheel-off claim or a contract review can reach back a long way, and evidence that exists but cannot be retrieved against a contract and a period is evidence you do not have. Retention is a filing problem, not a storage problem.
How AxleGrid handles this
Briefly, and only the parts that are built.
- Every uploaded file is SHA-256 hashed and chained to the previous item on the job, so the bundle reports whether it is intact rather than asking to be trusted.
- Checkpoints are defined per job, and the bundle reports which are complete — so a job can be held out of billing until the evidence is there.
- Evidence is reviewed, and a reviewer can reject an item back to the fitter with a reason, which is itself recorded.
- Evidence completeness and acceptance appear in the period return for a contract, so the across-a-quarter question has an answer.
- Authorisation is a record with who, when and what value, not a note on a job.
- Everything sits in an append-only audit ledger with before and after values, which the tenant's own auditors can filter and export.
What it does not do is judge whether a photograph shows what it claims. No system does. The point is to remove every other argument so that the one left is about the work.
How this turns into a contract pack · Wheel retorque records · How the evidence chain is built · Book a walkthrough
This page describes commercial dispute practice between a service provider and a fleet customer. It is not legal advice, and nothing here is a statement about what any court would accept.