Designing for Steady-State: The Specification Assumption That Gets Engineers Called Back

Every steady-state filtration spec carries the same flaw: the influent data behind it was never meant to describe the plant’s worst day.

That’s not a knock on the data. A few weeks of grab samples, maybe a full season if the budget allowed it, averaged into a single total suspended solids (TSS) number for the design basis; that’s what everyone works with. Nobody hands an EPC a year of hourly readings from a really challenging month of operations. Averaged data is what’s available. It’s also all that’s available, for every engineer specifying pre-treatment right now.

The problem isn’t the averaging. It’s what the spec does once that number lands on the page.

Standard practice sizes to the average, layers on a safety factor, and calls it conservative. That reads like diligence in a design review. What it actually does is dismiss every condition the average absorbed — the spring runoff, the process upset, the six hours where a production ramp doubles suspended solids loading. It passes those conditions to whoever is running the plant. So why the filtration system passes acceptance testing, but it doesn’t pass muster on those above-average days.

Those are the days that produce the call-back, the one that tails an engineer after the project is done. Eighteen months post-handover, the client wants to know why the filtration package needs a person standing next to it every time TSS spikes. The honest answer, if anyone gave it, is that the system was never designed not to need one. The worst-case condition wasn’t a design input. It was an operational problem from the day the spec got signed; nobody acknowledged it at the time.

Safety factor doesn’t fix this. It moves the threshold. A filter sized at 150% of the design spec handles a bigger spike before it loads out, but it loads out the same way, requires the same intervention, generates the same call, once the spike is big enough. More capacity for average conditions is not the same as a different response to variable ones.

A different question

The question that produces a defensible spec isn’t “what does our influent data show?” It’s “what happens when real conditions are worse than what we characterized, and does the system need a person for that?” Those two questions produce different specs. One gets validated by acceptance testing on a good day. The other has to be validated by performance data from an extreme day.

That’s the line item most pre-treatment specs skip: documented performance at TSS loading above the design average, from an operating site, not a test loop. Ask for it before you finalize sizing. If the vendor can’t produce it, you’re specifying against the same averaged snapshot everyone else works from, and you already know where that leads.

Specifying for variability isn’t overbuilding. It’s finishing a design that got left half-done at the averaging step.

Most specs never get tested against the extreme day that exposes that gap. The specs that do get tested end up with a phone call — and an uncomfortable discussion.