Making assumptions visible: designing trust into a calculator
Chapter 4 of 4 · Designing a data-center capacity calculator
A result can look exact while relying on incomplete measurements and scenario assumptions. Designing a useful calculator means making those distinctions readable wherever the result appears.
The PhysaFlow files contain several mechanisms for doing this: explicit result labels, data-coverage reporting, illustrative inputs separated from user defaults, and an unavailable benchmark state. Together, they provide a concrete story about communicating the limits of a model.
Put the qualification in the label
The presentation helper uses labels such as “Modeled stranded capacity,” “Annual revenue opportunity proxy,” and “Potentially recoverable capacity.” These terms help identify what kind of claim each number represents.
The surrounding explanation still matters. Formatting an estimate to two decimal places is a display choice; it does not establish accuracy to that precision. A revenue range reflects supplied valuation endpoints, not a statistical confidence interval.
Let the assumptions accompany the answer
The data-coverage summary records supplied facility inputs, reporting boundaries, cooling coefficients, valuation context, and relevant GPU scope. It also includes excluded constraints, errors, and warnings.
The result can therefore carry the information needed to question it: which limits were evaluated, which were missing, and which scenario was used. The reporting period uses UTC dates with an exclusive end boundary, making the time basis explicit for GPU-hour equivalents.
Tier and DCIM fields are accepted by the schema, but the current calculation applies no adjustment for them. The explanatory text discloses that behavior. An interface should make clear when a collected field is contextual rather than a driver of the result.
Allow “unavailable” to be a complete answer
The benchmark function returns an unavailable state because this version defines no operational comparison bands. Its test checks that retired bands are not presented as current benchmarks.
That is a meaningful product choice. Without a supported comparison framework, a percentile or performance grade would introduce an additional claim the model cannot substantiate.
The illustrative facility inputs are also explicitly marked as examples, never defaults for a user's facility. Keeping demonstration data separate from facility data reduces ambiguity about whose numbers are being evaluated.
Evaluate the explanation as part of the product
The supplied files show implementation decisions, not user-study results. A useful next evaluation would ask whether readers can distinguish measured load, modeled stranded capacity, assumed recovery, and financial proxies—and identify what information they need before acting.
That is the broader lesson of the series: a calculator's explanation is part of its functionality. A useful result gives someone a number, its basis, and a clear reason to investigate further.
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 separating financial opportunity from recovery assumptions.