17. Metrological modularity🔗

The chapters so far give the calculus's vocabulary (kinds, quantities, units, dimensions, objects and their parts) and its evidence discipline (the boundary audit and the metrological provenance hypergraph); the authoring recipe and the uncertainty calculus follow. This chapter states the organizing principle they add up to: software organized as metrology modules. Nothing in the principle is specific to science software — it applies wherever a computed value is presented as a measurement result in the VIM sense, whatever the domain; science software is simply where this development exercises it. A metrology module is a software component — the declarations one boundary names as its members, which need not be a file or a namespace — whose

interface is a declared boundary of kind-typed ports — input quantities, output quantities, parameters, configuration, and conditional outputs with their deciders;
behavior is a measurement model in the VIM sense — VIM 4 2CD §2.12 [VIM3: 2.48], the mathematical relation among the quantities involved, in the general implicit form h(Y, X_1, \ldots, X_n) = 0 — attached to the boundary as a checked theorem edge, not as prose;
implementation is a measurement function (VIM 4 2CD §2.13 [VIM3: 2.49], whose Note allows that "f" may symbolize an algorithm): a carrier-parametric kinded definition whose relation to the measurement model is equals, inverts, refines, or boundedBy a declared tolerance;
licenses are stated per rung of the carrier ladder, as the relation's license clause: the measurement-model claim is proved at one carrier, and each further carrier the module runs at — binary32, Float, the tape — gets its own entry saying how the claim holds there. A law proved over the reals survives the move up to one rounding per operation; a side condition phrased in the carrier's own arithmetic, such as "the total is not zero", constrains the exact total at one rung and the rounded total at the next, and neither implies the other;
mereology is declared — each output port carries its aggregation class, and the license to distribute the module's computation over a carving is derived from that declaration, not assumed;
requirements are stated — what the module's quantities must satisfy, each a requirement beside the boundary it governs with the evidence by which it is met: a provable requirement by a theorem, an empirical requirement by a gate against a referent the model does not define.

The name pairs the discipline (metrology — the interface vocabulary is Dybkær/VIM kinds and quantities, the spec vocabulary is the VIM measurement model) with the software principle (modularity — boundaries, contracts, composition). Why the relational form matters: VIM's general form is implicit, and its §2.12 Note 1 has the measurand's value inferred from the relation. A retrieval module's honest specification is therefore "the output satisfies the forward model's equation" — exactly, or within a declared tolerance — not "the output is what this loop computes". The paradigm demotes the loop to evidence for the relation, with the relation as the published behavior. MODULARITY.md in the repository root is the working plan for carrying the paradigm into the downstream model and deployment tiers.