AN—003 ARCHITECTURE NOTE · PUBLISHED 2026-07-02

Unit safety and uncertainty propagation in ENGIN Solver

Dimensional typing of engineering quantities, why a unit mismatch fails at parse time rather than producing a plausible wrong number, and how measurement uncertainty survives the calculation and reaches the displayed result.

READING TIME 3 MIN · IMPLEMENTATION DETAIL · SUPERSEDES NOTHING

1 — A NUMBER IS NOT A QUANTITY

Most engineering software stores a pressure as a floating-point number and the unit as a label somewhere else. The label is documentation; the arithmetic proceeds regardless. This is how a value in bar is subtracted from a value in psi and produces a result that is dimensionally coherent, numerically wrong, and entirely plausible.

In ENGIN Solver a quantity is a value, a dimension and an uncertainty travelling together. None of the three can be dropped, and operations that would produce a dimensionally invalid result do not compile.

2 — DIMENSIONAL TYPING

Dimensions are tracked as exponents over the seven SI base quantities. Addition and comparison require identical dimension vectors; multiplication and division add and subtract them. Conversion between units of the same dimension is permitted and recorded; conversion across dimensions does not exist as an operation.

// dimension vector · [M L T Θ I N J]

pressure [1 −1 −2 0 0 0 0] bar · psi · kPa

head [0 1 0 0 0 0 0] m · ft

head − pressure REJECTED AT PARSE · dimension mismatch

head × ρ × g [1 −1 −2 0 0 0 0] → pressure · admissible

The failure is at parse time, before any value is bound. This matters because a runtime failure only occurs on the input that happens to trigger it, whereas a parse-time failure occurs on the calculation itself — once, for everyone, before it is ever used on an asset.

3 — WHY NOT NORMALISE TO SI AND FORGET

Converting everything to SI on input is the common shortcut. It removes mismatch errors and introduces two worse ones: the engineer no longer recognises their own numbers, and the round trip through conversion silently discards the precision of the original reading.

Quantities are therefore held in the unit they were recorded in. Conversion happens at the point of comparison, is exact where the conversion factor is exact, and carries its own contribution to uncertainty where it is not. Results are displayed in the unit the site works in, not the unit the solver prefers.

4 — UNCERTAINTY PROPAGATION

Every measured input carries an uncertainty derived from the instrument's calibration record, not from a default. Propagation is analytical for linear and mildly non-linear expressions, and Monte Carlo where the expression is strongly non-linear or the inputs are correlated. The method used is recorded alongside the result.

SOURCECalibration record per instrument, with its expiry date

LINEARAnalytical propagation, first-order, with correlation terms retained

NON-LINEARMonte Carlo, sample count recorded, seed retained for replay

EXPIRED CALResult marked ESTIMATED, never CALCULATED

The last row is the consequential one. A calculation from an instrument whose calibration has lapsed is not a fact, and the provenance state says so on the engineer's screen rather than in a log nobody reads.

5 — UNCERTAINTY AT THE GATE

A result whose uncertainty band straddles a constraint limit is neither a pass nor a failure, and reporting it as either would be dishonest. The gate returns a third verdict — INDETERMINATE — with the band, the limit and what additional measurement would resolve it.

In practice this is the verdict engineers value most. It converts an argument about whether a machine is within limits into a specific question about which instrument to trust.

ENGIN Solver — the capability page AN—001 — the constraint gate EP-WP-001 §7 — physics provenance states

How to cite this note

ENGINPILOT (2026). Unit safety and uncertainty propagation in ENGIN Solver. Architecture Note AN—003. Bengaluru: ENGINPILOT Intelligence Systems.

All architecture notes