An emissions figure with three decimal places creates the impression of precision. But precision says nothing about reliability. A number can be calculated down to the decimal and still be based on the wrong unit, an expired conversion factor, or an estimate someone entered years ago that has never been checked since. That is false precision: a figure that looks more exact than it actually is.
This does not happen because people are careless. It happens because a report is the last step in a long chain, and by the end of that chain it is no longer visible what happened along the way. A spreadsheet with three decimal places looks the same whether the source value was a measured figure or a wild guess. Without rules that define what counts as a valid value, that difference remains invisible.
Every data point has boundaries within which a value is plausible. Energy consumption per site cannot be negative. An emission factor does not change by a factor of ten every quarter. A headcount does not deviate by thousands from the previous month without an identifiable reason. These are not complicated statistical models, they are simple, definable boundaries per data point.
The question of what counts as a valid value cannot be answered the same way everywhere. What counts as an acceptable range for one data point is too wide or too narrow for another. That choice belongs to the data point itself, just like the question what a valid value is and who notices when it goes wrong. Without making that choice explicit, every incoming value is silently treated as correct, even when it isn't.
Beyond a hard boundary there is a second layer: deviations that are not invalid, but are still notable. A value that falls within the permitted range but deviates strongly from the pattern of previous periods is not wrong, but it is a signal that someone should look at.
The difference between a hard rejection and a signal is a deliberate choice. A valid-value check blocks; a signal draws attention without blocking. Both are needed, and both should be defined at the level of the data point, with the question how you set a signal deviation and who notices when it happens as the starting point. Without that definition, it remains a matter of chance who notices an unusual value, and when.
A rule without a recipient is a rule nobody reads. If a value falls outside the boundary or triggers a signal, it must be established who gets to see that: the person entering the data, the data owner, the controller who processes the figure further. Without that step, a deviation disappears into a log file that nobody consults, and a flagged error turns into an unnoticed error.
This is also where many control mechanisms stall in practice. A rule is set up, but no one is assigned to respond to it. The rule exists, the alert appears, and nothing happens. Which controls belong to a data point and who sees them is connected to the broader overview of which controls belong to a data point and who notices when something goes wrong. A control that nobody sees is, in practice, no control at all.
There are systems that automatically detect deviations and send alerts. Those systems are useful, but they solve nothing if the underlying questions have not been answered: what counts as a valid value for this specific data point, what counts as a signal, and who is the designated recipient. A tool running on rules nobody has thought through produces alerts nobody takes seriously, or warnings that get structurally ignored. The result resembles control, but it isn't.
That is why these questions must first be answered at the level of the data point, before a system can execute them. The rule belongs to the data point, not to the software that happens to monitor it.
False precision often arises in combination with another problem: parts of the organization defining a data point differently. If one site counts square meters of office space and another does not, a plausibility check on values is not enough, because the values are not comparable to begin with. What you do about definitions that differ per unit and how that relates to the check on valid values is described on the page about diverging definitions and the corresponding control question. Anyone who sets up quality rules without first examining this definition issue may end up checking plausible values that are, in fact, not comparable to one another.
This scan maps out, per data point, what counts as a valid value, what counts as a signal, and who the designated recipient is. That overview is not the end point, but the starting point: it establishes where no rule currently exists, where a rule exists without a recipient, and where the definition of a data point itself already causes confusion between units. Once that picture is in place, it becomes clear which controls carry the most weight and where attention should go first.
Once that overview is in place, another question can be answered: which part of the work that is currently still done manually can, after this classification, be transferred to an automated process. That is what the work scan from FTE TO AI is for: it calculates, per task, which part of the work can be taken over by AI, not as a replacement for the quality rules established here, but as a follow-up step on the overview that this creates.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.