Unit conversion chain
01

Quantity: value and source unit

02

Dimension: mass, volume, count

03

Conversion: factor, offset, condition

04

Context: item, pack, version

05

Control: precision and conservation

A number without a unit is incomplete

One hundred can mean kilograms, liters, cases, or pieces. Store value, unit code, and measurement context together.

Convert only compatible dimensions. Kilograms to liters needs density; cases to pieces needs packaging. Reject conversion when context is absent.

Govern a dimensioned unit dictionary

Keep stable code, symbol, dimension, base unit, scale, offset, and source. Mass, volume, temperature, currency, and count are separate.

Normalize source variants but retain original values and units for audit.

Separate linear, affine, and item-specific rules

Mass often uses a factor; temperature may need offset; packaging depends on item, pack version, and effective period.

If a case changes from 12 to 10 pieces, event-time facts must retain the historical package version.

Preserve physical conditions

Mass-volume conversion depends on density, temperature, pressure, concentration, or batch. Record standard or measured conditions.

An approved estimate should carry estimated status and uncertainty rather than laboratory-like precision.

Keep original and canonical values

Facts can retain original value/unit, canonical value/unit, conversion ID, and version. Original supports audit; canonical supports aggregation.

Convert at the finest reliable grain before summing. Mixed units must never be summed first.

Treat precision and rounding as policy

Define source, intermediate, and display precision plus rounding mode. Per-row and post-aggregation rounding differ.

Use fixed decimal for controlled quantities and avoid both binary error and false excess precision.

Reject dimensional mismatch and inconsistent loops

Validate dimension, item scope, factor, sign, effective period, and overlap. If A-B-C conflicts with A-C, do not choose arbitrarily.

Select an authoritative path and preserve source evidence.

Make metric units explicit

Separate unit sales, weight, volume, and standard cases. Show target unit and conversion coverage.

Price per kilogram and per case require unit normalization. FX conversion is a separate versioned policy.

Accept through real edge cases

Test packaging change, affine conversion, missing density, partial cases, negative returns, loops, expired rules, and rounding residual.

Reconcile scale, warehouse, ERP, and finance samples, classifying source unit, specification, condition, precision, and timing.

Operate conversion changes as governed releases

Before changing packaging, density, or a standard unit, enumerate affected facts and downstream metrics. Decide whether the rule applies prospectively or restates open inventory and history.

Replay old and new canonical values with reasons, reconcile source and canonical quantities, and publish one conversion policy across semantic views and exports.

BuildTable.ai boundary

Pilot one product family with package changes, govern units, replay history, and publish unit-explicit metrics.

BuildTable.ai may be evaluated for dictionaries, rules, and canonical facts. Complete standards, physical-property data, and automatic rule choice require verification.

Public references

Build an AI-ready data foundation

Contact us to discuss your data modeling scenario and access BuildTable Desktop.

Contact us