Proof of service
The record of the work is the product
You are paid for work nobody in the office watched. Somebody drove somewhere, opened something, looked at it, fixed it or collected it, and left.
What you can show about that is the whole asset. It is what a customer accepts, what an insurer asks for, what a national account audits you against, and what settles an argument eleven months later when nobody remembers the day.
So proof is not a reporting module bolted on the end here. It is the output. Everything else — the dispatch, the checklist, the photo step, the typed answer — exists to produce it.
This is a module, and it is the usual first one. It needs the field app capturing answers. It does not need your billing, your purchasing or your customer master — which is why a shop can buy proof alone and keep everything else exactly where it is.
Three grains: a job, a run, a day
Different customers ask for different shapes of the same truth, and getting the grain wrong is why most “service reports” go unread.
One job — the story
Everything captured on a dispatch: every visit, who went, the three time intervals, and every answer from every procedure — photographs, readings, serial numbers, signatures. This is what a homeowner or a facilities manager wants.
One procedure — the run review
The story of a single visit in the technician’s own answers, read back before anybody signs it off. Useful for a supervisor, and for the technician themselves.
One day — proof of the day
Every stop for one customer, one site or one driver on one date, in time order, as a single document. A bank running forty collections does not want forty job reports. It wants Tuesday.
One job, assembled as a document. Print it or save it as a PDF.
A real one
This is not a mock-up. It is a proof-of-the-day PDF for a bank’s collection round, generated from the record in about a second.
Eight stops, eight finished, eight carrying proof, thirty-four answers.
Look at one stop. The site and its address. Arrived 08:07, started 08:09, finished 08:14. The work code. What the office had told them. Then every answer the procedure captured — who handed the bag over, by name, and the seal number — each with the coordinate it was recorded at.
That is the difference between telling a customer you were there and being able to show them.
It shows the stops with nothing captured
This is the design decision we would most want a buyer to understand, because it is the one that makes the rest of it worth anything.
The obvious way to build this report is “find the day’s procedure runs and print them”. That produces a beautiful document that is a lie. A day where thirty drivers ran the checklist and thirteen did not comes out as thirty perfect proofs, with nothing anywhere saying the other thirteen exist.
So it does the opposite. It starts from the day’s stops and attaches proof to them. The cover carries the gap:
— and every bare stop is named in the body, in words: “No procedure was run at this stop, so there is nothing captured to show.” If part of the read failed, that prints on the sheet too, rather than sitting in screen chrome that vanishes when you print it.
The file that was sent is the record
When a document is produced, the bytes are stored, hashed with SHA-256, and filed against the customer. That file is what gets downloaded, emailed and kept.
🛑 It is never re-rendered later. Re-making last month’s proof against today’s data produces a document the customer never received — today’s addresses, today’s site names, today’s corrections — and then hands it to them in a dispute as though it were the original.
The hash is the point rather than decoration. Thirty-two bytes that prove the copy a customer holds is the copy that left here. If anyone ever disputes a document, that is the answer.
⚠️ The archive lists what was produced. Recording delivery against the file itself is the next piece, and we would rather say so than let you find out.
Pick who it is for and the day. Build it, send it, keep the copy that went.
Why a photograph is evidence, or is not
A photograph carries when and where it was taken buried inside the file. That detail is what makes it evidence rather than a picture — and anything that shrinks the image destroys it.
Which is a problem, because shrinking on the handset is the obvious implementation: a 12 MB photo over a cell connection is painful. Do that and “we captured the location and the time” quietly becomes “the phone told us” — a different claim, and the one that does not survive being challenged.
The full image crosses the wire
This is the cost, and it buys everything below it.
The server reads the detail off it
From the bytes the device actually produced, not from what a client asserted.
The server hashes the original
This is the step everybody skips, and the one that actually works.
Then it is shrunk and stored
So the storage bill stays sane.
The original is optionally discarded
The only per-procedure knob. The detail and the hash are kept either way — so a shop that wants cheap storage can still prove nothing was doctored, and a shop carrying bags of cash deposits can keep the originals.
And it is a capability, not just a button
Building a proof, rendering the PDF and sending it are three capabilities like any others — so they are a screen, a REST route and an agent tool at the same time.
Which means a customer’s own system can pull Tuesday without anybody logging into a portal, and “email the bank yesterday’s proof” is a sentence rather than a Monday morning.
It also means the whole thing can be bound to an event: the last stop of a round finishes, and the document goes. Nobody remembers to do it, because nobody has to.