A calculated tag is only as trustworthy as the inputs it is built from, and quality propagation is the rule that carries the trustworthiness of those inputs into the result. When one input to a formula goes bad or stale, the output cannot be considered fully good just because the arithmetic still produced a number. This guide explains how the quality flag of source tags should flow into calculated and aggregated points, why the usual rule is that the worst input wins, and why a calculation engine that ignores input quality quietly manufactures results that look solid but are not.
Quality Propagation in one line: Quality propagation is the practice of carrying the quality of a calculation's input tags into its output, so a derived value reflects the trustworthiness of what it was computed from. The common rule is worst-input-wins: if any input is bad or uncertain, the result inherits that lower quality rather than being reported as good. It matters because a calc engine that ignores input quality produces derived values that look valid even when their inputs were broken.
A calculated tag is a value computed from other tags: a total flow summed from several meters, an efficiency derived from a temperature and a pressure, a rolling average of a level. The arithmetic will happily produce an output as long as it has numbers to work with, regardless of whether those numbers are meaningful. Quality propagation exists because the correctness of that output depends entirely on the correctness of its inputs, and there needs to be a way to carry that dependency through the calculation so the result honestly reflects how much it can be trusted.
The intuition is straightforward: a result cannot be more trustworthy than the least trustworthy thing it was built from. If a total is summed from four meters and one of those meters has failed, the total is wrong, even though it is still a number, and it would be a lie to report it as good. Quality propagation encodes this by having the output inherit a quality that reflects its worst input, so that a consumer of the calculated tag sees the same doubt about the result that applies to the input that undermined it.
This is what separates a quality-aware calculation from a naive one. A naive calc engine reads only the values of its inputs, computes, and emits a result with no quality at all, or with a blanket good quality, discarding everything the inputs knew about their own reliability. A quality-aware engine reads both the value and the quality of each input, does the math on the values, and separately derives the quality of the output from the qualities of the inputs. The second approach produces a derived tag that carries an honest verdict about itself; the first produces one that always looks fine.
The most widely used propagation rule is worst-input-wins, sometimes called a quality rollup. Under this rule the output takes on the lowest quality among its inputs: if every input is good, the result is good; if any input is uncertain, the result is at best uncertain; and if any input is bad, the result is bad. It is a conservative rule by design, on the principle that a single broken input is enough to compromise the whole calculation, so the safe default is to let the worst case dominate rather than optimistically averaging it away.
What happens when an input goes bad or stale depends on the calculation and on how the engine is configured. For a simple formula where every input is essential, worst-input-wins is usually right: lose one input and the result is untrustworthy. But some aggregates can tolerate missing inputs; a total across many meters might still be meaningful, if incomplete, when one meter drops out, so an engine may support masking or excluding a bad input and marking the result uncertain rather than bad, to signal that it was computed from partial data. The key is that the degradation is always reflected in the output's quality, never hidden.
Stale inputs deserve particular care because they are the sneaky case. An input that has stopped updating may still hold a plausible-looking last value, so the arithmetic proceeds normally and the output looks perfectly reasonable, while in truth it is being computed from data that is no longer current. Proper quality propagation catches this because the stale input carries an uncertain or bad quality that flows into the result, flagging the derived value as suspect even though its number looks fine. Without propagation, the calculation silently keeps producing confident-looking outputs from frozen inputs long after they stopped being real.
The danger of a calc engine that ignores input quality is that its failures are invisible. Because the arithmetic always succeeds as long as it has numbers, the derived tag keeps emitting confident, good-looking values no matter what has gone wrong upstream. An operator watching a calculated efficiency or a computed total sees a smooth, plausible number and has no reason to suspect that one of its inputs failed an hour ago and the result has been fiction ever since. The absence of any quality signal is precisely what makes it dangerous: nothing looks wrong.
This matters most exactly where calculated tags are relied on for decisions. Derived points frequently feed dashboards, drive alarms, and roll up into reports and totals used for operational and even commercial purposes. A quality-blind calculation that keeps returning a plausible number from a broken input can trip or suppress an alarm on false data, or push a wrong figure into a report that someone downstream trusts. Because the number looks normal, the error can persist unnoticed until it is caught by some external cross-check, by which time bad derived values are already baked into the record.
For a cloud SCADA platform such as Merobix, quality-aware calculation is what keeps derived values honest across every industry it serves. When an input to a calculated tag goes bad or stale, that condition propagates into the output so the derived value is visibly flagged rather than silently trusted, and that flag follows it onto dashboards, into alarm logic, and into the historian. The result is that a calculated number is only ever presented as good when the data behind it genuinely is, so operators can trust a healthy-looking derived tag precisely because the system would have told them if its inputs were not.
It means a calculated value inherits the lowest quality among all of its inputs. If every input is good the result is good, but if any input is uncertain or bad the result is degraded to match, because a single compromised input can undermine the whole calculation. It is a deliberately conservative rule that keeps a derived value from looking more trustworthy than the least trustworthy thing it was built from.
In a quality-aware engine, the bad quality propagates into the output so the derived value is flagged as untrustworthy even though the arithmetic still produced a number. For simple formulas the result is typically marked bad, while some aggregates may exclude the failed input and mark the result uncertain to show it was computed from partial data. The important part is that the output's quality always reflects the problem rather than hiding it.
Because it produces derived values that always look good, no matter what has failed upstream. The arithmetic succeeds as long as it has numbers, so a stale or broken input yields a smooth, plausible output with no warning, and that false value can feed dashboards, trip or suppress alarms, and land in reports. Ignoring input quality means the calculation confidently reports fiction, and nothing on the surface reveals that anything is wrong.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.