A number should never travel without its unit
Why units must stay attached to values through import, comparison, localisation and derived calculations so numerical precision does not become false precision.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
A clean numeric field is attractive to software. It is easy to sort, calculate and reuse. It is also incomplete whenever the number represents a measured quantity.
“42” might be floor area, a floor number, a distance, a percentage, a monthly charge or a payment period. On one page, the surrounding label may make the meaning obvious. Once that value moves through imports, comparison tables, calculators and language versions, the label can disappear while the number survives. The result looks precise but is no longer self-explanatory.
I treat the unit as part of the value, not as decoration added at the final rendering step.
Comparison needs dimensional meaning
Consider two hypothetical property records. One says 58 square metres. Another contains the number 620 from a source whose unit was not imported.
A human may suspect that the second figure uses a different area system. A product must not turn that suspicion into a confirmed conversion. If the source unit is missing, the two values are not yet safely comparable.
The honest state is therefore not “convert both so the table looks consistent.” It is “the second area cannot be normalised until its unit is known.”
That may mean excluding the value from a price-per-area calculation or marking the comparison as incomplete. A temporary gap is better than a fabricated common denominator.
Money also needs a unit and a basis
Currency is an obvious unit, but financial figures often need more context than currency alone.
A number such as 1,200 could be a monthly charge, a price per square metre, a deposit or a one-off fee. Even “USD 1,200” still leaves the question: for what, and for what period?
If an upstream source provides “USD 180 per month” and an import process keeps only 180, a later interface component cannot safely reconstruct the missing period from intuition. The technical system does not need to invent economic meaning. It needs to preserve meaning that was already present.
The same principle applies to percentages. “70” becomes meaningful only when the product knows whether it is 70 percent of a payment, 70 percent construction progress, a ratio used by a tool or something else entirely.
Conversion should preserve the original value
Sometimes a product should display a different unit because it is more useful to the reader. That is a presentation choice, and it can be valuable.
The safe sequence is to keep the original value and unit, then derive the presentation value from them. That preserves an audit trail for the calculation and avoids confusing a converted number with a number published by the source.
It also reduces compounding error. If a value is rounded for a card and a later calculation uses the rounded display value as its new input, small differences can accumulate. The authoritative input should remain the source value with its source unit, while presentation layers are treated as derived outputs.
A buyer does not need to see all of that machinery. The product does.
Imports should carry semantic pairs, not isolated numbers
I test the data path as a sequence.
At ingestion, the value and unit arrive together. In storage, they remain connected. On the project page, the correct label appears. In comparison, the unit survives. In any exported or printable version, the number still answers “how much of what?” In another language, formatting can change without changing the underlying quantity.
This kind of end-to-end test catches defects that individual pages miss. A project page may correctly show “45 m²” because its template knows that a particular field is area. A generic comparison component may receive only 45 and assume every row uses the same unit. The error remains invisible until data from another source uses a different convention.
The weakness is therefore not always in the source or in the display. It can be in the handoff between them.
Localisation is not the same as conversion
A localised interface may use different decimal separators, spacing or unit labels. Those changes are formatting.
Converting one measurement system into another is a calculation.
The two operations should not be confused. A language switch can change how the value is written while preserving the same measurement. A unit conversion changes the displayed magnitude according to a defined relationship. Both are legitimate, but they need different logic and different tests.
Thinking in a “value plus unit” pair before localisation makes this distinction easier. The system first knows what quantity it has. Only then does it decide how a particular reader should see it.
Derived figures inherit the unit problem
A missing unit becomes more dangerous when the number feeds another calculation.
Suppose an area value is used to calculate a price per unit of area. If the area’s unit is unknown or wrong, the derived price can still look mathematically tidy. The calculator will not complain merely because the semantics are broken.
That is why validation should happen before derivation. A number with unresolved dimensional meaning should not quietly enter a formula whose output looks authoritative.
The same is true for time periods and rates. A recurring cost needs a period before it can be annualised. A distance needs a unit before it can be compared. A percentage needs a defined base before it can be interpreted.
Precision is not the same as correctness
A lost unit can be harder to notice than a spelling mistake. The number remains plausible. The table is aligned. The calculator produces a result to two decimal places. Every layer can look professionally finished while the underlying statement is ambiguous.
For the buyer, the standard can be much simpler: every material number should answer “how much of what?” When the platform can preserve that answer from source to screen, the value remains useful across pages and tools. When the unit separates from the number, numerical precision stops being informational precision.