How we make sure the numbers are right

Our apps produce figures people build from. Here is the discipline behind them: one archived source document, every constant carrying its paragraph reference, hand-derived test cases, and a "not covered" verdict where the answer is not known.

✍️ Article🧭 About Plan CD Updated 10 September 2026 6 min read

Someone will cut a vent, lay a hearth or size a soakaway from a number one of our apps produced. A building control officer or a HETAS installer may be shown the verdict. An under-ventilated stove puts carbon monoxide in a living room; an undersized hearth is a fire risk; a legionella reading marked “pass” that should have been “fail” is a gap in someone’s evidence.

So a wrong number in one of these apps is not a bug. It is a defect in a real building. This is the process we use to keep them right, written down so you can judge it.

One archived document, not the internet

Every regulatory app in the range is built against a specific published document, downloaded once, checked, and archived in the repository alongside the code. Stove Toolkit is built on Approved Document J, the 2010 edition incorporating the 2010, 2013 and 2022 amendments, England. Stair Calculator uses Approved Document K, 2013 edition. Legionella Logger uses HSG274 Part 2 and the Approved Code of Practice L8.

The archived copy matters more than it sounds. Guidance gets amended, PDFs get replaced at the same URL, and a figure that was right in 2019 may not be right now. Pinning an exact edition means every number in the app can be traced to a document we can still open, and when a new edition lands we can diff our figures against it rather than guess what changed.

The source file that holds those constants carries a header recording the document title, edition, amendment state, source URL and the date each figure was verified. No constant is added without it.

Every figure carries its citation, in the code

This is the part that makes the difference in practice. The constants are not bare numbers with a comment. The citation is data, attached to the value, and it travels with it all the way to the screen:

/// Table 1, "other appliance ... with no flue draught stabiliser",
/// air permeability > 5.0: 550 mm2/kW of rated output above 5 kW.
public static let noStabiliserLeakyThreshold = Kilowatts(5)
public static let noStabiliserLeakyRate: Double = 550

Because the citation is carried rather than remembered, the app can print “AD J Table 1” next to the answer without anyone maintaining a separate list of references that drifts out of date. When you are standing in front of a building control officer, the app tells you exactly which paragraph its answer came from, and you can check it.

It also makes review possible. Anyone auditing the engine can put the constant and the archived PDF side by side, one figure at a time.

Figures read from diagrams are read from the page

Text extraction from a PDF quietly drops symbols, superscripts and everything drawn rather than typeset. Several of the figures in Approved Document J live only in diagrams: hearth plan dimensions, flue outlet positions, wall protection thicknesses.

Those were read from the rendered page by eye, not scraped, and the source file records which ones. It is slower and it is the only way to be sure a 200 in the code is the 200 on the drawing.

Test cases have to come from somewhere real

Every rule has a test, and the expected values are hand-derived worked examples recorded with their derivation and the paragraph they come from. Not “whatever the code returned when we wrote it”. A test whose expected value has no traceable origin proves only that the code still does what it did yesterday, which is not the same as being right.

On top of the worked examples, every limit gets boundary pairs: readings either side of each threshold. For Legionella Logger that means 49.99 and 50.00 on a hot outlet, 19.99 and 20.00 on a cold one, 59.99 and 60.00 on a calorifier. Those pairs encode a subtlety in the source wording that would otherwise be tidied away by a developer:

• hot outlets are “a minimum of 50 °C”, so 50.0 passes;
• calorifier flow is “without going below 60 °C”, so 60.0 passes;
• cold outlets are “below 20 °C”, so 20.0 fails.

Three thresholds, three different boundary behaviours, straight from the document’s own words.

Rounding never decides a verdict

Compliance is evaluated on the exact value in the calculation engine. The display layer decides how many decimal places to show, and shows extra precision near a limit. A number is never rounded and then compared, because that is how a marginal fail turns into a displayed pass.

The engine has no user interface in it

Each app is split so that all the arithmetic, every limit and every verdict lives in a pure calculation core with no screens, no network, no clock and no side effects. Given the same input it returns the same output, always. The interface renders what the core returns.

That boundary is not tidiness for its own sake. It means the rules can be tested exhaustively without simulating a user interface, and that a change to how something looks cannot change what it decides.

“Not covered” is a legitimate answer

Guidance documents do not cover everything, and the honest response to a gap is to say so.

Approved Document J’s Diagram 30, for example, gives wall protection rows for a hearth that abuts the wall with the appliance up to 50 mm away and between 50 and 300 mm away. It gives no row for a hearth that abuts the wall with the appliance more than 300 mm from it. Stove Toolkit returns “not covered” for that case and points you at the manufacturer’s clearances, rather than interpolating a number that the document does not contain.

A clearly marked “not covered” is safe. A verdict that looks authoritative and is quietly invented is not.

Where the manufacturer wins, we say so

Several provisions defer to the appliance manufacturer, sometimes allowing a reduction and sometimes requiring more. The apps never present a guidance figure as final where the guidance itself defers. Every result screen carries the line that manufacturer’s instructions and a competent installer govern, and it is not optional text that gets trimmed for a tidier layout.

The same discipline runs the other way. Overstating a requirement costs a real person real money and erodes trust in every other answer the app gives, so the apps distinguish what the document requires from what it recommends, and cite the paragraph either way.

What the apps are not

They are pre-checks and guides. They are not certification, not approval, not a competent person’s judgement and not building control sign-off. We do not use the words “certified”, “approved” or “compliant” about their output, in the app, on the App Store, or here. Where an app touches a trademarked scheme, it says it is not affiliated with it.

What we cannot copy

Some source material is Crown copyright under the Open Government Licence, which permits reproducing limits and citing paragraph numbers with attribution: that is why Approved Documents J and K and HSE’s guidance can be quoted directly, with the attribution line on the About screen.

Other material is not. The tabulated capacity and volt drop tables in BS 7671 are BSI and IET copyright and cannot be reproduced in a commercial app, so Cable Size UK does not contain them. It applies the method and asks you to enter the figures from your own copy of the tables. That is a genuine constraint, honestly handled, rather than a table copied and hoped about.

Why write this down

Because “trust us, the numbers are right” is worth nothing, and because the discipline only survives if it is written where the next change has to pass it. Each of these repositories carries the rule as its first instruction: never guess a limit, a formula, a table entry or an interpretation, and if the right answer is not known with certainty, stop and say so.

If you find a figure in one of our apps that you think is wrong, tell us: email@plancd.com. Bring the paragraph, and we will check it against the archived document the same day.