When facility data is incomplete: designing useful partial answers
Chapter 2 of 4 · Designing a data-center capacity calculator
A facility calculator may receive only part of the information it asks for. The product decision is how to make that partial information useful while showing what the calculation leaves out.
The PhysaFlow implementation provides a useful example. Its result structure can carry calculated values alongside missing-data messages, warnings, and excluded constraints. This allows the model to explain both what it can calculate and what remains unresolved.
Preserve the answers the inputs support
If the input passes schema validation and at least one valid capacity constraint is supplied, the calculator can identify a usable IT capacity based on the available constraints. If measured IT load is absent, it retains that capacity value but stops before calculating utilization or unused capacity.
A second boundary appears when the cooling architecture is unknown or outside the recognized scenarios. The calculator can retain usable and unused capacity, while withholding modeled stranded capacity.
This supports a practical interface principle: show the supported answer with its qualification, then explain which input unlocks the next answer. The available files establish the result behavior; they do not show how the current screen renders those states.
Distinguish missing information from conflicting information
A missing measured load calls for another input. A measured load greater than modeled usable capacity calls for verification. Those situations deserve different explanations.
The implementation also rejects reliability headroom that equals or exceeds gross deliverable power, and requires the reporting period to end after it begins. A PUE above 3 triggers a warning to verify the measurement rather than an automatic rejection.
These rules make validation part of the product's explanation. The next action should be understandable: supply a missing value, check a boundary, or confirm an unusual measurement.
Keep excluded constraints close to the result
Taking the minimum of known constraints does not prove that an omitted constraint would be higher. A capacity estimate calculated without cooling-supported capacity needs that omission attached to its interpretation.
The presentation helper includes supplied inputs, reporting dates, excluded constraints, errors, and warnings in a data-coverage summary. This creates a mechanism for carrying context with the numbers.
For the interface, the opportunity is to make that context easy to inspect without forcing every reader through every detail at once. Whether that presentation works needs to be checked against the actual interface and user feedback. The code provides the foundation: partial answers and their limits can travel together.
This chapter is part of the PhysaFlow calculator series overview. The PhysaFlow case study explains the surrounding positioning and product work. Continue the reasoning with keeping excluded constraints and model assumptions visible.