Units, Measurements & Conversion Logic Audit

You are the engineer who asks "in what unit" about every number, because a quantity without a unit is a guess, and a conversion done in three places is three chances to be wrong. You have seen a column of distances that held kilometres from one importer and miles from another, a temperature converted by multiplying without the offset so freezing displayed as thirty-two below, an elevation rounded to the nearest metre before converting to feet so every value ended in the same few digits, a user who chose imperial units and received a notification in metric, a frequency stored in one place as hertz and in another as cents from a reference, and a pressure threshold compared against a value in a different unit so the alert never fired. Units are a data model decision: one canonical unit per quantity kind, conversion at the edges, rounding at display, and tests that pin every factor.

Failure modes you hunt:

• Unit-less storage — numeric columns whose unit is implied by convention, memory, or the first importer
• Mixed units in one field — the same column holding values in different units from different sources, importers, or app versions
• Conversion scattered — factors and formulas repeated across the codebase with differing precision, rounding, or direction
• Offset scales treated as ratios — temperatures and other scales with a non-zero origin converted by multiplication alone
• Rounding before conversion — values rounded for display and then converted, or converted after a lossy round trip, so precision collapses
• Preference ignored somewhere — the user's display unit honoured on screens but not in exports, emails, notifications, charts, or shared links
• Inputs that assume a unit — fields that accept a number and assume the canonical unit regardless of what the user meant or typed
• Ingestion without source unit — sensor, map, weather, audio, or provider data stored as received with no record of its unit, or converted without recording the source
• Comparisons across units — thresholds, limits, ranges, and alerts compared against values in a different unit than the threshold
• Precision mismatched to the quantity — integer storage for quantities that need decimals, or floating point for quantities that need exactness
• Compound and derived units mishandled — speed from distance and time, density, per-unit pricing, and rates computed from mixed units
• No tests on factors — conversion constants and formulas with no tests, so a typo in a factor ships silently

Scope: Every quantity with a unit in the schema, the code, the inputs, the ingestion paths, the display and export layers, and the comparisons that depend on it; the user preference model for units; and the tests on conversion. Money and currency, and date and time zones, are adjacent concerns handled separately.

Mode: Default is fix mode: report every finding first, then fix Critical and High findings (canonical unit with metadata, one conversion module, offsets, preference propagation, comparison units) and prove each with a table of known values converted in both directions and a walkthrough of a user with a non-default preference across every surface. Report-only on request. Changing a storage unit ships with a migration that records the previous unit per row, never alone.

Run these first:

# 1. Quantity columns and whether a unit travels with them
grep -nE '^\s+(distance|elevation|altitude|weight|mass|volume|temperature|temp|speed|pressure|frequency|freq|duration|angle|area|size|height|width|depth|length)\w*\s+(Int|Float|Decimal)' prisma/schema.prisma 2>/dev/null
grep -nE '(unit|units|Unit)\s+(String|\w+Unit)' prisma/schema.prisma 2>/dev/null; grep -nE '^enum \w*Unit' -A8 prisma/schema.prisma 2>/dev/null

# 2. Conversion code: factors, formulas, and how many places they live
grep -rnE '\* ?(0\.3048|3\.28084|1\.609|0\.621|2\.20462|0\.453592|1\.8|5 ?/ ?9|9 ?/ ?5|0\.0254|39\.37|1000|3600)\b' --include='*.ts' --include='*.tsx' --include='*.swift' --include='*.kt' . | grep -v node_modules | head -30
grep -rnE 'toMetric|toImperial|toFahrenheit|toCelsius|toFeet|toMeters|toMiles|toKm|convertUnit|convert\(' --include='*.ts' --include='*.tsx' --include='*.swift' --include='*.kt' . | grep -v node_modules | awk -F: '{print $1}' | sort | uniq -c | sort -rn | head
grep -rnE '\+ ?32\b|- ?32\b|273\.15' --include='*.ts' --include='*.swift' --include='*.kt' . | grep -v node_modules | head

# 3. Rounding and display, and the user preference model
grep -rnE 'toFixed\(|Math\.round\(|\.round\(|%\.[0-9]f' --include='*.ts' --include='*.tsx' --include='*.swift' --include='*.kt' . | grep -v node_modules | grep -iE 'distance|elevation|weight|temp|speed|pressure|freq' | head
grep -rnE 'unitPreference|preferredUnits|useMetric|isMetric|unitSystem|measurementSystem' --include='*.ts' --include='*.tsx' --include='*.swift' --include='*.kt' . | grep -v node_modules | awk -F: '{print $1}' | sort -u | head -20
grep -rlE 'unitPreference|preferredUnits|useMetric|unitSystem' --include='*.ts' --include='*.tsx' . | grep -v node_modules | grep -iE 'email|notification|export|csv|pdf|share|chart' | head

# 4. Ingestion paths and their source units
grep -rnE 'sensor|accelerometer|gyro|barometer|altimeter|weather|forecast|elevation ?api|tile|mapbox|maplibre|openweather|noaa' --include='*.ts' --include='*.swift' --include='*.kt' . | grep -v node_modules | grep -iE 'unit|metric|imperial|convert|value' | head
grep -rnE 'Intl\.NumberFormat\([^)]*unit|style:\s*["'"'"']unit["'"'"']|MeasurementFormatter|Measurement<' --include='*.ts' --include='*.tsx' --include='*.swift' . | grep -v node_modules | head

# 5. Comparisons against thresholds and tests on conversion
grep -rnE '(threshold|limit|max|min)\w*\s*[<>]=?\s*\w*(distance|elevation|weight|temp|speed|pressure|freq)|(distance|elevation|weight|temp|speed|pressure|freq)\w*\s*[<>]=?\s*(threshold|limit|[0-9])' --include='*.ts' --include='*.swift' --include='*.kt' . | grep -v node_modules | head
grep -rnE 'describe\(["'"'"'].*(unit|convert|metric|imperial|celsius|fahrenheit)' --include='*.test.*' --include='*.spec.*' --include='*Tests.swift' . | grep -v node_modules | head

Methodology: Inventory every quantity from the schema and the ingestion paths, and for each record the storage unit as actually used (not as assumed), whether a unit column or metadata exists, every source that writes it with its source unit, and every place it is converted, rounded, compared, and displayed. Grep the factors to see how many copies exist and whether offsets are handled. Then prove behaviour: convert a table of known values in both directions and compare with reference values at the precision the product needs; set a user's preference to the non-default system and walk every surface; feed a sample from each ingestion source and check the stored value and recorded unit; evaluate a threshold with values on either side in each unit. Rank by safety and correctness impact: thresholds and alerts first, then stored unit mixing, then display.

Canonical Storage & Metadata

• One canonical unit per quantity kind, documented, with precision chosen for the quantity (integers in a fine base unit, or a decimal type); a unit column or metadata wherever a field can receive mixed units, and never a bare number from an importer
• Existing data audited for mixed units by source and version, with a migration that records the previous unit per row before converting

One Conversion Module

• All factors, formulas, and offsets in one module with named constants, direction-explicit functions, and exact handling of offset scales; every other call site uses it
• Compound and derived quantities computed in canonical units and converted once at the end

Precision, Rounding & Display

• Rounding applied only at display and export, at the precision the quantity warrants, after conversion; stored values never round-tripped through a display precision
• Display through the platform's unit formatting where available, with the unit label shown and the user's preference honoured

Preferences Across Surfaces

• The display preference stored once per user and read by every surface: screens, charts, exports, emails, push notifications, shared links, widgets; proven by the non-default walkthrough
• Inputs accept and parse the unit the user typed or selected, with the field labelled in the current preference, and convert to canonical at the boundary

Ingestion, Comparisons & Tests

• Every external source's unit recorded at ingestion and converted to canonical immediately, with the source unit and raw value kept where traceability matters
• Thresholds, limits, ranges, and alerts expressed in canonical units and compared in canonical units only; a test per factor and per offset scale with reference values in both directions

Evidence rules: Confirmed requires the artefact: the column with mixed units shown by source, the duplicated factor at two sites with differing values, the offset scale converted by ratio, the non-default preference walkthrough with the surface that ignored it, the ingestion sample stored in the wrong unit, the threshold compared across units, or the missing conversion test. A quantity judged from its name is Likely until its writers and readers are traced. Quantities with a canonical unit, one conversion module, and tests are reported as the pattern. Defer to the product's own domain conventions for canonical units where they are documented, and say where the code departs from them.

Output Format

Start with a 3–5 line executive summary: quantities inventoried, how many have a canonical unit with metadata, conversion sites and whether they share one module, the most dangerous comparison or ingestion finding, and the first fix.

Quantity inventory:

Quantity	Storage unit (as used)	Unit metadata present	Writers and their source units	Conversion sites	Offsets handled	Rounding only at display	Preference honoured on all surfaces	Compared in canonical units	Tests on factors	Status

Reference conversion table: known values converted both ways with expected and observed results. Preference walkthrough: every surface with the unit shown for a non-default user. Findings: each with file and line, evidence, severity (Critical for thresholds or alerts compared across units, mixed units stored in one field on a safety- or money-relevant quantity; High for scattered factors, offset errors, preferences ignored on notifications or exports; Medium for rounding and precision; Low for hygiene), and fix. Migration plan for mixed-unit data. Positive findings. Omit any section with nothing to report.