BE Teck Notes Back to be-teck.com

5 min read

A site photograph is a record, if anything reads it

Thousands of site photographs are taken every month and almost none become records. The bottleneck is not capture. It is that nothing ever looks at them.

Photographs are the most complete data a construction site produces. They are taken constantly, without being asked for, by everybody, and they contain more than any form would have collected.

They are also, on most projects, worth nothing at all, because nothing reads them.

Why the photograph exists in the first place#

Somebody takes a picture instead of writing because the picture is faster and more complete. A delivery slip photographed contains every field a form would have asked for. A crack photographed says more than three sentences would, and photographed again after the repair it is what closes the item on a snag list that actually closes.

That behaviour is not laziness to be corrected. It is a correct assessment of effort against information, made by somebody who is standing up and busy. The question for a system is not how to stop it. It is how to accept it.

The gap between capture and record#

We had over a thousand photographs sent from site whose text had been machine read and stored, and nothing had ever looked at the result.

The check that should have used it read only the caption somebody typed. And site photographs usually have no caption, because the delivery slip in the picture already says everything, so nobody types.

The extraction worked. The storage worked. Nothing was broken and nothing had errored. The output simply had no consumer, and a produced result with no consumer looks — from every direction, including from the inside — exactly like a feature that was never built.

This turns out to be one of the commonest classes of defect we find. Work that was done, correctly, and never wired to anything. The general case is written, and never wired.

What a photograph needs to become a record#

Four things, and only the first is about the image.

A subject the machine can identify. A delivery slip, a hazard, a defect, progress, a person, a meter reading. Roughly, is this a document, a condition, or a scene.

A place. Which site, which area. Usually derivable from who sent it and when, which is much more reliable than asking.

A time. Almost always present and almost always trusted too readily — a photograph of a photograph, or a picture taken yesterday and sent today, both carry misleading times.

A connection to something. An order, a task, a location, a person. A photograph attached to nothing is not a record; it is an image in a folder.

The fourth is where nearly all the value sits and where nearly all systems stop.

Reading the text is the easy half#

Extracting text from a photograph of a document is a solved problem to a useful degree of accuracy. Getting from that text to the right record is not.

Our extraction was reading delivery slips correctly and matching them against nothing, because the matcher only considered purchases that had not yet been paid — and in our process, payment precedes dispatch. By the time material arrived and somebody photographed the slip, the correct purchase was always paid and therefore never a candidate. Every slip matched nothing. A slip matched to nothing appears on no screen at all.

The reading was never the bottleneck. The connection was.

Three rules we ended up with#

Machine reading produces a suggestion. Extracted text gets digits wrong, and a document number with a wrong digit is worse than a missing one because it looks usable. Every match is a proposal a person confirms with one tap, and a rejection is remembered so the same wrong pair is never offered again. The argument is in the machine proposes, a person decides.

Refuse the obvious non-cases rather than guessing. A cylinder going out for refilling, a vehicle that damaged a divider, a weight dispute — these look superficially like delivery messages. A system that files them as receipts is worse than one that files nothing, because somebody must now find and remove them.

Privacy is enforced before processing, not after. This one we got wrong. Our text extraction ran before the check that knew which rooms were private, so a personal photograph was being read and, if the text resembled a delivery slip, filed as a goods receipt. The correction was not to discard the result afterwards. It was to exclude private rooms at the query, so the bytes are never fetched at all.

A privacy control that runs after the data has been processed is not a privacy control. It is a cleanup.

Not every photograph should be quiet, and not every one should ring#

There is a routing decision hidden in this that took us a while to see.

A contractor's room is correctly kept at arm's length — their progress photographs are their business and notifying our staff about each one would be noise. But a photograph that reads as a hazard or a defect is exactly what the channel was added for, and keeping that quiet is a different kind of mistake.

So the rule is by content, not by source: hazard photographs notify, progress photographs do not, regardless of which room they came from.

The general shape of that decision — classify by what the message asks somebody to do, rather than by where it came from or how important it feels — is the subject of an alert that rings for everything.

What to do with the archive you already have#

Most organisations have years of photographs sitting in chat history, in folders named by date, on individual phones.

That archive is worth something, but not much, and it is worth being honest about why: it has no connections. Reprocessing it will give you dated, located images and very few links to orders, tasks or events, because the records those would connect to have moved on.

The better investment is almost always forwards. Get the pipeline right from today — subject, place, time, connection, with a person confirming — and let the archive be what it is, which is a searchable pile that occasionally settles an argument.

The short version#

Site photographs are already the richest record you have and almost none of them are records, because nothing consumes them.

Reading the image is the easy part. Connecting it to an order, a task or a location is the hard part and the valuable one.

Suggest rather than file. Refuse the obvious non-cases. Enforce privacy before the bytes are fetched. Route by what the picture shows, not by where it came from.

And check, in your own tools, whether anything is actually reading the output of the thing you built to produce it. The answer is surprisingly often no.

Have a gap worth closing?

If something in your daily work is broken in a way everybody has stopped complaining about, that is exactly what we want to hear.

Write to hello@be-teck.com

More notes