Kennisbank

Setting a signal deviation on a data point: what you record and who sees it

A signal deviation — sometimes called a validation rule or threshold value — is a rule that has a system check whether an entered value falls within an expected range. It sounds technical, but the question behind it is simple: what is a valid value for this data point, and what happens if that value falls outside it. Without an answer to those two questions, a signal deviation is a setting without a function.

What a signal deviation actually records

A signal deviation consists of three parts. First, a boundary: a minimum, a maximum, or an expected ratio between two data points, such as energy consumption per square metre that should not deviate by a factor of ten from last year. Second, an action: what the system does when that boundary is exceeded — a notification, a block, or nothing. Third, a recipient: who sees that notification, and whether that person knows what is expected of them when they see it.

Most organisations that start with signal deviations focus on the first part and forget the third. A threshold value is set, the system generates a notification, and that notification disappears into the inbox of someone who no longer works at the organisation or does not know that this falls within their responsibilities. The rule exists, but no one notices when it triggers.

What counts as a valid value differs per data point

The boundary you set depends on the data point itself and on what you already know about it. For some data points, a valid value is easy to determine: a percentage cannot exceed a hundred, a quantity of waste cannot be negative. For other data points, the boundary is less fixed and more a matter of experience: a CO2 emission per site that is three times as high this year as last year is not necessarily incorrect, but it is worth reviewing before the figure moves on. What exactly counts as a valid value for a given data point is described on the page what is a valid value, which distinguishes between hard boundaries and flagging based on deviation.

That distinction matters because it determines what the action should be. A hard boundary — a percentage above a hundred — can block an entry. Flagging based on deviation — an emission figure that stands out but is not necessarily wrong — cannot be a block, because that would incorrectly stop correct but unusual values. Here a notification belongs to a person who can assess whether the deviation is an error or a real change.

Who sees the notification is a question of ownership

The third question — who sees it when something goes wrong — is not a technical setting but a question of ownership. A signal deviation without an assigned recipient does not function, even if the rule is set up correctly. This touches on the question of which checks belong to a data point and who is informed of them, a topic elaborated further on the page which checks belong to a data point and who notices it.

In practice, the recipient is often the person who supplied the data point, but that is not always the right choice. The person who supplied the figure is not automatically the one who can assess whether a deviation is correct — that often requires someone with knowledge of the underlying source or of comparable figures from previous years. Who can make that assessment differs per organisation and per data point, which is precisely why ownership per data point must be recorded rather than assumed.

The pitfall: setting up a signal without a process behind it

A setting for a signal deviation is quickly made in a system. The temptation is therefore great to think that the problem has thereby been solved. But a tool that flags without a recorded process behind it — who receives the notification, what they must do, within what timeframe — only gives the appearance of control. This is the same pitfall described on the page buy a tool first or set up the process first: a system placed on top of a disorganised process generates notifications that no one follows up on, which looks even calmer on a report than no notifications at all, but in practice changes nothing about the reliability of the underlying figure.

A signal deviation is therefore only meaningful once the three parts have been assigned together: a boundary that fits the data point, an action that fits the type of deviation, and a recipient who knows what they are expected to do. That is not a setting you finish in an hour for a hundred data points. It is a choice made per data point, based on what is already known about the source and the history of the figure.

Whether a task such as assessing a flagged deviation is suitable for automation, or whether that assessment remains work for a person, is a question that differs per task. The [work scan](https://fte-to-ai.nl) from FTE TO AI calculates per task which part of the work can be taken over by AI, and which part still requires assessment from someone who knows the context of the data point.