Decimal precision and units in numeric exports

Start with the semantic role, not the column name. A count is usually an integer, a measured quantity may need a unit and a decimal scale, a ratio may need a declared denominator, and an identifier is often text even when it contains only digits. “Numeric” is not enough to decide whether a consumer may round, add, compare, or display a value.

Write the contract in one sentence: “This field is a measured quantity in the named unit, represented at the stated scale, with rounding applied only at the stated boundary.” If the sentence cannot say where rounding happens, the export does not yet have a precision policy. The source dates shown in this guide identify documentation checks on 22 October 2026, not original publication dates.

A review packet should keep the source lexeme, parsed value, scale, unit, and operation visible. The lexeme is the text that crossed the wire. The parsed value is what the reviewing tool understood. Keeping both makes it possible to spot a parser that turned a trailing zero into a shorter display scale or rounded a value before validation.

The table is a worksheet, not a universal schema. Choose names that match the receiving contract and retain the original field names in a mapping. Do not replace an unknown unit with a guess. An unresolved unit is a review finding, even when the number itself parses cleanly.

RFC 8259 allows JSON numbers, but its interoperability guidance describes a practical boundary around IEEE 754 binary64. RFC 8785 makes the consequence concrete for canonicalization: JCS serializes numbers under that model and points to strings for higher precision or longer integer values. If exact decimal text is part of the meaning, a string with a documented decimal grammar can be safer than relying on every consumer to share a decimal implementation.

import json
from decimal import Decimal

payload = '{"reading":"1.250", "count": 17}'
row = json.loads(payload, parse_float=Decimal, parse_int=Decimal)

reading = row["reading"]
count = row["count"]
assert isinstance(reading, str)
assert Decimal(reading) == Decimal("1.250")
assert count == Decimal("17")

This small fixture demonstrates a review technique, not a drop-in parser policy. The receiving contract still needs a scale, range, exponent policy, and error behavior. Test a value with trailing zeros, a boundary integer, a negative value if allowed, and a value that should be rejected. Check the serialized output again after any transformation.

The JSON Schema, 22 Oct 2026 (opens in a new tab) validation vocabulary can express numeric constraints such as minimum, maximum, multipleOf, and integer type. Those constraints do not supply a unit or decide whether a decimal should be a string. Keep the mathematical contract and the JSON Schema contract adjacent in the packet.

A number without a unit is only useful when the field contract makes the dimension obvious. Prefer a unit field, a documented field-name convention, or a typed schema that cannot be separated from the value. Record whether the export contains a base unit, a derived unit, or an agreed non-SI unit, and state any conversion boundary explicitly.

NIST lists SI base units and derived units such as area, volume, and velocity. Its SI prefix guidance distinguishes defined prefixes from local shorthand. An unexplained or domain-specific shorthand may not use a defined SI multiplier, so do not turn an abbreviation into a unit by intuition. Ask the producer for the unit vocabulary and conversion rule, then test the conversion with a synthetic value.

Run validation on the representation that the contract names, then repeat the checks after any permitted normalization. A value can satisfy a range before rounding and fall outside it after rounding, or it can appear to satisfy a scale check only because a consumer formatted it for display. Record which version was tested and why the transformation is allowed.

A useful finding says “the wire value is parseable but the unit and rounding boundary are undocumented.” It does not say “the dataset is accurate.” Keep precision, units, completeness, and business meaning as separate findings. That separation makes a follow-up request small and testable.

If the owner can describe the collection and its handling authority, the next step may be the appraisal route. That route is a request for review, not automatic acceptance, a quote, a buyer match, a legal opinion, or a license. Keep sensitive values out of a first-pass numeric worksheet and share only the approved evidence needed to answer the named question.

Takeaways

• Classify the field before choosing JSON number or string.
• Keep the raw lexeme, parsed value, scale, unit, and rounding stage visible.
• Use a documented exact representation when consumer precision is uncertain.
• Treat unit and prefix rules as part of the schema, not display decoration.
• Report parseability, precision, units, and business meaning as separate findings.