Part 2: The Clean Loop Series - How to Prove the Loop Is Ready for Compute

Start with the release question

The question is not, did we fill the loop? Filling a loop only proves that liquid entered the system.

The better question is, would you connect expensive AI hardware to this loop and defend that decision later?

Pre-commissioning guidance describes the practical sequence: hydrotest, clean, flush, prepare for commissioning, document the work, and prove performance.

The operator version is shorter: release the loop because the evidence says it is ready, not because the schedule says it is time.

The proof chain

The best release record should answer five questions without a meeting: what was cleaned, what was caught, what was sampled, what was measured, and what normal looked like on day one.

A useful proof chain is simple. The flush plan says what should have happened. The filter record says what the loop caught.

The sample record says what was left in the fluid. The pressure and flow record says whether the hydraulic path is behaving.

The baseline says what normal looked like before production load made every problem harder to explain.

That paper trail matters later. If one piece is missing, the team may still operate, but it loses confidence.

A future alarm becomes harder to sort out: workload, facility water, pump control, chemistry, trapped air, or debris that should have been caught during commissioning.

What to capture during flushing

• System configuration: rows, manifolds, bypasses, filters, temporary skids, and any sections isolated from the flush.
• Flush conditions: flow rate, pump speed, temperature, direction, duration, and whether all branches saw useful flow.
• Filter history: installed micron rating, changeout times, filter pressure drop, and visible filter loading.
• Water and waste handling: source water quality, cleaning chemistry, flush water disposal, and final rinse condition.
• Sample chain: sample point, date, loop identity, fluid identity, test method, and retained records.

Those details prove that the loop was circulated with intent.

A loop can be filled without being cleaned, just like a bottle can be filled with water while dirt still sits in the corners. The record is how you tell the difference.

What to test before compute load

Think of pre-load testing like a medical check before a marathon. You do not only ask whether the runner looks healthy.

You check the vital signs that prove the body is ready for stress.

Water-based transfer-fluid guidance recommends routine monitoring for conductivity, pH, bacteria, inhibitor levels, water appearance, and filter loading.

It also lists lab checks such as total suspended solids, total dissolved solids, corrosion byproducts, metals, and turbidity.

Those are not just chemistry details. They are operating evidence. Conductivity can show ionic drift.

Turbidity and suspended solids can show material still moving. Metals can show corrosion byproducts.

Filter pressure drop can show whether the loop is still shedding particles into the filter.

For a cold-plate system, the hydraulic side matters too. Cold-plate guidance ties thermal performance to fluid temperature, applied power, flow rate, and pressure drop.

A clean-loop release should capture both the chemistry and the hydraulic fingerprint.

The baseline is the handoff

This is the moment teams are tempted to rush. Construction wants to close. Commissioning wants to move. IT wants hardware.

But this is exactly when the loop needs its first clean fingerprint.

A useful day-one baseline should include supply and return temperature, rack or branch flow, pump command, differential pressure, filter pressure drop,

chemistry results, sample dates, leak status, and workload context if any load is already present. The goal is not to promise the loop will never drift.

The goal is to know what it looked like before drift began.

That baseline is the before photo. Without it, the team is trying to judge future change without knowing what the healthy system looked like on day one.

A simple release logic

This is not meant to replace the site procedure. It is a simple way to separate a real release decision from wishful thinking.

• Release when flush records are complete, filters stabilize after circulation, representative samples are acceptable, pressure and flow behavior are explainable, and the baseline is saved.
• Hold when filter pressure drop keeps rising, samples are unclear, branches do not balance, air removal is incomplete, or records do not prove all sections saw flow.
• Escalate when debris keeps appearing after filter changes, metal byproducts trend upward, pressure is unstable at the same flow, or any cold-plate branch shows unexplained restriction.

The important word is unexplained. A commissioning record will not prevent every future issue.

It gives the team a way to separate normal startup behavior from a loop that is already trying to tell them something.

What this really buys

Teams do not document a clean loop because paperwork is exciting.

They do it because the first cooling problem after go-live should not turn into an argument about what happened before the rack was powered.

The real win is fewer mysteries.

When a branch warms up, a filter loads, or a pump starts working harder, the team can compare against a known clean starting point instead of reconstructing the past from memory.

A clean-loop proof package moves risk from memory to evidence. It gives operators a starting point, gives facilities a record, gives vendors a cleaner handoff,

and gives customers a better chance that cooling stays invisible while compute does the visible work.

Read Part 1 first if you want the origin story: The Hidden Risk Inside a New Cooling Loop.

References

• OCP Guidelines for Pre-Commission Preparation of Technology Cooling System Row Manifolds in Liquid Cooled Data Centers
• OCP Guidelines for Using Water-Based Transfer Fluids in Single-Phase Cold Plate-Based Liquid-Cooled Racks
• OCP Cold Plate Development and Qualification with Integrated Comments
• ASHRAE TC 9.9 Water-Cooled Servers: Common Designs, Components, and Processes