‘Based on Available Data’: The Four Words That Should Make Engineers Nervous

"Based on available data." That phrase appears in EPC project documentation more often than almost any other hedging construction. It is technically accurate. It is professionally safe. And for anyone who has read enough post-handover performance reviews, it is a warning sign.

What the phrase is concealing

"Based on available data" is a four-word acknowledgment that the design was built on a characterization window that does not represent the full operating envelope.

The data that was available was collected over a limited period. It captured the influent under the conditions that existed during sampling. It did not capture the production ramp-up in Q4. It did not capture the precipitation events that arrive twice a year and change the TSS load by a factor of five. It did not capture the process upset that sent a slug through the system on a Tuesday afternoon eight months after commissioning.

The system was designed for what the data showed. Reality is what the data missed.

Where this shows up in performance

Not every "based on available data" specification produces a post-handover problem. When the variability in the actual operating conditions turns out to be modest, the conservatively sized system handles it and nobody notices the gap.

When the variability is significant — which it is, in most industrial water treatment applications — the phrase "based on available data" marks the location of the design failure before the system is built.

Filtration equipment specified for average conditions fails during TSS spike events. Those events are not anomalies. In high-solids industrial environments, they are the operating conditions that define whether the system actually works.

The design question that replaces the hedge

The alternative to specifying based on available data is specifying for the conditions the available data did not capture. That means asking a different question:

Instead of What does the average influent look like? ask What does the upper bound of expected influent look like, and does the system I am specifying maintain acceptable performance at that boundary without manual intervention?

For filtration, that upper-bound question should then spur three additional questions:

• What is the highest TSS loading this application will produce during a realistic worst-case event?

• Does the system I am specifying maintain continuous filtrate output at that loading without alarming or requiring operator response?

• If the vendor's performance data does not answer this question, what data am I accepting on behalf of the system's future operators?

"Based on available data" is a professionally defensible phrase. It is also a phrase that transfers the risk of the data's limitations to the operations team that will run the system.

The design case should include the conditions outside the available data. That is what the available data cannot do.