A Number Is Not a Quantity: The Measurement Contract for AI

A maintenance assistant reads a bilingual supplier quotation. It extracts ۱۲٫۵, normalizes the digits to 12.5, and proposes a purchase total. The arithmetic is internally consistent. The result is still unsafe: the source line did not say whether the quantity was kilograms or tonnes, the price used another currency, a comma elsewhere meant a thousands separator, and the supplier rounds tax at invoice level while the purchasing system rounds each line.

The reader decision is not simply whether the model “can do math.” It is: for this quantitative claim, may the AI present a number, may a deterministic service calculate a result, or may the result authorize a real effect? Those are three different permissions.

The central rule is: a model may interpret and propose a quantity, but it must not become the authority for its unit, currency, precision, rounding, evidence, or business effect. Put those properties in a versioned measurement contract, execute the calculation in a deterministic engine, and reject or escalate any claim whose meaning is incomplete.

A bare number has almost no business meaning

12.5 is a valid decimal lexeme. It is not yet inventory, money, duration, a percentage, or a safe threshold. A useful quantitative claim needs a semantic envelope:

The BIPM SI Brochure, updated in 2026, expresses the value of a quantity as a number and a unit; changing the unit changes the numerical value without changing the underlying quantity. That simple metrology rule matters in AI systems because language models can preserve a plausible number while silently losing its unit.

Money adds another namespace. SIX, the official ISO 4217 maintenance agency, maintains alphabetic and numeric currency codes and their minor-unit relationships. A symbol such as $ or a translated currency name is not an adequate machine identifier. Neither is “two decimals” a universal property of money.

What the evidence establishes—and where design begins

The NIST AI RMF trustworthiness characteristics define validation as objective evidence that requirements for an intended use were fulfilled, and accuracy as closeness to true or accepted values. NIST also says measurement should reflect realistic use conditions and that human intervention may be needed when a system cannot detect or correct an error. It does not prescribe a quantity schema or a calculator architecture.

Research gives a narrower technical result. The 2023 ICML paper Program-Aided Language Models reports that language models can decompose natural-language problems yet still make logical and arithmetic mistakes; its PAL method delegates the solution step to an interpreter and improves results across the evaluated reasoning tasks. That study is not financial-control certification, and a generated program can encode the wrong unit or business rule. It supports separation of language interpretation from execution, not blind trust in model-written code.

The standards and documentation below establish unit, currency, numeric representation, and rounding behavior. The quantity contract, the three permission lanes, and the release gate in this guide are ZharfAI analysis built from those facts. They are not a form mandated by NIST, BIPM, ISO, IEEE, Python, PostgreSQL, HMRC, or the PAL authors.

Choose the lane before choosing the model

Assign each quantitative use case to the least powerful lane that meets the need:

Crossing lanes must be explicit: a calculation cannot authorize payment or prove source identity, and approval cannot repair a currency the reviewer never saw.

This extends the structured-output contract. Schema validity can require a decimal string and a currency field; the quantity contract proves whether they form a supported claim and whether the consumer may use it.

Define one decision-complete quantity contract

Keep the model-facing object small, but keep the trusted envelope complete. A consequential quantity should carry at least:

{
  "status": "supported | absent | ambiguous | conflicting",
  "source_lexeme": "۱۲٫۵",
  "normalized_value": "12.5",
  "quantity_kind": "mass",
  "unit_code": "kg",
  "currency_code": null,
  "precision": 1,
  "rounding_rule_id": null,
  "source_ref": "quote-184/page-2/region-7",
  "effective_at": "2026-08-24T00:00:00Z",
  "tolerance": null,
  "contract_version": "quantity-v3",
  "allowed_use": "compare-only"
}

source_lexeme preserves what the document showed. normalized_value is a canonical decimal string, not a binary float. status prevents missing, ambiguous, conflicting, and supported values from collapsing into a nullable field. source_ref must resolve to an immutable record or protected region, not a model-generated citation-shaped string.

Do not let the model set trusted fields such as allowed_use, policy version, approval state, tenant, exchange-rate source, or rounding rule. The application derives those from authenticated context and controlled reference data. Use an allowlisted unit registry and currency table rather than accepting arbitrary abbreviations.

Normalize language without erasing evidence

Quantitative extraction is partly a language problem. Persian and Latin digits may appear together; decimal and thousands separators vary; a minus sign can be a dash; parentheses may indicate a negative amount; percent may mean a fraction or percentage points; and abbreviations can be ambiguous across domains.

Normalization should produce candidates, never silently decide among incompatible interpretations. Preserve the original glyphs and location. Parse under an explicit locale and document profile. If 1,250 could mean one thousand two hundred fifty or one and a quarter, return ambiguous unless surrounding evidence resolves it. If a unit is absent, do not borrow it from the previous line without a versioned rule and evidence link.

Separate quantity from presentation. Store canonical identifiers and decimal values; localize digits, grouping, unit names, and currency symbols only at the display boundary. Both interfaces can then show the same business quantity.

The financial-document automation guide sets the broader division of labor: models handle irregular documents; rules and accountants control financial effects. The quantity contract applies that boundary per field.

Compute in a pinned deterministic engine

Moving arithmetic out of the language model is necessary but not sufficient. The engine needs pinned behavior: decimal representation, precision, rounding mode, operation order, overflow handling, unit conversions, currency metadata, rule versions, and allowed functions.

IEEE 754-2019 defines binary and decimal floating-point formats, operations, exceptions, and results that depend on inputs, sequence, and destination format. It is not a warning that floating point is “wrong.” It is a reason to name the numeric format and operation sequence in the contract.

For decimal business invariants, ordinary binary floating point is often the wrong representation. The current Python decimal documentation shows exact representation of decimal values, configurable precision and rounding, and signals such as Inexact and Rounded. The PostgreSQL numeric-type documentation similarly distinguishes exact numeric from inexact real and double precision; it also demonstrates that numeric and floating types may resolve halfway cases differently.

Choose representation by claim: bounded integers for counts, integer minor units or fixed-scale decimal for money, and floating point with stated tolerance where appropriate. Never route a source decimal through binary float before constructing its exact value.

The engine should accept a signed contract and operands, not arbitrary model-written code. Compile any proposed expression into an allowlisted operation graph, validate dimensions, then execute it. Record the engine and rule versions, operands, ordered operations, rounding events, exceptions, and final output.

Rounding is policy, not formatting

Rounding mode alone is incomplete. The contract must state what is rounded, when, to what increment, under which jurisdiction or commercial agreement, and whether intermediate values remain available.

The UK VAT Notice 700 permits specified approaches for invoice and line-level VAT calculations and requires consistency. That is jurisdiction-specific guidance, not a global default. Its durable architectural lesson is that rounding at a line, unit, tax, or invoice boundary can produce different valid totals under different policies.

Store a rule such as:

rule: supplier-vat-2026-04
mode: half-up
quantum: 0.01 USD
stage: round each line total; round discount; compute tax on net invoice total
effective: 2026-04-01 through 2026-12-31
authority: purchasing policy P-17

Do not hide rounding behind a database column declaration. PostgreSQL documents that a constrained numeric column rounds values to its declared scale on storage. If that is the first moment the application discovers precision loss, the decision has already become implicit. Trap or record every inexact conversion before the effect boundary.

Bind every rate and threshold to time

Prices, exchange rates, tax rules, tolerances, approval limits, and unit conversions do not all change on the same clock. A calculation receipt needs the event time of the business fact, the observation time of the source, and the effective interval of every rule.

For a currency conversion, record the source pair, direction, rate, effective timestamp, publication identifier, fallback behavior, and rounding after conversion. “Use today's rate” is not reproducible across time zones or reruns. For a measured quantity, preserve instrument or source tolerance rather than manufacturing extra certainty by printing more digits.

If required evidence or an effective rule is unavailable, the correct output is not zero, the last value in memory, or a plausible estimate. It is absent, ambiguous, or conflicting, followed by the disposition defined in the abstention contract.

Build the boundary as a short pipeline

A dependable quantitative path has separable stages:

source bytes
  -> locale-aware extraction with source regions
  -> quantity candidates and explicit uncertainty
  -> unit/currency/reference-data resolution
  -> semantic and dimensional validation
  -> deterministic calculation under a pinned rule
  -> independent postcondition and tolerance checks
  -> authorization / human review
  -> external effect and authoritative receipt

The model belongs mainly in extraction, mapping, and explanation. It may suggest a unit from context, but the resolver must verify the unit against the source and domain. It may propose an operation graph, but the engine must reject unknown operations, incompatible dimensions, missing rates, division by zero, overflow, and unauthorized rule versions.

Keep authorization after calculation. Amount limits, segregation of duties, tenant scope, supplier identity, duplicate detection, and approval state do not become mathematical just because the amount is exact. After an effect, reconcile the calculation receipt with the system-of-record receipt. The audit-evidence guide explains why a model trace alone cannot prove that a transaction occurred.

Worked example: one invoice, two defensible totals

Assume a test invoice contains two mass lines written with Persian digits: ۱۲٫۵ kg and ۲٫۲۵ kg, each priced at 34.75 USD/kg, followed by a 2.5% discount and 20% tax. For this example only, purchasing policy says: use exact decimal operands, round each line half-up to 0.01 USD, round the discount to cents, then calculate and round tax on the net invoice total. This is an invented operating rule, not tax advice.

The engine calculates:

If another service keeps both line values unrounded until the end, it reaches 599.698125 and rounds to 599.70 USD. Neither language fluency nor more decimal places selects the governing result. The one-cent difference comes from operation order and rounding stage. The contract decides; the receipt shows how.

Now change kg to an unresolved source abbreviation, remove USD, or date the quotation outside the price rule's effective interval. The engine must not calculate a total. It should return the exact blocking fields and route the case to evidence retrieval or qualified review.

Test the contract, not a list of arithmetic questions

Production evaluation must attack meaning and effect, not only benchmark arithmetic. Build cases across:

• Persian, Arabic, and Latin digits; mixed separators; negative formats; percentages and percentage points;
• absent, duplicated, contradictory, inherited, and visually detached units;
• currencies with different minor-unit relationships, deprecated codes, and ambiguous symbols;
• tie values under every approved rounding mode and stage;
• very large, very small, zero, negative, overflow, underflow, division-by-zero, NaN, and infinity paths;
• conversion rates before, during, and after their effective interval;
• values just below, at, and above approval or safety thresholds;
• tampered source regions, stale reference data, and rule-version mismatches;
• reruns under another engine, database, locale, provider, and software release;
• unauthorized attempts to change unit, rule, precision, or allowed use.

Compare complete receipts, not only final totals. A test should fail if the result matches by accident while the source, unit, rule, operation order, or exception handling differs.

Operate from quantitative integrity signals

Monitor the places where meaning can disappear:

• supported, absent, ambiguous, and conflicting quantities by field, supplier, locale, and model release;
• unit and currency resolution rate, including inherited-unit use and unknown codes;
• calculations with Rounded, Inexact, overflow, invalid-operation, or tolerance exceptions;
• rule-version and effective-time mismatches;
• deterministic replay agreement across sampled receipts;
• discrepancy rate against authoritative external totals and settlements;
• cases that cross an approval threshold after correction or conversion;
• human correction patterns for value, unit, currency, sign, separator, and rounding stage;
• unexplained differences between archive, preview, application, and system-of-record values.

Do not optimize extraction accuracy while hiding unit ambiguity. Report field-level correctness as a joint claim: value, unit or currency, evidence, effective rule, and allowed use all agree. Revisit the contract whenever a source layout, locale, currency table, tax policy, database type, arithmetic library, model, or downstream authority changes.

The measurement release gate

Before an AI-generated number can create a business effect, require affirmative answers:

• Is the quantity kind explicit, with a supported source lexeme and resolvable evidence region?
• Is the unit or ISO currency identifier present, canonical, and dimensionally compatible?
• Are locale, sign, separator, scale, precision, tolerance, and missing-value behavior defined?
• Does a versioned rule name the numeric representation, operation order, rounding mode, stage, and quantum?
• Are rates, prices, thresholds, and conversions bound to an authoritative source and effective interval?
• Does a pinned deterministic engine execute an allowlisted operation graph and surface every exception?
• Can an independent service replay the receipt and reproduce every intermediate and final value?
• Are calculation, authorization, approval, and external execution separate decisions?
• Do boundary, locale, adverse, stale-data, and cross-engine tests meet limits set by consequence?
• Does the system abstain rather than infer a missing unit, currency, rate, or governing rule?

A number becomes operationally trustworthy only when the organization can state what it measures, which rule transformed it, which evidence supports it, and what the result is allowed to do.

Source notes — reviewed August 24, 2026

• NIST AI RMF trustworthiness characteristics — current AI RMF 1.0 resource, originally released in 2023; definitions and lifecycle expectations for validity, reliability, accuracy, testing, and intervention. NIST notes that AI RMF 1.0 is being revised.
• PAL: Program-Aided Language Models — ICML 2023 paper; separates natural-language decomposition from interpreter execution across the reported reasoning evaluations.
• BIPM SI Brochure — ninth edition, 2019, updated in 2026; authoritative SI treatment of quantities, numerical values, units, and symbols.
• SIX ISO 4217 maintenance agency — the official maintenance agency’s current currency identifiers, minor-unit relationships, lists, and amendments on behalf of ISO and SNV.
• IEEE 754-2019 — active standard published July 22, 2019; binary and decimal floating-point formats, operations, exceptions, and deterministic result conditions.
• Python decimal documentation — current Python 3 documentation reviewed on August 24, 2026; exact decimal representation, precision, rounding modes, signals, and float-conversion behavior.
• PostgreSQL numeric types — current PostgreSQL 18 documentation; exact numeric, inexact floating types, scale coercion, and differing tie behavior.
• HMRC VAT Notice 700 — current UK VAT guidance reviewed on August 24, 2026; jurisdiction-specific examples of line, unit, and invoice rounding. It is evidence that stage is policy, not a universal tax rule.