Skip to main content
DoneThat

AI Adoption GuideGovernmentInspect

Sensor-based infrastructure anomaly detector

ML processes IoT and sensor streams from assets continuously, flagging deterioration and safety anomalies before physical inspection is triggered.

Government processPlanFundAuthorizeDeliverInspectEnforceReportClose

By Don, DoneThat’s AI coach · updated

A usable flag cites the sensor, the reading, and the threshold

The quality outcome is a flag an engineer can check, or nothing, because the stream stayed ordinary. When a reading leaves the band in a published threshold document, emit the sensor ID, the reading, and a cite to that document. If the stream is ordinary, leave the output empty. An engineer still dispatches.

A colored tile is not the outcome. A tile that cannot print those three cites cannot be audited, cannot be explained to a regulator, and cannot be replayed. The inspect job for government infrastructure is to decide whether a competent person should go to the asset. The detector makes that decision cheaper to start. It does not replace the visit.

A flag that says only "anomaly on structure 14" is not usable. The desk cannot tell which channel moved, what value it showed, or which rule it broke. A flag that names the register ID, the value with unit and timestamp, and the specification section that defined the band is something an engineer can act on or dismiss.

Do not add a failure percent. The detector does not know how often the asset "fails," and inventing that number is not analysis. Severity exists only if the same published document already defines tiers. If the document has one alert band, the flag is binary: in band or out.

Bind the live stream to a published threshold document

Load two inputs before any model runs: the IoT or SCADA stream keyed by sensor ID, and the threshold document that already governs that asset. The document is typically an inspection specification, a dam safety instrument plan, a consent condition, or a manufacturer's envelope the agency has adopted. The detector does not write it. It reads it.

If a channel has no published threshold, do not invent one. Inventing a band so the pipeline has something to fire against is a failure mode. Park the channel as unthresholded and send it back to the asset owner to set a band in the same process they use for inspection criteria. A made-up limit generates flags that look precise and mean nothing.

Platforms from Palantir, Microsoft, AWS, and Esri are a class of places this pairing can live: time-series ingest, geospatial context for the asset, identity for the sensor, and a store for the document. None of them is the threshold. If the cite cannot point at a versioned document the agency already uses, the pairing is not done.

Resolve identity before you score. Sensor IDs in the historian and labels on the drawing often drift. A flag that cites a historian tag the field crew has never seen will sit unread. Join the stream to the asset register, then to the document, then run.

Watch units and document version. A kPa band applied to a psi channel will paint the map red on every poll. A cite to a withdrawn revision will send crews against a rule the agency no longer holds. Both look like detection. Both are load errors.

Leave ordinary streams empty

Most hours, most sensors stay inside the band. The correct output then is empty. Do not emit a green "healthy" event for every poll. Do not fill a feed with "no anomaly" rows so the pipeline looks busy. Ordinary silence is the product. That silence is what makes a real flag visible. If every channel writes a status, the inspect desk learns to ignore the desk.

When a reading does leave the band, emit once per excursion, or once per persistence window the specification already defines, not once per sample. Then stop. The detector does not estimate remaining life. It does not diagnose the member. It does not close a finding.

Use one walk-through, not a result. A regional roads desk has a strain gauge on the downstream girder of a two-span river crossing. The structure's inspection specification already sets an alert band for that gauge and a persistence window. The historian is loaded. The specification is loaded and versioned. Overnight the gauge stays above the band longer than that window. The detector emits one flag: register sensor ID, reading with timestamp and unit, cite to the specification section and the numeric band. No percentage. No "likely crack." If the stream had stayed inside the band, overnight output would have been empty.

The flag is evidence, not a work order

Morning shift, an engineer reads that flag, checks adjacent gauges and traffic logs, and decides whether to dispatch a visual and NDT look at the girder. The engineer still owns the next scheduled inspection when the night was quiet. The flag is a reason to open the inspection process, not a completed work order and not a finding.

Treating the flag as a work order is the second operational failure. It short-circuits competence. A strain spike can be a convoy, a wiring fault, a clock jump, or a real change in the member. The detector does not know which. The engineer decides whether to send a crew, wait for the next scheduled visit, or pull adjacent channels first.

Dispatch can be a physical inspection, a remote review of adjacent sensors, or a request for imagery. When the next step is visual confirmation of the site, the computer vision site auditor is a sibling inspect tool, not a substitute for the cited flag. When the next step is to place the visit against other risk on the calendar, hand the flag to the risk-based inspection scheduler. Neither tool should invent the threshold this detector failed to load.

After the visit, the inspection report auto-drafter can carry the same sensor ID, reading, and document cite into the draft. The detector still does not write the report.

Failures that look like a working detector

A red tile with no reading is the first failure. Operations paint a map, a channel goes red, and nobody can see the value or the rule. If you cannot print the sensor ID, the reading, and the threshold cite from the same object the tile represents, the tile is not a flag. Kill it or finish it.

Inventing a threshold is the third, already named at load time, and it returns in demos. A vendor session needs "something to show," a channel was never in the specification, or someone copies a band from a similar asset in another district. The copied band is not a cite. If the document is missing, the channel stays unthresholded. Empty is honest. A synthetic limit is not.

Cousins of these failures show up in production: a model that fits a baseline from a short window of quiet weather and then flags every storm; a stale document version; a join that maps the wrong gauge to the right structure. None of these is a quality outcome. The test is simple. Can a second engineer, given only the flag object, find the sensor, reproduce the reading, and open the same threshold document?

Where this sits in inspect work

This detector watches continuous streams. Crews still walk structures. Cameras still capture conditions the gauges cannot. It does not certify that a consent condition is met. It only says whether a named sensor left a named band.

Closed or mothballed assets with instruments still on them (landfills, decommissioned plants, residual dam instrumentation) follow the same rule: cited threshold or empty. Continuous obligation watch after closure is a different job, the post-closure obligation monitor. Do not stretch this detector to sign that a post-closure condition is satisfied.

Keep the roster honest. Someone on the asset class must be able to say they accept this flag as a reason to go. Someone must be able to say this channel has no threshold, so do not color it. If those two roles are missing, the platform stack does not matter.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first