Why two engineers write two different reports

Written by The BlueWave team · Published 28 October 2026 · 6 min read

BlueWave is Legionella compliance software for UK water hygiene contractors. BlueWave is not affiliated with or endorsed by the Legionella Control Association.

Send two competent engineers to the same site in the same week and you can get back two reports that don't match. Different findings flagged, and a different view of whether the calorifier is a problem. The instinct is to decide one of them is wrong, or greener than the other. Usually neither is. The variance was built in before either of them arrived.

Two things produce it, and both are fixable without touching the people. The report has no fixed structure, so each assessor imposes their own. And the template they fill in doesn't cover the whole standard, so it leaves room for judgement exactly where judgement diverges. Fix the deliverable and most of the variance goes with it.

The LCA already named the cause

The Legionella Control Association, auditing its own registered members, keeps finding the same weakness: a lack of evidence of assessor competence combined with a template that doesn't cover all the elements of the LCA Service Delivery Standard, which is how two assessors reach different conclusions about the same system. Read that slowly, because it puts the blame somewhere unusual. Not on the assessor's ability. On the form they were handed.

If the template has a row for water temperatures but no structured prompt for, say, the condition of the cold water storage tank lid, or whether a little-used outlet was actually flushed, then whether those things reach the report depends on whether the assessor remembered to write a paragraph about them. One will. One won't. Same site, two records, and neither engineer did anything wrong.

That is worth dwelling on if you have ever refereed a dispute between two of your own people over a report. The argument feels like it's about competence or attitude. It almost never is. It's about a form that made something optional when it should have been mandatory.

Picture it on a single asset. Two engineers inspect the same cold water storage tank. One has a form that asks, in so many words, for the lid condition, the insect screen, a photo of the interior and the stored temperature. They answer four prompts, and the tank's state is on the record whether it was spotless or filthy. The other has a form with a free-text box headed "tank", and on a busy day a tank with nothing obviously wrong earns the single word "fine". Neither engineer was negligent. But one of those two reports can be defended three years later and the other cannot, and the only difference between them is how much the form insisted on.

What a report should contain every time

There is a fairly settled answer to what a water hygiene report needs before a client will trust it. The Water Hygiene Centre sets out the components that make one defensible: photographic evidence attached to each finding, a full asset register with photos and asset tags, a system schematic, and the written scheme of control kept as its own document, presented in a structure the client recognises from one visit to the next.

The point about structure is easy to skim past, and it does more work than the rest. A client who receives the same shape of report every quarter learns where to look. Findings here, a photo against each one, actions with dates below. When the shape changes because a different engineer attended, the client has to re-learn the document, and re-learning a compliance report feels like being handed a different supplier. Familiarity is doing quiet work in that trust.

Put the two ideas together and the standard for a report reads like this: every finding carries a photo, every asset is on the register with its tag, the schematic and the scheme of control travel alongside, and the order never changes. None of that depends on which engineer holds the phone. All of it depends on the template making those things compulsory instead of a matter of memory.

Consistency is a property of the form, not the person

Here is the shift worth making. Stop trying to train variance out of people and start designing it out of the deliverable. Your most senior assessor and a competent newer engineer should produce reports that read as though the firm wrote them, because in a real sense the firm did, through the form.

In practice that means a template where the required photos are required rather than suggested. Where the temperature rows are the same rows in the same order for the same asset type, so nobody invents their own layout in the van. Where a finding can't be closed without its evidence attached. Where the asset register is populated from the site's actual assets, so no one types "CWST" one week and "cold tank" the next. The judgement that should vary between engineers is the professional interpretation of what they find. The structure around that judgement is exactly what shouldn't move.

This is a different problem from getting reports finished at all, which is its own battle. We wrote about the proof debt that builds up between doing the work and being able to prove it separately. Consistency is the next problem along: two reports that both exist, both on time, and still disagree with each other.

It is also why a general field-service tool tends to struggle here. A job-shaped app treats the visit as a job with a notes field, and a free-text notes field is precisely where variance breeds. A purpose-built data model treats the visit as structured readings against known assets, which is the distinction between generic FSM and water-hygiene software and the reason it matters for the report rather than only for the schedule.

How BlueWave takes the variance out

BlueWave uses schema-driven forms in the engineer app, which is a technical way of saying the form is the same form whoever opens it. The temperature rows, the required photos, the asset list, the order of the sections: all defined once, in the template, and identical on every engineer's phone. A newer engineer and your most experienced assessor capture the same fields in the same structure, because the structure isn't theirs to change. Interpretation stays human. The shape of the record does not.

The register is built from the site's real assets, so a finding attaches to this tank with this tag, not to a note that reads differently every visit. When the assessor arrives for the annual LCA audit and samples last year's reports, they line up, because they were poured into the same mould rather than written from scratch by whoever was on shift.

Here is a test you can run this week without buying anything. Take last quarter's reports from two different engineers on similar sites and lay them side by side. If the sections are in a different order, if one has photos against each finding and the other has a lump of photos at the back, if an asset is named two ways, the variance is in your template, not your team. Fix the template and you fix every report that comes after it. Retrain the engineers and you only fix the ones who happened to be in the room. Report drift is one of the eight leaks BlueWave maps across an operation, and it's the slowest to show itself.

The work these posts describe, run properly

BlueWave books the work in, captures the evidence on site, and turns it into records a client or an auditor can actually use. See it on your own workflow.