Turning Sensor and Camera Signal Into a Leadership Decision
The plant manager has more data than anyone who ran this floor a decade ago could have dreamed of.
Vibration sensors on the critical pumps. Temperature probes on the line. Cameras over every station, recording everything. A historian logging thousands of tags a second. By any measure, the floor is wired. And yet, when she is asked the only question that matters — *is anything about to cost us money, and what should I do about it* — she still walks the floor, calls the supervisors, and waits for the morning meeting. The sensors did not answer the question; they produced more of something she now has to go interpret by hand.
This is the quiet paradox of a well-instrumented operation: more signal did not produce more clarity. It produced more *noise* — thousands of readings a second, each true on its own, none assembled into the one thing a leader needs.
The scale of the waste is not subtle. In McKinsey's Internet of Things research, an oil rig with 30,000 sensors had only 1% of its data examined — and even that 1% was used mostly to detect and control anomalies, not for the optimization and prediction that create the most value. Ninety-nine percent of the signal a company paid to capture never became a decision — captured and abandoned in the same breath.
A floor can be drowning in sensor data and starving for a single decision.
This is about closing that gap: how raw signal from sensors and cameras becomes one owned decision, made while there is still time to act.
Direct answer:
Raw sensor and camera signal becomes a leadership decision in four steps: capture the signal, give it context by connecting it to the asset, order, and commitment it affects, judge whether it crosses a threshold that matters, and route it to one owner with the next move attached. Skip the middle two steps and signal stays noise.
Why 99% of the signal never becomes a decision
The instinct after that 1% figure is to add *more* sensors. That makes it worse: the rig with 30,000 sensors did not have a capture problem.
On its own, a reading is a fact with no meaning: pump vibration is 4.2 mm/s. So what? On which pump, feeding which line, behind which order, for which customer? The reading cannot know — it is a number leaving a device. Three gaps turn all that signal into noise no matter how much you collect:
- No context. A reading without the asset, line, order, and commitment behind it is a number floating in space. You cannot act on 4.2 mm/s; you can act on "the pump feeding this week's biggest order is trending toward failure."
- No judgment. Even with context, somebody has to decide whether the reading *matters* enough to interrupt a leader's day. Skip this and you get alarms for everything (people learn to ignore them) or alarms for nothing (the historian logging a failure in advance).
- No owner. A signal that reaches a screen but not a person is a signal nobody acts on. No dashboard ever fixed a pump. The decision has to land on the one person who can make it, with the move already framed.
Fix those three and signal becomes decision. Skip any one and you have a wired floor that still cannot answer the leader's question.
From signal to decision: the four steps
Capture. The raw layer — vibration, temperature, pressure, cycle time, counts, camera frames — pulled from the sensors, cameras, machines, and historians already on your floor. Most operations already have this; capture is rarely the gap.
Context. This is where signal stops being noise. The reading gets connected to what it concerns: *this* vibration belongs to *this* pump, which feeds *this* line, which builds *this* order, due to *this* customer on *this* date. The number stops floating; a rising trend becomes a risk to a named commitment with a dollar value and a deadline. This is the step a historian and a dashboard skip entirely — they show you the vibration chart, not which order is behind that pump.
Judgment. With context in place, the system can judge: does this reading, on this asset, behind this commitment, cross a line that warrants a decision? A pump drifting toward its failure band while feeding a low-priority job with weeks of slack is a maintenance note. The same drift feeding this week's biggest shipment with no buffer is a decision that needs a leader today — same reading, different judgment, because the context is different. This is what separates a useful alert from alarm fatigue.
The owned decision. One decision, one owner, the next move attached — not a wall of readings. A single framed call, "the pump behind this week's largest order is trending to failure; service it tonight on off-shift or risk a line-down during the shift that builds the order," routed to the person who owns that trade-off while there is still time to make it the cheap way. The leader's job is to *decide*, not to interpret telemetry.
Here is the pump from the story above run through the full path — illustrative, but the shape of a winning signal:
```mock
signal-escalation
```
Top to bottom, that card is the four steps — and nobody had to go looking for it.
Captured signal versus an owned decision
The difference between a wired floor and a floor that decides is not the amount of signal but how far each reading travels.
| Step | Captured signal | Owned decision |
|---|---|---|
| Capture | Lands in the historian | Lands in the historian |
| Context | A number, no asset or deadline | Tied to the pump, line, order, customer |
| Judgment | Every reading equal; sort it later | Weighed against what it threatens; ranked |
| Ownership | Sits on a dashboard nobody watches | Routed to one named owner with the next move |
Both rows start identically and diverge at step two. The left column is the rig with 1% examined; the right is the same signal, finished.
The same four steps, for a camera
A sensor produces a number, so it is easy to picture it crossing a threshold. A camera produces *images*, so operators often assume camera signal lives in a separate world. It does not have to — the same four steps apply.
On a finishing line, a camera over the final station sees every part go by. Capture is already handled — the footage rolls to storage, where in most operations it is reviewed only after something has gone wrong. Context connects the frame to this station, this run, this order: a part that looks off is no longer an anomalous frame but a quality risk on a run feeding a specific commitment. Judgment weighs it — a few off-looking parts on a run with generous tolerance and downstream inspection is a note; a rising rate on a run feeding a tight-spec customer with no re-inspection step is a decision. The owned decision reaches the line supervisor as one framed call: hold the run and check the setup now, or let it continue and risk a reject at the customer.
```mock
quality
```
Same path, different sensor. A camera is not a security system bolted onto the floor — it is another stream of signal that, given context and judgment, produces decisions about output and quality. That is what Production Intelligence does with camera and sensor signal alike. And it is exactly here that the framing matters most.
What this is not: coach and allocate, not police
The point of connecting camera and sensor signal is better decisions about assets, output, and quality — not watching people. When a camera flags that a station's output quality is drifting, the useful response is to check the machine setup, coach the operator, and rebalance the line if someone is overloaded. The signal exists to protect the run and allocate help fairly, not to build a case against a worker.
This distinction is not soft. An operation that uses its signal to coach, fix machines, and balance workload gets a floor that trusts the system and flags problems early. An operation that uses the same signal to police people gets a floor that hides problems and games the cameras. The first compounds; the second corrodes. The system flags what needs attention; people decide what to do — and the decisions worth making are about the work, not about surveillance.
The scale of what is hiding in the signal
It is tempting to treat all of this as a refinement, not urgent. The numbers say otherwise. According to Kimberlite's oil and gas research, the average offshore operator loses about $38 million a year to unplanned downtime, and for the worst performers the figure exceeds $88 million.
Where does that loss come from? Rarely a sensor that was not there — the vibration was usually rising for days. The signal that a critical asset was heading for failure almost always existed; it just stayed a reading in a historian, true and unwatched, until the asset failed and the reading became a post-mortem. The gap that costs $38 million is not a missing sensor — it is the missing path from the signal that was already there to the leader who could have acted on it.
Before and after, on a real floor
Same plant, same critical pump, same rising vibration. Watch what changes when the signal is just captured, versus turned into a decision.
Captured, not connected. The vibration sensor on the main feed pump has trended up for nine days; the reading sits in the historian. On day ten the pump fails mid-shift — during the run building the week's largest order. The line goes down, procurement scrambles a replacement on emergency freight, and the order ships late. Roughly: a 9-day trend nobody owned → line-down on the priority order → emergency freight plus a late shipment → tens of thousands in margin and expedite cost. Illustrative numbers, but Kimberlite's $38M average says this shape repeats across the year, not once.
Connected to a decision. The same trend, day three. Because the sensor is tied to the pump, the pump to the line, and the line to this week's largest order, the system judges it: an asset trending to failure behind a high-value, no-slack commitment. That crosses the line. A single decision lands on the plant manager's desk that morning — service tonight on off-shift, or carry the risk into the shift that builds the order — with the cost of each path attached. She pulls it for service that night, and the order ships on time.
The signal was there both times. The only thing that changed is that in the second case it became a *decision* — with context, judgment, and an owner — while there was still a cheap way to act. The "after" did not require more sensors or a bigger control room.
"Why can't a leader just watch the dashboards?"
The honest objection is: we already built dashboards for this signal, so why don't leaders just watch them. A leader cannot watch a dashboard the way a sensor produces readings — continuously, around the clock. A pump trends up over nine days, mostly during off-shifts and weekends. For the dashboard to catch it, the right person would have to be looking at the right panel at the right moment, recognize that this drift threatens this week's order, and decide to act — all while doing the other forty things that own their day.
Dashboards are a *pull* model: the signal waits for someone to come look. That works for the question you already know to ask — "how is the line doing right now" — and fails for the problem you do not yet know exists, which is precisely the problem that costs you money. Turning signal into a decision flips that to a *push* model: the system does the continuous watching, applies the judgment, and brings the decision to the owner when something crosses the line that matters. That is why "we have dashboards" and "we catch problems early" are two very different claims.
Where this fits in the bigger picture
One pump, one decision, is real money saved. It compounds because the same path works for every sensor and camera on the floor: the leader stops getting a thousand readings and a daily walk, and starts getting a short list of owned decisions, ranked by risk. Each lands as a real owned task with a name and a deadline, which is why the signal feeds the same AI project management that runs the rest of the operation, not a separate alert console.
This is the gap your existing systems leave open. Your MES executes and records production; your historian stores the readings. Neither connects a rising vibration trend to the order it threatens and frames it as a decision for a named owner. That connecting layer sits *above* the systems you already run rather than replacing them. That layer is the platform. The decision is the product; everything else is plumbing in service of it.
Common questions
We already have sensors and a historian — isn't that the same thing?
No. Storing readings is step one of four. A historian holds the vibration trend; it does not connect that trend to the order behind the pump, judge whether it crosses a line that matters, or route a decision to an owner. McKinsey found a rig examining 1% of 30,000 sensors — rich in storage, starved of decisions. Most plants are the same.
Won't connecting more cameras and sensors just create more alarms?
The opposite, if judgment is built in. Alarm fatigue comes from flagging every reading regardless of context. Weigh each signal against what it threatens — a no-slack commitment versus a job with weeks of buffer — and most readings resolve to "note it." Only the ones that warrant a decision reach a leader. Fewer alerts, each worth acting on.
Is this using cameras to monitor workers?
No, and the framing is deliberate. Camera and sensor signal here is about assets, output, and quality. When it points at a person, the right response is coaching, fixing the machine setup, or rebalancing the line — not building a case against them. A floor that is coached surfaces problems early; a floor that is policed hides them. The goal is fair allocation and better output.
How is this different from a dashboard?
A dashboard shows you readings after you go look, and leaves the interpretation to you. This delivers a decision *to* the owner — context, judgment, and next move already attached — while there is still time to act. One waits for a leader with time to interpret telemetry; the other hands them a call they can make in a minute.
Do we need to replace our floor systems or our historian?
No. The intelligence layer sits *above* the sensors, cameras, machines, and historian you already run, and connects them. You keep capturing signal the way you do today. What changes is that the signal now has a path — to context, to judgment, to an owner — instead of dead-ending in a store nobody watches.
Where do we start if we're already drowning in signal?
Start with the one asset whose failure hurts the most — usually a constraint pump, motor, or machine on the critical line — and connect its signal to the orders behind it. Prove that one rising trend becomes an owned decision days early instead of a post-mortem, then expand. It is weeks of work on your highest-stakes asset, not a floor-wide rewire.
Turn the signal you already have into decisions
Your floor is probably already producing the signal that would prevent your next expensive failure. Book an intelligence-layer assessment, and we will find the one asset whose signal should be a decision — and exactly what it takes to put that decision in front of the right owner in time.