Turn sensor anomalies into temporary maintenance actions: decision tables for workarounds vs schedule fixes

The gap most teams struggle with isn't detecting the anomaly. Sensors flag deviations constantly. The real problem is what happens in the next 15 minutes: does someone throw a temporary fix on it, bump the monitoring interval, or open a full corrective work order?

That decision usually lives in a lead tech's head. And that's the whole problem. When the call to apply a temporary workaround goes undocumented, you end up with two failure modes — either the "temporary" tape-and-pray fix quietly becomes permanent, or a genuinely minor drift gets escalated into an emergency shutdown because nobody knew it was safe to run for another two weeks.

This post is about closing that gap with sensor-specific decision tables that spell out when a temporary maintenance action is allowed, how often you re-check it, what conditions force a rollback, and — the part everyone skips — what evidence has to exist before the work order can actually close.

The decision that keeps getting made informally

Here's the sequence that plays out in most plants. A bearing temperature sensor on a mid-sized pump climbs from its usual 62°C to 78°C over a shift. It's above the "investigate" band but well below the trip. The night supervisor calls the on-call tech. The tech says "keep an eye on it, we'll look tomorrow." No log entry, no interval defined, no threshold for when "keep an eye on it" turns into "shut it down now."

That verbal handoff is where things break. The next shift doesn't know what "keep an eye on it" meant. Was it check hourly? Check if it passes 85°C? Nobody wrote it down, so the sensor is effectively unmonitored until someone happens to glance at the trend again.

Across a lot of asset-heavy operations, these informal deferrals aren't rare edge cases — they're the majority of how anomalies actually get handled. The formal work-order process kicks in for the obvious stuff. Everything in the ambiguous middle gets resolved by whoever's on shift, using judgment that never gets captured.

The decision table exists to move that judgment out of one person's head and into a rule that any shift can execute the same way.

What a sensor-specific decision table actually contains

A generic "escalation matrix" won't cut it, because the safe workaround for a vibration reading on a fan is nothing like the safe workaround for a pressure transmitter on a hydraulic line. Each table has to be built per sensor type and per asset criticality.

Every row needs to answer four questions:

1. 1
   What triggered this? The specific reading band or rate-of-change that puts you in this row.
2. 2
   Is a temporary workaround permitted, and which one? Named, bounded, and time-limited.
3. 3
   How often do we re-check while the workaround is live? An explicit monitoring interval.
4. 4
   What forces a rollback or handback, and what evidence closes it? The conditions that end the temporary state.

Here's a simplified example for a bearing temperature sensor on a Criticality-B pump:

The exact numbers aren't the point — those come from your own drift history and OEM limits. What matters is that the ambiguous middle now has explicit, repeatable behavior attached to it.

The rule nobody writes: an expiry date on "temporary"

The biggest failure with temporary maintenance actions is that they have no expiry. A workaround applied on a Tuesday is still running six months later because it "seemed fine."

Every temporary action needs three fields baked in from the moment it's created:

1. 1
   Applied timestamp — when the workaround went live
2. 2
   Max allowable duration — the hard ceiling before it must convert to a scheduled fix
3. 3
   Handback trigger — the event or reading that ends the temporary state early

That max duration is what forces the conversation from "it's still working" to "we agreed this had to be permanently fixed by now." Without it, temporary workarounds accumulate into a shadow backlog nobody's tracking — reduced loads, bypassed interlocks, manual readings covering for dead transmitters. Each one is a small accepted risk. Stack enough of them and they quietly erode reliability across the whole asset base.

A useful discipline: when a workaround hits 50% of its max duration and there's no scheduled fix on the calendar, that alone should generate an escalation. Don't wait until the deadline.

Monitoring intervals are a decision, not a default

Teams tend to pick monitoring intervals emotionally. Something looks concerning, so they say "check it every hour" — then reality sets in, nobody has time, and the checks silently stop.

The interval should be tied to the rate at which the failure mode actually develops, not to how nervous the reading makes people. A bearing that historically takes 40+ hours to go from elevated to failure doesn't need hourly checks. A seal leak that can cascade in under an hour does.

This is where drift history earns its keep. If you've been capturing calibration and drift data properly — the kind of record-keeping covered in risk-based calibration scheduling for instrumentation — you already have the evidence to set intervals from real degradation curves instead of guesswork. The interval becomes defensible because it's derived from how the asset has actually behaved.

1. 1
   Does it give at least 2–3 readings before the next threshold at the worst observed rate of change?
2. 2
   Is someone actually assigned to each check, or is it "whoever's around"?
3. 3
   Does a missed check trigger an alert, or does it just silently not happen?

“

Tie the interval to the worst-observed rate so you reliably get multiple readings before the threshold.

If a missed check produces no signal, your monitoring interval is decorative.

Evidence rules: the part that closes the loop

The operational pattern that causes the most audit pain: a temporary workaround gets applied, the reading normalizes, and someone closes the work order with a note like "resolved, monitoring." No photo, no measurement, no confirmation the workaround was even removed.

Six months later, when the asset fails hard, nobody can reconstruct what was actually done. Was the workaround still active? Was it ever converted to a permanent fix? Did the reading normalize because the problem resolved, or because the sensor drifted?

Evidence requirements need to be defined per row of the decision table — not as a blanket policy. A minor load-reduction workaround might need three logged stable readings. A run-to-outage deferral on a rising trend should need a thermography image and confirmation the corrective WO actually exists in the schedule. The stricter the deferral, the harder the evidence.

The rule of thumb: the evidence required to close should be proportional to the risk you accepted by deferring. If you deferred nothing, minimal evidence. If you deferred a genuine intervention, the evidence has to prove the risk stayed inside the boundary the whole time.

This also connects directly to how you tune the thresholds themselves. If your bands are wrong, the whole table produces bad decisions — which is why the threshold-setting work in predictive vibration threshold tuning for rotating equipment sits upstream of everything here. The decision table is only as good as the bands feeding it.

A real scenario

A regional water treatment operator running around 40 pumping assets kept hitting the same problem: their most experienced reliability tech was the informal gatekeeper for every borderline anomaly. When he was on shift, deferrals were sensible. When he wasn't, the team either over-escalated (unnecessary shutdowns) or under-reacted (running assets past reasonable limits).

They built decision tables for their four most common sensor types — bearing temp, vibration, discharge pressure, and motor current — covering their Criticality-A and B assets. Not a massive project; roughly three weeks of pulling drift history and arguing over bands.

The change wasn't dramatic on paper but it showed up in operations. Emergency shutdowns triggered by ambiguous readings dropped over the following quarter — from something like a dozen a month down to a handful. More importantly, "temporary" workarounds stopped disappearing into the shadow backlog, because each one now carried a max duration and an automatic escalation at the halfway mark. Two long-running bypasses that nobody remembered were flushed out in the first month just from applying the expiry rule retroactively.

The tech, notably, was relieved. He wasn't the single point of failure anymore.

Where a management platform makes this stick

Decision tables written in a spreadsheet degrade fast. Someone updates one copy, the version on the shop floor goes stale, and you're back to tribal knowledge. The value only holds when the table is enforced at the point of decision.

An AI-assisted maintenance platform genuinely helps here — not by making the call for you, but by removing the ways the process quietly fails. When a sensor crosses a band, the system can surface the applicable row, require the necessary fields (applied timestamp, max duration, monitoring interval) before the workaround gets logged, and fire the halfway-point escalation automatically instead of relying on someone to remember. It can also block a work-order close when the row's evidence requirement hasn't been met — no more "resolved, monitoring" closures with nothing attached.

Below is a visual workflow showing how a platform enforces the decision table at the point of decision.

The automation itself isn't the interesting part. The interesting part is that the rule you agreed on runs the same way on every shift, and the evidence trail builds itself. That's the difference between a decision table that lives in a binder and one that actually changes behavior.

When this is worth building — and when it isn't

Build sensor-specific decision tables when:

1. 1
   You have assets running in the ambiguous middle band regularly, not just clean pass/fail
2. 2
   Deferral decisions currently depend on specific individuals being available
3. 3
   You've had "temporary" fixes turn permanent without anyone deliberately deciding to make them so
4. 4
   You already have enough drift and trend history to set defensible bands

Skip it, or keep it minimal, when:

1. 1
   The asset is simple enough that any anomaly just means "fix it now" — no meaningful deferral option exists
2. 2
   You don't yet have reliable sensor history, in which case fix your data capture first or your bands are fiction
3. 3
   The asset is low-criticality and run-to-failure is the accepted, deliberate strategy

Don't try to table every sensor on every asset. Start with the sensor types on your critical assets that generate the most borderline decisions. Those are where the informal judgment is costing you the most.

The takeaway

Sensor anomalies aren't really the hard part. The hard part is the murky decision that follows — workaround, watch, or fix — and the fact that decision is usually made verbally and never captured. Sensor-specific decision tables turn that judgment into something repeatable: defined triggers, bounded workarounds with expiry dates, monitoring intervals tied to real failure rates, and evidence proportional to the risk you accepted.

Do this well and two things happen. Your borderline anomalies stop depending on who's on shift, and your temporary maintenance actions stop silently becoming permanent liabilities. Both of those are worth more than the few weeks it takes to build the tables.