ComplianceSoftware Engineering

Evidence that holds up: what makes field data trustworthy

A report is an assertion. The photograph attached to it is what makes it evidence — and in most field operations, the photograph is the least protected part of the whole document. Four design decisions that change that.

Samuel KirighaFounder, McDorcis Solutions3 August 20266 min read

There is a moment in most compliance conversations where someone asks how you know. Not what your record says — how you know the record is true.

If your answer involves a photograph, it is worth asking where that photograph currently lives, who could have changed it, and whether anything ties it to the specific finding it supports. In most field operations I have looked at, the honest answers are: on somebody's phone, anybody, and no.

This is about four decisions we made building an audit platform for Texas SoluTech, an electrical safety consultancy whose engineers were photographing findings on personal devices and assembling reports afterwards. They generalise well beyond electrical safety — they apply anywhere a person away from the office records something the business later has to stand behind.

Evidence uploads at capture, not at the end

The obvious design is to let an engineer complete an audit and submit everything together. It is simpler to build and it is what most people expect. We upload each photograph the moment it is taken, straight to storage, keyed to the specific checkpoint on the specific audit record.

The reason is that the gap between capture and submission is where evidence goes wrong. Photographs sit in a camera roll among personal pictures and then have to be matched back to findings by a human being at the end of a long day. That matching step is where the wrong image ends up against the wrong finding — not through dishonesty, just through a tired person and forty near-identical photographs of distribution boards.

Removing the gap removes the failure. There is no camera roll, no manual labelling, and no file to lose.

The record cannot be submitted incomplete

An audit cannot be submitted with gaps. Every section is validated on the device before the record leaves it.

This is more contentious than it sounds, and engineers dislike it at first. The alternative — allow partial submission, chase the gaps later — is friendlier in the moment and produces a permanent backlog of nearly-finished records that somebody has to pursue.

The judgement is that a strict rule at capture is cheaper than a chasing process forever. I would still make that call, but be clear-eyed: it moves cost from the office to the field, and you should tell the field team that is what you are doing and why, rather than letting them discover it.

Drafts survive bad connectivity

An engineer in a plant room does not have signal. If your system assumes connectivity, it will fail exactly where the work happens.

Audits save locally and sync when there is signal, so a single audit can span several sessions and several site visits without anything being lost. In Kenyan field conditions this is not a nice-to-have; it is the difference between a system people use and a system people work around by going back to paper.

The audit trail is designed in, or it does not exist

Every review action carries a timestamp and the identity of whoever took it. Managers see submissions arrive in real time, read every checkpoint response and photograph, comment inline, and either approve or return for revision. Approval is what generates the finished report.

That last detail matters more than it appears. Because the document is generated from the approved record rather than assembled by hand, the report and the audit trail cannot drift apart. There is no step where a person retypes a finding into a template and quietly changes a word.

The general principle: an audit trail has to be designed in from the beginning. Retrofitting one is expensive, and — this is the part people miss — the trail it produces only covers the period since it was added. The years before that remain unevidenced no matter what you spend.

The one worth stealing

The feature I would point any field operation at is the danger notification. When an engineer finds an immediate electrical hazard, they log it from site with photographic evidence and it appears in the office dashboard instantly.

Before, that was a phone call. A phone call is fast and leaves no record. It relies on the right person answering, remembering, and acting — and if anyone later asks when the hazard was reported and to whom, the answer is somebody's recollection.

Making the urgent path also the recorded path is the trick. If the fast way to escalate something is also the way that documents it, people use it and you get the record for free. If your documented process is slower than picking up the phone, you will get phone calls and no records, and no amount of policy will change that.

What this is really about

None of these four decisions is technically difficult. They are all cheap at design time and expensive to add later, which is the actual reason they get skipped.

If you are commissioning a system that will hold records you may one day have to defend, ask before anything is built: where does the evidence live and who can alter it, what happens when the device is offline, is the record forced to be complete, and does the audit trail start on day one.

Further reading

Tell us the job you would most like off your team's plate.

Thirty minutes, no obligation, and a straight answer on whether it is worth automating.

Book a free consultation

More reading

  • The five ways a paper process quietly costs you

    When we audited a Kenyan electrical safety consultancy's reporting process, the delay everyone complained about turned out to be the least expensive problem. Here are the five we actually found, and how to check for them in your own operation.

All articles
logo

202, Madonna House,
Westlands Road,
Westlands,
Nairobi, Kenya

T: +254704093039

E: info@mcdorcis.com

@mcdorcis.com 2026

emailinfo@mcdorcis.com
email+254704093039