Every conversation about AI in industrial operations eventually reaches the same question, usually from the most experienced person in the room: "So you want software to control my pump?" The answer that earns trust is not a demo. It's a boundary.

The boundary

KNOCE software is a monitoring and supervisory-request layer. Emergency shutdown, overpressure protection, interlocks — every protective function — remains with the certified hardware layer, independent of anything the platform does. If the cloud disappears, the alarms stop, and the AI goes quiet, the equipment protects itself exactly as it did before KNOCE arrived. We put this in the product plan before we wrote the first screen, and we put it in the Terms of Service on this site.

That isn't caution for its own sake. Protective systems are certified as a whole — hardware, wiring, logic, test procedure. A software layer that reaches into that loop doesn't just add risk; it invalidates the certification the plant already paid for. The right architecture keeps the two worlds separate and makes the separation visible.

What a supervisory request is

Monitoring alone leaves value on the table. An operations center that can see a unit degrading should be able to ask for something: reduce rate, idle a unit, bring one online, hold. In KNOCE those are supervisory requests, and each one moves through five states:

• Requested — who asked, for what, with the value.
• Validated — the request is checked against the operating envelope: is the spread rate impact acceptable, is there HHP margin, is the unit in a state where the request makes sense.
• Acknowledged — a second person accepts responsibility.
• Executed — at the equipment, by the equipment's own controls.
• Audited — what happened, when, and the outcome, recorded permanently.

Every step is timestamped and attributed. Nothing in the flow bypasses a protective function; the request goes to the same place an operator's hand would.

Why attribution is the product

The value of the flow shows up in the incident review nobody wants to have. When a stage went wrong, the questions are always the same: who asked, who approved, what was the equipment doing, and what happened next. A supervisory command flow answers them from the record instead of from memory. The paper trail exists before anyone asks for it.

Saying what's real

We also think the safety conversation includes being honest about maturity. The KNOCE platform's alarms, work orders, and supervisory flow are available today. AI anomaly detection is in pilot, sharpening on real telemetry with analyst review. Remaining useful life and on-device inference are roadmap. Our Why KNOCE page keeps that table current, because an industrial buyer who finds the distinction in diligence stops believing everything else.

The line between watching and protecting is the most important line in the product. We drew it first.

Here is a number: 8.9 mm/s of vibration on a frac pump's power end. Is that a problem?

You can't answer, and neither can an algorithm, until you know what the pump was doing. At idle, 8.9 is alarming. At 80% of rated hydraulic horsepower, mid-stage, with discharge at 9,800 psi, it may be Tuesday. The same reading is two different facts depending on the operating state — and a monitoring system that doesn't know the state will either miss the real failure or cry wolf until the crew stops reading its alerts.

The sensor sees the machine, not the operation

Standalone machine-health platforms are good at what they do: sensors, large failure libraries, expert-validated diagnostics. But their unit of analysis is the machine in isolation. On a frac spread, the operating context changes every few minutes — rate ramps, stage transitions, units idled and brought online, gensets shedding and picking up load. Vibration, temperature, and pressure all move with it. Strip the context away and every baseline is wrong half the time.

What a finding should carry

In the KNOCE platform a diagnostic finding is not a threshold crossing. It carries:

• The failure mode it points to — fluid-end washout, bearing wear, compressor fouling — named in plain language.
• A confidence score, so an engineer knows whether to act now or watch.
• Cited evidence: which signals moved, by how much, since when, against which baseline.
• The operating state it was seen in — the rate, the load, the stage — because that is what makes the evidence mean something.

The evidence is the part we care most about. A finding that says "bearing wear, 88%" is an opinion. A finding that says "power-end vibration up 2.6× over six hours with a growing 1× running-speed component, bearing temperature 218°F and climbing, lube-oil temperature steady — so it isn't cooling" is a case an engineer can check.

Where remaining useful life fits

Remaining useful life — RUL — is the natural next step: fit the degradation trend and project it to the threshold. It is also the easiest number to oversell. A projection of "120 hours" is really a band, and it moves with load: the bearing that has 120 hours at idle has fewer at full rate. When RUL ships in KNOCE it will carry its uncertainty the same way findings carry their confidence, and it will be computed against operating context, not calendar time. Until then it's on our roadmap, and our Why KNOCE page says so.

The chain that matters

Sensor → machine state → operating context → finding → operator decision → maintenance action → equipment history. Every link in that chain is data the platform already has because it sits in the operation, not beside it. That is the difference between monitoring a machine and connecting machine health to operations — and it is the part a vibration sensor alone can never reproduce.

Every operator has seen the wall of red. A unit trips, forty alarms fire in ten seconds, thirty-eight of them are consequences of the first two, and by the time the board is quiet nobody is sure which alarm was the one that mattered. Do that a few times and the crew learns the only rational response: stop reading.

The industry has known this for decades; the standard is ANSI/ISA-18.2, and it is long. Here is the part of it that we built into the KNOCE platform, in operator terms.

Priorities that mean something

Five tiers — critical, high, medium, low, journal — assigned by consequence, not by how loud the sensor is. A tripped unit is critical. A rising fluid-end vibration is high. A heat-rate deviation on a genset is medium: real, but not this minute. A stage-started event is journal — recorded, never shouted. If everything is critical, nothing is.

Acknowledge with a name

An alarm moves from active-unacknowledged to acknowledged only when a person accepts it, and the record keeps who and when. That sounds bureaucratic until the shift handover, when "did anyone see the bearing temp on PU-12?" has an answer with a name on it.

Shelve, don't silence

Some alarms are true and not actionable right now — lube-oil temperature drifting high on a 105°F afternoon. Silencing it forever is how alarms disappear until they matter. Shelving puts it aside with a timer; it returns on its own. The operator gets a quiet board and the alarm doesn't get lost.

Suppress by state

A unit in maintenance should not generate process alarms; its low discharge pressure is a fact, not a fault. State-based suppression ties alarm behavior to the equipment state, so the flood never starts. This single mechanism removes more nuisance alarms than any threshold tuning.

Cleared is not the same as gone

An alarm that clears before anyone acknowledged it — suction pressure dipped during a rate ramp and recovered — is kept in a distinct state, cleared-unacknowledged, so the transient still gets seen. Transients are how failures introduce themselves.

The point

None of this is exotic. It is discipline encoded so that operators don't have to supply it at 3 a.m. An alarm system earns belief by being right about priority, honest about state, and quiet about things that don't matter — and a crew that believes its alarms is the cheapest reliability improvement a spread can buy.

Ask a frac supervisor what a spread costs to run and you'll hear about people, pumps, sand, and downtime. Ask what it costs to not run — the minutes between stages, the hold while a unit is swapped, the wait for the wireline — and you'll get a shrug. Not because it doesn't cost anything. Because nothing has ever shown the number.

Turbines hate idling

A gas turbine's efficiency is a function of load. Near rated output the heat rate — fuel energy per kilowatt-hour — is at its best. Pull the load off and the heat rate climbs steeply: the machine keeps spinning, keeps burning, and produces almost nothing. Between stages, a turbine genset feeding an idle pump fleet is at the worst point on its own curve. The fuel meter doesn't care that no sand is moving.

Representative arithmetic

The numbers vary by turbine, fuel, and site, so treat these as illustrative rather than a quote. Five gensets idling at roughly 100 gallons per hour each is 500 gallons per hour of unproductive burn. At $3.20 per gallon that is about $1,600 per hour of idle across the spread. An hour of inter-stage time per day — not unusual — is on the order of half a million dollars a year in fuel that moved no fluid. Your numbers will differ; the shape won't.

Why "live" is the whole point

A monthly fuel report tells you idle was expensive last month. A live figure — this spread, right now, $/hr — sits on the same screen as the decision that creates it: hold two more minutes, or bring the unit online now; keep a genset warm, or drop it to idle. When the cost of an idle decision is visible while the decision is being made, the decision changes. That is the difference between accounting and operations.

What the spread overview shows

The KNOCE Frac Operations Platform puts idle fuel burn on the top row of the spread view, beside fleet status, hydraulic output, and genset load — priced per hour, with the gallons behind it. The turbine performance screen goes deeper: heat rate against the ideal curve per genset, so a machine that is idling badly and a machine that is fouling both show up, for different reasons.

It's not the most sophisticated thing on the platform. It may be the most persuasive, because it's the first number a CFO and a pad supervisor read the same way.

There is a graveyard of industrial software pilots, and most of the headstones say the same thing: the plant wouldn't let us touch the PLC. They were right not to. A working control system is the most expensive thing to break in a facility, and "trust our new box" is not an argument that survives contact with the person who gets paged when it fails.

So we built KNOCE to start where the plant already is.

Mode 2 first

Deployed as a smart gateway, the KNO1-PLC sits beside the controls you already run — Siemens, Allen-Bradley, CODESYS — and reads them over OPC-UA or Modbus. Read-only. Your control logic, your safety systems, and your vendor warranties stay exactly as they are; the gateway adds no path into the loop. What it adds is everything above the loop: a fleet view, alarms with discipline, findings with evidence, and work orders that write themselves. Telemetry leaves the site as MQTT Sparkplug B, so a new site is named, typed, and stateful the moment it connects.

What the plant manager hears

"Nothing changes on your control side, and in a week you'll see the whole site on one screen." That sentence closes more deployments than any feature list, because it removes the only objection that matters. The engineering team doesn't have to defend a new controller; they have to plug in a cable.

Mode 1 when a panel comes due

Panels age out. When one does, the same KNO1-PLC becomes the controller: deterministic IEC 61131-3 logic on real-time cores, 76 I/O channels including 20 high-power outputs, in a sealed IP69 unit that mounts at the machine — no PLC, no I/O rack, no cabinet. Same platform, same data, same screens. One fewer thing in the electrical room. Consolidation happens on the plant's replacement schedule, asset by asset, not on a vendor's launch schedule.

Three phases, no cliff

• Phase 1 — Don't touch control. Read what's there.
• Phase 2 — Add the operations layer across everything the gateway can see.
• Phase 3 — Consolidate onto KNO1 when it's the right time for each panel.

The industrial AI that ships is the kind that respects the order of those phases. Everything else is a demo with a headstone.