Define tolerance policy for one quantity expressed in different units

[mentaljam]

Context

PR #65 introduces specs/quantities.yaml, where one physical quantity may define separate absolute tolerances for several units. We need an explicit policy for how those tolerances relate to one another.

This is intentionally separate from the PR review: the registry architecture can land first, while the numerical policy is discussed and refined independently.

Example

For saturated_hydraulic_conductivity, the current absolute tolerances are:

Unit	Absolute tolerance	Equivalent in mm/h
m/s	1e-10	3.6e-4
cm/h	1e-5	1e-4
mm/h	1e-4	1e-4
cm/min	1e-5	6e-3
cm d^-1	1e-4	4.17e-5

The relative tolerance is consistently 0.01, but the absolute floors differ by roughly two orders of magnitude after unit conversion. This may be acceptable, but it should be a deliberate rule rather than an accidental property of convenient decimal values.

Question

Should absolute tolerances for one quantity be:

1. Physically equivalent across units
   Define one canonical absolute tolerance and convert it into every supported unit.

2. Independent per-unit rational resolutions
   Allow each unit to reflect typical reporting precision, source rounding, or measurement resolution, even when the same physical value could pass in one unit and fail in another.

3. A hybrid
   Define a canonical physical tolerance for the quantity, plus an optional unit-specific representation/rounding floor. The effective absolute tolerance would be the larger of the converted physical tolerance and the unit-specific floor.

Points to decide

• Is acceptance expected to be invariant under exact unit conversion?
• If not, what evidence or rationale is required for a unit-specific difference?
• Should one unit be declared canonical for each quantity?
• Should equivalent tolerances be generated automatically or only validated?
• How should we handle inconvenient converted values and round-trip conversion error?
• Do source-specific function-output overrides follow the same conversion policy?

Desired outcome

Document the chosen rule, encode enough metadata to make it reviewable, and add validation/tests that prevent unintended inconsistencies while still allowing scientifically or practically justified exceptions.

Related: #65