'Operations Will Figure It Out': The Design Assumption That Creates the Most Expensive Post-Handover Calls

Every spec that leaves an EPC firm contains a decision nobody wrote down: operations will compensate for whatever the design didn't anticipate.

It's never stated that plainly. It lives in the gap between what the influent data described and what the plant will actually see: the spike the characterization window missed, the upset that doesn't show up in a design basis, the condition everyone half-knows is coming but nobody sized for.

The spec handles the average. The assumption handles the rest: someone on the operating floor will notice, intervene, and make it work.

The design choice that puts operations on call

That assumption feels like humility. Engineers can't design for conditions they were never given data on, so they design for what they have and trust the plant to absorb the difference. That’s reasonable, in the moment. But trusting operations to absorb the difference is not the absence of a design decision. It is the design decision.

The spec chose to put a person in the loop for the worst conditions the site produces. It just chose it silently, and it chose it for someone who never got a vote.

Silent decisions get discovered, not reviewed

Here's why that matters more than it looks. A decision made explicitly gets reviewed, priced, and owned. A decision made silently gets discovered, usually months post-handover, usually by the operator standing next to a filter that needs a hand every time solids climb.

Same choice with radically different consequences, depending only on whether anyone said it out loud during design.

The call lands on your engineer

When operations has to intervene on a regular basis, their unhappiness doesn't stay on the floor. It travels. The plant manager asks why the technology needs babysitting. The question then climbs back up the chain to the firm that specified it, and lands on the process engineer whose name is on the design basis.

The unmade decision has now become that engineer's problem: a callback about a condition that was foreseeable, that could have been priced into the spec, that instead got quietly assigned to a operations manager on the night shift.

The tell is a missing sentence

The sign that you're relying on this assumption is a specific kind of silence in the documentation.

Nowhere does the spec say what happens when real conditions exceed the characterized ones. Nowhere does it define whether the system holds performance on its own or needs an operator to carry it through.

The absence isn't an oversight. It's the assumption, doing its work invisibly, right up until the day it surfaces as a phone call.

Make the decision on purpose

None of this argues for overdesign or for pretending you have data you don't. It argues for something smaller and harder: making the decision on purpose.

If the design puts a person in the loop for spike conditions, that's a legitimate choice, but it's a choice the client should see, price, and agree to before handover, not inherit by surprise after it. Write the assumption down. Put it in the design basis. Let it be reviewed like every other line item, because it is one.

The most expensive assumptions in any spec are the ones nobody decided to make. Before the next design basis leaves your desk, find the sentence you've been leaving out, the one about what happens when reality exceeds the data, and write it in. A decision you can see is a decision you can defend.