Validation Methodology — How Every Calculator Is Verified
Piping Toolset's positioning is deliberately narrow: fast, auditable ASME B31 / BPE calculation reports and design tools for piping engineers — not a replacement for CAESAR II, AutoPIPE, Plant 3D, or hydraulic network solvers. Narrow scope is what makes full verification practical. This page describes exactly how that verification works.
1. One implementation, everywhere
Every calculator is a strictly-typed pure function in a single package
(calc-core). The same code runs in your browser and on the server — there is no
second implementation to drift. A calculator takes explicit inputs, returns explicit outputs
with a PASS/FAIL/computed status and any model-boundary warnings, and touches nothing else.
2. Fixtures are the contract
No calculator module exists without a green fixture: a JSON file holding named cases of exact inputs, expected outputs, the expected verdict, and a numeric tolerance. Three rules govern them:
- Expected values are derived independently before the code runs — by hand calculation (the derivation is recorded in the fixture's description), from the PVP Suite validation set (112 checks whose driving inputs were reverse-derived and locked), or from a published source-sheet example.
- A fixture is never edited to match code. If code and fixture disagree, the derivation is re-done on paper first.
- Verdict paths are fixtures too. Where a calculator renders PASS/FAIL, failing cases are locked alongside passing ones (e.g. the B31G example on this site is a deliberate FAIL).
3. Two runners, one fixture set
The same fixture JSON is executed by two independent harnesses: the project's test suite, and a zero-dependency verification script that any auditor can run with bare Node — no package installation, no framework:
node scripts/verify-core.mjs PASS piping.b313-wall-thickness :: NPS 6 @ 2000 psi, S=20000, Y=0.4, ... ... calc-core: all cases green
Because the runner strips types directly from the production sources, what it verifies is the shipping implementation — not a copy.
4. Red blocks release
Continuous integration runs the fixture gate, the full test suite, and the type checker on every push and every pull request. The production site only deploys from a commit where all of it is green. There is no manual override path.
5. What the worked examples on this site are
Every worked example published on the calculator pages here is a fixture case, shown with its derivation. The numbers you can check by hand on the page are byte-for-byte the numbers the release gate asserts on every commit. The downloadable sample reports are generated from the same cases.
6. What validation does not claim
- Fixtures verify that the implementation computes its documented method correctly. Choosing the applicable code edition, allowable stresses, and factors for your design remains engineering judgment — allowable-stress and factor data are user-supplied inputs.
- Model-boundary conditions (thin-wall validity, z ≤ 20 in B31G, θ ≤ 22.5° miters …) surface as explicit warnings rather than silent extrapolation, and the warning logic is itself fixture-covered where verdicts depend on it.
- Results must be independently verified and reviewed by a qualified/licensed engineer before any design, fabrication, or operation decision.
7. Audit it yourself
The fixture coverage table on the coverage page is generated from the live fixture directory at every build — module by module, case counts, tolerances, and governing references. The calculation changelog records every change to calculation behavior with the fixtures that lock it.