On the shop floor, the alarm is often too late, too frequent, or too vague. A limit is exceeded — and then the system reacts. By then, drift may have been visible for a while. Or the alarm fires dozens of times a day without clarity on what truly matters.

That is not only a UX issue. It is a detection question: what counts as “normal” for this one machine — and when has something actually changed?

Classic monitoring defines normality through fixed thresholds: temperature above X, pressure below Y, cycle time outside range. That works for stable processes. In real operation, material, tools, and operating states change. What was normal yesterday is a different context today — and the threshold either reports nothing or everything.

Copass takes a different path: instead of global limits, the cognitive engine captures how this machine typically runs in comparable context. Signals are not judged in isolation but placed in operating state — maintenance, material change, normal run, startup.

Recurring situations become experiences. From experiences, machine-specific patterns emerge. When something shifts, Copass does not compare against a fixed limit but against what this machine has already shown under similar conditions.

The result is not a binary alarm decision. Copass classifies deviation: harmless, worth watching, or action needed. Operators and technicians get context — not just “alarm yes or no”.

Material changes and maintenance are not faults but explainable shifts. Copass separates drift from expected changeover. That can reduce false alarms and surface real shifts earlier.

This also differs from generic anomaly scores. Copass does not deliver an opaque number nobody can explain on shift. Guidance is traceable: what changed? in which context? why does it matter?

Important: this is not the same as Copass’s notification slider. The slider sets how much Copass reports per machine — from full updates to errors only. This research focus is detection itself: whether and why something counts as change before the classic control or monitoring alarm fires.

Early results from internal tests and lab scenarios show change becoming visible while the machine is in simulated normal operation — not only when downtime looms or an alarm flood filter kicks in.

For us, that is core to the industrial cognitive engine: understanding instead of thresholds. Not more data on the dashboard, but a system that knows this machine — and informs people in time.