Death by Exception: What's Wrong with How FlowCal Exceptions Get Created
FlowCal's exception system is one of the most powerful tools in natural gas measurement, and one of the most quietly broken. Here's why false positives are costing your analysts more than you think.
Every measurement analyst knows the feeling. You open FlowCal on a Monday morning, and the exception queue is already stacked. You start working through them. This one’s real, that one’s not, this one’s been a recurring false positive for three months. By mid-morning you’ve cleared a column of exceptions and produced exactly zero actual fixes.
That’s not an analyst productivity problem. That’s an exception design problem.
How FlowCal Exception Limits Get Created
FlowCal’s exception engine is built around the idea that every flowing variable (volume, differential pressure, static pressure, temperature, flow rate) should operate within defined limits. When a value falls outside those limits, the system generates an exception for an analyst to review.
In theory, this is exactly right. In practice, the limits themselves are the problem.
Most exception limits in FlowCal are created one of a few ways: carried over from a legacy system during implementation, set manually by an engineer based on general rules of thumb, or copied from a neighboring meter that behaves similarly. Once set, they’re rarely revisited, because revisiting hundreds of meter setpoints manually is its own full-time job.
The result is limits that don’t reflect what a meter actually does. A meter in the Permian that runs hard in summer and backs off in winter needs different limits in July than it does in January. A meter that just had equipment replaced will behave differently than its historical range suggests. Static limits applied to dynamic measurement data will generate false positives. That’s not a bug. It’s physics.
What a False Positive Actually Costs
Here’s where the math gets uncomfortable.
When an analyst receives an exception, the investigation process is roughly the same regardless of whether the exception is real or not:
- Navigate to the meter in FlowCal
- Pull the relevant time series data
- Evaluate whether the deviation is outside normal operating behavior or a genuine measurement issue
- If real: initiate a correction workflow
- If false positive: close and document it, and suppress it if the limit allows
That process takes somewhere between 5 and 15 minutes per exception, depending on meter complexity, data availability, and whether the analyst has reviewed this particular meter recently. Call it 10 minutes as a reasonable middle estimate.
Now consider a measurement team managing 500 meters with poorly-calibrated exception limits. If each meter generates even five false positive exceptions per month (a conservative estimate for a pipeline system with legacy or generic setpoints) that’s 2,500 false exceptions per month. At 10 minutes each, you’re looking at 417 analyst hours spent on work that produces no measurement correction and no revenue recovery.
That’s more than two full-time employees, working an entire month, generating nothing.
The Deeper Problem: Exception Fatigue
The math above assumes analysts investigate every exception thoroughly. They don’t, and they shouldn’t be blamed for it.
When an analyst has seen the same false positive from the same meter seventeen times, their brain stops treating it as a signal. They close it faster. They look at it less carefully. And then, eventually, that meter generates a real exception that looks just like all the false ones, and it gets closed in 30 seconds because the pattern-matching is already established.
This is exception fatigue, and it’s the actual reason poorly-set limits are dangerous. It’s not just wasted time. It’s degraded signal quality. The more noise in your exception queue, the harder it becomes for real issues to surface.
An analyst who trusts their exception queue will investigate carefully. An analyst who doesn’t will triage quickly. The difference shows up in PPAs, in missed freezes, in billing disputes, and in audit findings.
Why the Standard Fix Doesn’t Work
The standard answer to exception fatigue is to raise the limits, making them wider so fewer exceptions fire. This works in the short term and creates a different version of the same problem: limits that are so wide they only catch catastrophic deviations, not the subtle drift and anomalous patterns that indicate a real measurement issue developing.
You can’t solve a calibration problem by making the instrument less sensitive. You end up toggling between too many false positives and too few true positives, without a principled way to find the right threshold.
What Good Exception Limits Look Like
Effective exception limits for natural gas measurement have a few characteristics that generic or manually-set limits typically lack:
They’re statistically derived from the meter’s own data. A limit that reflects the actual distribution of a variable at a specific meter, accounting for seasonal variation, equipment characteristics, and normal operating range, will generate far fewer false positives than a limit based on an industry rule of thumb.
They’re specific to the variable and measurement type. Volume exceptions and differential pressure exceptions don’t behave the same way and shouldn’t share a limit-setting methodology. Hourly and daily variables need different treatment.
They’re reviewed and updated as meter behavior changes. Equipment ages, conditions change, and operators adjust. Limits that were accurate eighteen months ago may be generating false positives today for reasons that have nothing to do with actual measurement problems.
They can distinguish nuisance exceptions from actionable ones. The goal isn’t fewer exceptions. It’s a higher signal-to-noise ratio. An analyst should be able to trust that every exception they open is worth opening.
The Cost of Inaction
The measurement industry has largely accepted exception fatigue as a cost of doing business. It shows up in analyst overtime during high-exception periods, in the quiet understanding that some exceptions never really get looked at, and in the post-period adjustments that result when real issues were in the queue but didn’t get prioritized.
What’s changed is that the technology now exists to set exception limits the right way, using the same kind of statistical and machine learning methods that handle this kind of problem in every other data-intensive field. The gap between what’s possible and what most measurement teams are doing is wide, and it’s getting wider.
Your analysts’ time is not infinite. Your exception queue should respect that.
NDL (Meter Setpoints) uses advanced unsupervised machine learning to derive statistically precise exception limits from your meter’s own data, reducing false positives, eliminating nuisance exceptions, and restoring trust in your exception queue. Schedule a demo to see how it works with your FlowCal setup.
Schedule your demo