Methodology
How CalcBrand calculators are specified, implemented and checked.
How a calculator is built
Each calculator is one declarative specification: its inputs, a pure function implementing the formula, the formula itself written out in plain notation, a worked example and its FAQs. The interface never touches the maths directly — it reads the same specification a reader sees, so the displayed formula and the code that runs cannot silently drift apart.
How a worked example is checked
A worked example is not prose describing what the calculator should do — it is a set of real input values, run through the calculator’s own compute function, and checked automatically against the figures the example quotes. If a formula changes and the example no longer matches, that failure blocks the change rather than shipping quietly.
Automated correctness checks
Every calculator runs through the same battery of checks: that every declared input is actually read by the calculation, that every declared bound (a minimum, a maximum) is one the calculation genuinely enforces, that no combination of realistic inputs produces a crash or a nonsensical output, and that instructions never reference a field the calculator does not have. These run across the whole catalogue on every change, not as a one-off review.
Where a formula has more than one accepted version
BMR equations, one-rep-max estimates and ideal-weight formulas are real examples: more than one respected version exists, and they disagree. Rather than pick one silently, the calculator shows the ones in common use side by side, named, so the reader can compare rather than trust an unstated choice.
What this cannot check
Automated checks confirm a calculator is internally consistent — the code, the formula shown, and the worked example all agree, and the inputs behave as declared. They cannot confirm that a formula is the right one for every jurisdiction or edition, which is what the sources policy and each calculator’s own assumptions and limitations exist to address.