AI Number Extraction: Preserve Units, Scale and Precision

An AI extractor returns 1.25. The JSON is valid, the value is positive and the digits match the document. Yet the destination needs kilograms, the source reports tonnes, and the integration has just reduced the quantity a thousandfold. A model can transcribe a number correctly while the surrounding software delivers the wrong fact.

The consequential decision is whether an extracted quantity has enough evidence and a sufficiently precise [contract](/industries/legal) to enter a calculation or record. Asking the model to double-check its arithmetic does not resolve a missing unit, ambiguous decimal separator or lossy serialisation step.

This guide separates documented behaviour from design judgement. The standards, incident report and runtime documentation establish specific failure mechanisms. The proposed quantity contract, acceptance rules and synthetic example are AIEngine's engineering recommendations, not a certified specification or evidence of performance in a customer deployment.

A number is not yet a quantity

The BIPM's SI Brochure, ninth edition, version 4.01 of June 2026 explains that a quantity's value is generally expressed through a numerical value and a unit. It also describes table headings that carry the unit while the cells contain only numbers. Extracting the cell without that heading removes part of its meaning.

For an application, the same discipline extends beyond physical measurements. An amount needs a currency and scale; a percentage needs a defined base; an identifier may contain digits without being a quantity at all. A reference such as 000847 must not become the integer 847 merely because a parser can convert it.

Define the field's meaning before choosing its data type. Is this a measured mass, a count, a ratio, a monetary amount, a bound or an identifier? Which unit and reference period apply? Does a dash mean unavailable, not applicable or zero? These choices belong to the receiving contract, not the model's improvisation.

The document reading-order audit covers preserving a value's attachment to its header and notes. Numerical validation begins after that relationship is available; it must still verify that the attached context supports the proposed interpretation.

Parse the source convention, not the server's locale

The string 1,250 is not self-interpreting. Depending on the convention, the comma may group thousands or separate a fractional part. Removing all punctuation is not normalisation: it can multiply a quantity while leaving an entirely plausible result.

Unicode's LDML number specification, version 48.2 when checked for this article, documents locale-dependent number symbols and parsing ambiguities involving signs, separators, exponents and currency symbols. It supplies useful parsing guidance; it does not establish which convention an individual source document intended.

Use an explicit parsing profile tied to the document family or source system. That profile should specify accepted digit sets, decimal and grouping separators, sign notation, exponent syntax and whether surrounding whitespace is permitted. Require the entire field to parse. A parser accepting the numeric prefix of an unexpected string should not make the remaining characters disappear.

A language label alone is weak evidence. An English report can reproduce a table from another locale. Prefer a declared source convention, an approved template or corroborating context. If two interpretations remain possible, retain both as candidates and route the field for resolution. Do not choose whichever candidate falls inside the expected range: a range check can expose a contradiction, but cannot manufacture source evidence.

Keep the original and the interpretation separately

Avoid a schema with only a value and confidence score. It cannot explain whether a discrepancy came from transcription, inherited scale, unit conversion or storage. Instead, retain a source representation alongside a typed, validated interpretation.

A useful minimum record contains:

• The original numeric token, including sign, separators and trailing zeros.
• Source revision and a location resolving to the field and its governing context.
• Quantity kind, with identifiers explicitly excluded from arithmetic types.
• Source unit, source scale and evidence for each inherited attribute.
• Parsing profile and the rule used to resolve the source convention.
• Exact parsed representation, separate from the destination representation.
• Conversion rule, rounding policy and implementation version, where applicable.
• Validation state and unresolved reasons, without replacing missing values with zero.

This is not a demand to copy entire documents into every row. Store controlled references to retained evidence, with permissions and retention appropriate to the source. The important property is reconstructability: a reviewer can see the original token and the transformations that produced the delivered value.

Make accepted, ambiguous, missing, out-of-range and unsupported-unit states distinguishable. Downstream calculations should require an accepted quantity rather than treating every populated value field as usable. A review correction should create a new interpretation with its reason, leaving the original extraction intact.

Choose representation before arithmetic

JSON's number syntax is not a universal precision guarantee. RFC 8259, published in December 2017, allows implementations to limit numeric range and precision. It identifies exact agreement for integers from negative 9,007,199,254,740,991 through positive 9,007,199,254,740,991 when the commonly used binary64 behaviour applies. Larger integers require deliberate interoperability decisions; the RFC does not say JSON forbids them.

Test the complete path: model response, SDK, application, queue, database, export and receiving service. A large integer may be correct in raw JSON and already altered before application validation runs. Once digits are lost, converting the rounded result into a string cannot recover them.

Use bounded integer types for counts that genuinely fit. For exact decimal interchange, a canonical decimal string plus an explicit contract can avoid premature binary floating-point conversion. Validate its grammar, length, exponent limits and permitted scale before constructing a numeric object; an arbitrary string is not automatically a safe decimal.

Python's decimal documentation shows why construction matters: decimal values such as 1.1 lack an exact binary floating-point representation, and constructing a Decimal from a float preserves that float's exact value, not the original decimal spelling. Construct from the validated source string when decimal exactness is required. Set calculation precision and rounding deliberately; decimal arithmetic still has finite contexts and inexact operations.

Binary floating point remains appropriate for many scientific and statistical calculations with explicit error tolerances. The choice is not a contest between good and bad number types. It is whether the representation satisfies this field's range, equality, precision and interoperability requirements. Version that decision with the tool and data contract, including any change from numeric JSON to decimal strings.

Convert only after meaning is established

A conversion service should accept a known quantity kind, supported source unit and permitted destination unit. It should not ask a language model to invent a conversion expression each time. Keep a reviewed registry of transformations and reject unsupported combinations.

The historical warning is concrete. NASA's Mars Climate Orbiter Phase I investigation, dated 10 November 1999, found that ground software supplied pound-force seconds where the interface required newton seconds. The report identified a root cause and several contributing causes, not an AI failure. Its relevance here is the interface lesson: a written unit requirement did not ensure that transferred data obeyed it.

Distinguish a change of unit from a change of meaning. Kilowatts and kilowatt-hours are not interchangeable labels. A conversion between compatible units does not establish whether a figure is gross or net, a maximum or an average, or a rate rather than a total. Even compatible dimensions may be insufficient to prove that two fields describe the same quantity.

Keep scale application explicit and single-use. A table headed “amounts in thousands” should not be multiplied again because a later stage sees the same heading. Store the source value, applied multiplier and resulting value so tests can detect double conversion.

Rounding needs its own policy: target resolution, rounding mode, stage of application and treatment of boundaries. Do not infer measurement uncertainty from the number of decimal places alone. Preserve a reported uncertainty or interval separately, and let the domain's decision rule determine how it affects acceptance. Extra computed digits do not make uncertain source evidence more accurate.

Work through one quantity end to end

Consider a synthetic warehouse intake form, used only to illustrate the contract. Its approved template declares a comma decimal separator. A row has reference 000847, net mass 1,25 beneath a tonnes header, and moisture 0,8 beneath a percentage header. The destination is a draft logistics record requiring kilograms and a moisture fraction, not a dispatch command.

The extractor should propose the raw tokens and source locations. Conventional code then performs the following interpretation:

For this example, the approved conversions are 1.25 multiplied by 1000 and 0.8 divided by 100. They are exact arithmetic operations on the represented decimals, not claims about the accuracy of the underlying measurements. Retain the original stated precision rather than presenting 1250 as a newly measured exact mass.

Now remove the template's locale declaration and replace the mass token with 1,250. If the remaining evidence cannot resolve the convention, the correct output is an ambiguous mass with no accepted destination value. Regenerating until the model chooses one candidate is not a repair. A reviewer needs to resolve the convention from the source or obtain a corrected document.

Finally, read the draft record back from its destination and compare the stored quantity, unit and reference with the accepted object. This catches a receiving schema that rescales or coerces the value. Numerical acceptance still does not authorise dispatch: the wider output-to-action validation gates cover permission and safe commitment.

Test meaning-preserving and meaning-changing mutations

Build tests at two levels. Fixed numeric fixtures exercise parsers, conversions and serialisation without any model. Document-level examples exercise the extractor's ability to find the right token and context. Keeping these separate makes a failed result diagnosable.

Use paired cases with explicit expected outcomes:

• Change approved grouping whitespace without changing value; the interpretation should remain equal.
• Change the declared decimal convention while retaining the token; the interpretation may change or require review.
• Remove the unit header; a quantity requiring that header should lose accepted status.
• Change a scale from units to thousands; verify one multiplication, never zero or two.
• Exchange a percentage with its equivalent fraction; compare only after an explicit representation conversion.
• Send integers around the interchange boundary through every real client and storage hop.
• Replace a missing marker with numeric zero; the validator should recognise these as different states.
• Exercise negative values, bounds, extreme exponents and unsupported units against field-specific rules.

Include correct examples so rejection does not become the easiest way to pass. Test values immediately below, at and above a business threshold using the specified rounding rule. Where a source reports an interval, test whether the downstream decision consumes the interval or wrongly collapses it into a midpoint.

Compare expected quantities, not merely strings. Different approved spellings can represent the same value; identical digits with different units can represent different values. Conversely, identifiers require the contract's identity-preserving comparison, not numeric equality. Human reference labels should preserve genuine ambiguity instead of forcing every test document to have one answer.

Measure accepted errors, not just extracted fields

A high extraction completion rate can hide precisely the cases that matter. Track wrong-but-accepted quantities separately from visible rejections, and distinguish transcription errors from convention, scale, conversion, rounding and storage failures. Measure at field level and at the record level where several quantities jointly determine an outcome.

Report review rate and queue age alongside accepted-error rate, with counts by document family and unit. Sample accepted records against original evidence; reviewing only rejected records cannot reveal silent escapes. Record the downstream consequence where it is known, without treating every decimal difference as equally material.

Re-run the fixtures when the model, prompt, parser, template, unit registry, decimal library configuration or destination schema changes. A newly received format can invalidate an old parsing assumption even when no code changed. Keep unresolved records out of consequential calculations until their interpretation is established.

The release question is narrow and testable: can the receiving system reproduce why this token became this quantity, and can it stop when that explanation is incomplete? Correct digits are necessary. Preserved meaning is what makes them usable.