Quantity: value and source unit
Dimension: mass, volume, count
Conversion: factor, offset, condition
Context: item, pack, version
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