An AI agent can explain a calculation correctly and still produce a wrong operational result when the number travels between a model, a tool, a database and a human decision. Numeric integrity means preserving what a quantity represents, which units it uses, how precisely it was measured, where rounding is allowed and how the final amount can be independently reconciled. The practical control is not a more eloquent mathematical answer. It is a typed numerical contract whose arithmetic can be repeated outside the model.
This chapter teaches an engineering pattern for present-day AI-assisted workflows, not a claim that artificial superintelligence exists. An agent may recommend a price, compare a laboratory measurement or assemble an invoice, but authoritative calculations should run in deterministic software with explicit validation. We will build a fictional teaching ledger, locate the errors that make plausible outputs dangerous, test recovery when two records disagree, and transfer the method to a physically measured quantity. Every numerical example here is illustrative, not a measured performance result.
Choose a route: readers who mainly need the principle can start with quantities, units and representation; builders can follow the contracts, rounding checkpoints and invariants; reviewers can begin with the worked ledger and the failure diagnosis; students can attempt the independent exercise before reading its solution. The same test runs through all routes: can another person reconstruct the exact intended number without guessing its meaning?
Contents and learning routes
1. Start with quantity, not a string
A model may see the string 12.5, but a real workflow must ask what 12.5 denotes. It might mean twelve and a half kilograms, a temperature in degrees Celsius, 12.5 Singapore dollars, 12.5 percent, or a ratio with an unstated denominator. The characters are not enough to know whether addition, comparison or conversion is valid. A safe record therefore couples the magnitude to a quantity kind, unit or currency, precision, source, effective date and permissible operation. Two fields can share the same apparent numeric type while remaining impossible to add meaningfully.
Imagine an ordering assistant receives 14 items, an amount of 14 dollars, and a measurement of 14 metres. It should not infer a combined total of 42. The error is dimensional, not arithmetical. The receiving system must reject the operation before the language model writes a persuasive explanation. Define which values may be counted, which may be multiplied by a unit price, and which may be compared only after conversion to a common unit. If the user’s intent is unclear, request the missing unit instead of guessing it from surrounding prose.
Every quantity needs a declared reference point. Is a rate per hour or per completed job? Does a fee include tax? Is a temperature an absolute scale reading or a temperature difference? These distinctions become particularly important when an agent calls tools whose field names are short or inherited from an older API. Put the meaning in the schema and its documentation, not in a fragile prompt.
2. Why a correct-looking float is not an accounting contract
Many programming environments use binary floating-point numbers for ordinary calculations. That representation is excellent for large classes of scientific and graphical work, but some common decimal fractions do not have finite binary representations. Python’s official decimal documentation illustrates why 0.1 plus 0.1 plus 0.1 may not compare exactly equal to 0.3 when represented as binary floats. This is a property of representation, not a mysterious language-model arithmetic failure. When exact decimal equality is an invariant, use a suitable decimal or integer-minor-unit representation instead.
This does not mean every scientific calculation should use decimal arithmetic. Sensor data often arrives with uncertainty much larger than machine rounding error, and numerical algorithms frequently depend on well-understood floating-point methods. Choose the numeric form according to the task. For a financial ledger whose smallest permitted posting unit is a cent, an integer number of cents can be robust if the range and currency are explicit. For decimal fractions with configurable rounding, a decimal type may be more readable. For continuous measurements, a floating-point value plus units, significant precision and uncertainty may be appropriate.
The contract should specify whether non-finite values such as not-a-number or infinity are legal. Usually they are not acceptable as monetary totals, quantities of packages or human-facing approval thresholds. Reject them before storage. A blank value also differs from zero: zero asserts a measured or calculated amount, while blank may mean not recorded, not applicable or not yet approved.
3. Make dimensional analysis executable
Dimensional analysis is the simple discipline of keeping compatible units together. Adding four metres to three kilograms is invalid, regardless of the numerical result. Multiplying distance by price per metre can produce a price, while dividing distance by time produces speed. These relationships should be checked by typed functions or a validated unit library rather than inferred from prose. The labels must be specific enough to distinguish mass, time, area, volume, count, money and ratios.
Consider six packages of 0.75 kilogram each and a separate 320-gram padding allowance. Six times 0.75 kilograms equals 4.50 kilograms. Three hundred and twenty grams equals 0.320 kilograms. The combined physical mass is 4.820 kilograms. Treating 320 as kilograms would overstate the padding by a factor of one thousand. A text answer that merely displays 324.5 without units could conceal this mistake; a dimensional contract would flag it before shipment planning.
Conversions also have direction and context. A conversion between kilometres and metres uses a dimensionally valid multiplicative factor, but a conversion involving temperature requires special care with offsets. A currency conversion is not a timeless physical conversion: it needs an exchange rate, direction, source and timestamp, as well as a rule for rounding after conversion. Do not hide any of those decisions inside a single unlabelled multiply operation.
4. Separate accuracy, precision and display
Accuracy asks whether a value is close to the relevant truth; precision describes the resolution or repeatability of its representation or measurement. Showing eight decimal places does not create eight decimals of reliable evidence. If a ruler measured a table to the nearest centimetre, reporting 1.234567 metres implies information the measurement never supplied. The agent must preserve the source’s resolution and state when subsequent arithmetic merely generates extra digits rather than extra certainty.
A monetary total has a different reason for its display scale: a settlement system may require currency-specific minor units even if intermediate calculations carry more digits. Keep unrounded intermediate values where the policy requires them, then apply the explicitly declared rounding checkpoint. Avoid carrying a rounded display string back into the calculation as if it were the original measurement. The database may hold 493.92 while the interface prints 493.92; those equal-looking strings have different roles as a durable authoritative value and a view.
When comparing outputs, distinguish formatting differences from substantive disagreement. The strings 4.5 and 4.50 may denote the same mathematical magnitude but different implied reporting precision. Commas, spaces and locale-specific separators may turn 1,250 into an ambiguous number. Parse under an explicitly selected locale, then store a canonical representation with the original text retained as evidence.
5. Choose the rounding moment before computing
Rounding is a business or scientific rule, not something the assistant should improvise. Different permitted rules may round a midpoint upward, to an even last digit, toward zero or in another direction. Python’s decimal context exposes these alternatives explicitly. PostgreSQL also documents important differences in the rounding behaviour of numeric and floating-point values. A workflow should declare its rounding mode, precision and stage: per input, per line, per tax class, per document or only at final settlement.
Take two fictional items costing $0.05 each with a 10 percent discount and a rule that rounds positive midpoint cents upward. Each item’s discount is $0.005; rounding each line to cents produces $0.01 plus $0.01, or $0.02. If the policy instead calculates a basket discount, 10 percent of $0.10 is $0.01. The two legitimate policies differ by one cent. No amount of model confidence can decide which is right; the agreed policy must choose one before calculation.
Never fix such a difference by quietly modifying the last line until the total looks right. If allocation to lines is required, use a documented residual-allocation rule, preserve the pre-allocation amounts and verify that the allocated sum equals the authoritative total. A reviewer should be able to reconstruct why a particular line received the residual cent.
6. Treat money as amount plus currency plus rules
A value of 50 without a currency is not a payment instruction. Keep ISO currency identity where relevant, but do not assume all currencies use two minor decimal digits or that every external service accepts the same numeric encoding. A payment gateway may expect integer minor units, an accounting interface may expect decimal strings, and a report may display formatted symbols. The agent should map between these representations using a tested boundary adaptor and never infer a unit from a symbol alone.
An amount is also affected by its treatment. Was a discount applied before tax? Is a fee taxable? Is a refund based on the original charged amount or a recalculated schedule? This article is about computation integrity, not about advising any jurisdiction’s tax rules. Our worked example uses a fictional 9 percent rate solely to exercise a chosen calculation convention. Production systems must obtain the correct legal and contractual treatment from the qualified authority and effective rules for the actual transaction.
Use a ledger entry with an immutable transaction identifier, amount, currency, calculation-policy version, source document reference and approval state. Negative values should have declared semantics. A refund of 10 is not always the same operation as a negative purchase of 10; some controls and receipts differ even when the arithmetic cancels.
7. Use one canonical calculation engine
A language model can describe the intended formula and help users supply missing parameters, but deterministic software should perform and attest the arithmetic that affects an external record. Define a calculation service with an input schema and an output record containing both result and calculation trace. It should validate ranges, units, currency, allowed rate precision, rounding mode and policy version. The agent submits structured inputs, receives a calculation receipt, and presents that receipt without rewriting the numbers.
Two agents may derive the same amount from different documents, yet only one system should determine what is authoritative. Establish an owner for the calculation and a stable operation ID so an uncertain retry does not create two postings. Require read-after-write verification for any consequential ledger change. If the service returns an ambiguous timeout, query by the original operation ID rather than inventing a new one. This links numerical integrity with the existing idempotency and reconciliation chapter.
A useful receipt records source-value hashes or references, intermediate exact decimals, rounded values, the final unit and the policy. Avoid claiming cryptographic verification unless a signature or hash has actually been computed and checked. A plain text explanation is helpful to a person but does not substitute for an auditably reproducible calculation.
8. Worked laboratory: start from a fictional order
Consider a teaching order with 23 notebooks priced at $19.95 each and nine folders priced at $7.40 each. The currency is an illustrative dollar unit. The quantities are exact counted integers. Multiply 23 by 19.95 to obtain 458.85. Multiply nine by 7.40 to obtain 66.60. Add those line extensions to obtain a subtotal of 525.45. A validator checks that both line extensions match quantity times unit price, not merely that the two supplied extensions sum to the supplied subtotal.
Assume this fictional contract grants a 6 percent discount on the subtotal, rounded once to cents using decimal half-up. Six percent of 525.45 is 31.527. Round that discount to 31.53 and subtract it, yielding 493.92. Assume, for this classroom example only, a fictional 9 percent tax applied to that discounted base and rounded once. Nine percent of 493.92 is 44.4528; the rounded tax is 44.45. The final total is 493.92 plus 44.45, or 538.37.
The important evidence is the chain of explicitly stated operations, not the final number by itself. If a record instead showed a total of 538.38, an agent should not declare a mysterious one-cent discrepancy or alter a line to fit. It must identify whether the input values, discount rounding, tax base or rounding checkpoint differed. That is a tractable investigation because every branch is described.
9. Reconcile the example as independent invariants
Build four independent assertions from the order. First, each extended line amount must equal its authorised quantity multiplied by its unit price. Second, the subtotal must equal the sum of all rounded-or-unrounded line amounts according to the chosen policy. Third, the net amount plus discount must equal the subtotal: 493.92 plus 31.53 equals 525.45. Fourth, the net plus rounded tax must equal the payable amount: 493.92 plus 44.45 equals 538.37. A check that merely asks the language model whether the total looks reasonable is not independent.
Now suppose the uploaded invoice states 538.37, the database contains 538.37, but the bank receipt is absent. Arithmetic verification does not prove payment occurred. A financial action needs a separate reconciliation against the authoritative settlement event or ledger. Numeric integrity limits one class of mistakes; it does not create a missing business fact. Similarly, a perfect bank total cannot prove the purchaser authorised the goods, the price or the tax treatment.
A good review screen separates source evidence, computed amount, settlement evidence and outstanding uncertainty. A missing receipt should be labelled unverified rather than silently treated as zero or as success. This separation prevents an agent from turning a correct computation into an overconfident assertion about the real world.
10. Denominators are part of a percentage
Percentages are incomplete unless the denominator is explicit. If a team successfully completes 84 of 120 assigned tasks, the completion rate is 84 divided by 120, or 70 percent. If an automation handles 11 errors among 48 attempted changes, the relevant fraction is 11 divided by 48, about 22.92 percent. Combining those values without the original counts is not mathematically justified. The samples measure different events and may have different eligibility rules.
Even apparently compatible rates cannot always be averaged. Suppose queue A completed 90 of 100 tasks and queue B completed one of ten tasks. Their unweighted average percentage is 50 percent, but combined completion is 91 of 110, or about 82.73 percent. The first answer describes the average of two queue rates; the second describes the share of individual tasks completed. An analyst must state the reader question, unit of analysis and denominator before selecting a summary.
Rate records therefore carry numerator, denominator, inclusion rules, time window, missing-data handling and rounding/display precision. If the denominator is zero, the rate is undefined rather than automatically zero. If eligibility changed midperiod, split the periods or explain why an aggregate remains meaningful.
11. Preserve versions of rates and rules
A number that was right on Monday may be wrong for a transaction evaluated under Tuesday’s rules. Exchange rates, service tariffs, authorised discount tables and tax assumptions need effective timestamps and policy identifiers. Save the version used at the moment a consequential calculation was authorised. Recomputing a historical bill using the latest settings can generate an amount that does not match the original agreement, even if the new arithmetic is flawless.
Separate event time from processing time. A delayed message received after a rate update may refer to an earlier authorised transaction. The agent must check whether policy follows order creation, shipment, settlement or another explicitly defined event. Do not guess from the newest row in a database. This is a specialised numerical application of event time and effective-date reasoning.
Version comparisons should not hide corrections. If an input was factually wrong, preserve the original, a reason for correction, the new authorised value and any resulting adjustment record. Replacing history with a single recalculated figure makes later auditing unnecessarily difficult.
12. Keep calculation and presentation separate
The authoritative number should not depend on how a browser, spreadsheet or mobile phone chooses to format it. A user-facing screen might display 1,234.50, while another locale displays 1.234,50. A robust parser accepts only declared formats; it does not infer separators from a nearby place name. Dates in the same record deserve equally explicit treatment. Round only once at the prescribed stage; formatting for display should not silently become another calculation.
A model-generated table can make values appear aligned while the underlying columns shift. Bind each field to a stable machine-readable key and display unit, then make the interface show which source row was used. If a calculation has a condition such as a discount cap, display the cap and whether it was triggered. This helps a reviewer catch an incorrect assumption without reading code.
Accessibility is also part of numerical integrity. A screen reader should announce the currency or unit with the value rather than reading a contextless sequence of digits. A changed value should be marked clearly in a form. A good interface reveals important uncertainty and errors without relying on red colour alone. Human attention is scarce; provide the facts needed to make a decision.
13. Distinguish an estimate from an authorised amount
Many agent tasks begin with estimates: expected travel time, projected costs, likely energy use or approximate material volume. An estimate should be labelled as such and carry the assumptions that made it possible. Converting that estimate into an invoice, procurement order or public commitment requires a distinct authorisation and often fresh measurements. If the assistant treats a predicted value as a verified obligation, precise decimal arithmetic will only produce a precisely expressed mistake.
Use state names such as estimated, measured, calculated, reviewed, authorised and settled. Each transition must have its own evidence and owner. An estimate of 15 kilograms may become a measured 14.6 kilograms; that is not necessarily an arithmetic correction but a new observation. A human reviewer needs to know whether an update reflects new evidence, a formula correction or a changed policy.
A useful agent explanation makes the state transition visible: here is the input, here is the formula and rounding rule, here is the independent verification, and here is the action that still needs human authority. Never let an eloquent narrative replace the record of who approved what.
14. Build a boundary contract for every tool
A numerical tool call should carry a schema resembling amount, currency, quantity, unit, effective date, source reference and policy version rather than only a free-text command. Reject missing required fields, unknown units, contradictory units, overflow, negative quantities where prohibited and unexpected precision. Validate after the model forms the request and again when the tool receives it. Client-side validation is helpful to the user, but the protected service must enforce its own rules.
Do not solve validation by converting every incoming value into a plain JavaScript number or generic float first. That can lose precision before the rule runs. For decimal currency, parse an allowed decimal string or integer-minor-unit field into the chosen exact representation. Preserve the submitted bytes or canonical normalised value as required for traceability. Normalize only when a specific specification defines how normalisation works.
Require the tool response to identify success, rejection or uncertainty. When it rejects an input such as 9.999 units at a two-decimal boundary, the agent should report the actual rule and the rejected field rather than quietly rounding the user’s request into a different instruction. A separate approved conversion can be offered when that change is explicitly authorised.
15. Numerical tolerances are not universal permission
In scientific computation, exact equality may be unreasonable because of rounding and measurement uncertainty. A tolerance should have a named purpose, unit and numerical scale. An absolute tolerance of 0.1 metres is very different from a relative tolerance of 0.1 percent. For each comparison define whether either tolerance applies, what happens near zero, and whether the allowed error accumulates across stages.
For monetary ledger invariants based on stored integer cents, equality is often an appropriate strict check. A tolerance of one cent could accidentally make an actual missing posting look acceptable. In contrast, a sensor estimate of 1.20 metres plus or minus 0.02 metres should not be rejected merely because an independent sensor reports 1.21 metres, provided the measurement method and uncertainty bounds are consistent. The decision is scientific or contractual, not cosmetic.
Consider a calculated distance of 100 metres and an observed value of 100.4 metres. The absolute difference is 0.4 metres; the relative difference against a declared 100-metre reference is 0.4 percent. Whether that passes depends on the specific task. An agent must not invent a threshold after seeing the result.
16. Diagnose failure at the earliest wrong boundary
When results disagree, locate the first divergent step: parsing, unit conversion, lookup, multiplication, rounding, aggregation, posting or presentation. For example, if a subtotal is correct but a tax amount differs, inspect the tax base, rate effective date and rounding mode before examining unrelated line items. If the human-visible receipt is wrong but the machine ledger is right, inspect the rendering layer. If the stored amount is wrong, correct the authoritative record through an approved adjustment, not merely the display.
Create a small diagnostic set. Submit a value with an unexpected unit, a negative count, a midpoint rounding case, a blank denominator, a stale rate and a duplicated transaction ID. The expected outcomes should be specified in advance: reject, abstain, hold for review, compute or reconcile. An agent that always returns some number fails this test even when it frequently gives plausible totals.
Different failure modes demand different repairs. A missing source requires evidence retrieval. A precision bug requires a representation or algorithm change. An unauthorised rate requires governance, not just recalculation. A repeated posting requires reconciliation against actual effects. Keep these root causes separate so a local fix does not conceal a deeper system problem.
17. Design tests for every mathematical edge
Ordinary happy-path tests are necessary but insufficient. Include zeros, very large magnitudes, the smallest allowed nonzero amount, negative values where meaningful, boundary discounts, midpoints, values just below and above a threshold, and same-value inputs represented in different accepted forms. Property-based testing can verify invariants such as total equals the sum of components and converting a quantity to another unit and back preserves the expected value within a declared precision limit.
Test rounding with deliberately chosen ties. For a half-up rule, the exact decimal value 1.005 becomes 1.01 when rounded to two decimal places, while 1.004 becomes 1.00. Do not feed a binary float approximation into this test and then blame the rule for a surprising result. Use exact decimal inputs for an exact-decimal contract. For a half-even rule, document a different expected midpoint result where appropriate.
Introduce an uncertain external response. The operation may have posted successfully even though the client timed out. The expected behaviour is to inspect the operation identity and stored amount before retrying. If the system cannot establish whether a posting happened, it should pause or escalate, not produce a second amount and hope that one will be correct.
18. An engineering acceptance gate
Before an AI-assisted amount can trigger a consequential action, ask a series of concrete questions. Are all input quantities sourced and authorised? Are dimensions and currency valid? Are denominators explicit? Does the versioned formula use the correct effective policy? Was rounding applied at the specified checkpoint? Were totals independently recomputed? Does the operation ID already have a receipt? Are the downstream effects known? A failure on a critical gate should block the action rather than lower the explanation’s confidence score.
The gate should return structured reasons rather than a single opaque verdict. A human reviewer may need to know that the subtotal and arithmetic pass but the effective rate cannot be established. This is more useful than an overall ’97 percent safe’ statement with no defined meaning. Numeric integrity can be demonstrated for a particular calculation path; it does not imply the entire agent system is safe or the real-world claim is true.
Keep the acceptance criteria stable across deployments and explicitly version them. If a new field or unit is introduced, test how older readers behave. A schema mismatch should be visible, not silently interpreted as zero. Small boundary decisions are precisely where a powerful assistant can create expensive errors despite apparently fluent reasoning.
19. Independent practice: two calculations with different answers
Practice case A: a fictional service charges 18 items at $8.25 each, discounts the subtotal by 5 percent and rounds the discount once to cents using half-up. Compute the line subtotal, exact discount, rounded discount and net amount. The subtotal is 18 times 8.25, or 148.50. Five percent is 7.425, rounded to 7.43. The net amount is 141.07. This is an arithmetic exercise with a declared fictional policy, not an actual invoice or legal tax instruction.
Practice case B: the same service changes the rule so the 5 percent discount is rounded separately for each $8.25 item. Five percent of one item is 0.4125, which rounds to 0.41. Eighteen line discounts total 7.38, and the net becomes 141.12. The two policies differ by five cents: 141.12 minus 141.07. The lesson is that selecting a rounding stage is an input to the calculation. A model asked for ‘the discounted amount’ without that rule cannot safely select one.
Ask yourself what evidence is needed to choose the correct case. The answer is not a higher-temperature model response; it is the agreed discount policy and any relevant external rule. The unit price, item count, currency, rate, rounding mode and stage must all be available to the calculation service.
20. Changed-context transfer: material preparation
Transfer the method from money to physical units. A workshop plans to prepare 24 identical tubes, each nominally 0.375 metres long. The nominal total length is 24 times 0.375, or 9.000 metres. Suppose each tube may be between 0.373 and 0.377 metres according to a specified tolerance. The plausible total interval under a conservative all-at-the-extreme assumption runs from 24 times 0.373, or 8.952 metres, to 24 times 0.377, or 9.048 metres. Do not claim that every outcome in this interval is equally likely or that errors are independent; those would require additional evidence.
A worker instead reports 9,000 millimetres. That is equivalent to 9.000 metres, so the units reconcile. A report of 9,000 centimetres would mean 90 metres and should be rejected as inconsistent with the nominal design. A supplier quotation in kilograms cannot be compared against the length without material density and cross-sectional information. The numeric-contract approach catches all three classes of confusion: conversion, implausible magnitude and incompatible dimensions.
Changed condition: only 20 tubes are built. The nominal length is now 20 times 0.375, or 7.500 metres, with a conservative interval from 7.460 to 7.540 metres under the same per-tube bounds. Recompute from the updated count; do not scale a previously rounded display total without recovering the authoritative inputs.
21. The human role remains substantive
An agent can help explain why a stored sum differs from a printed sum, but the person accountable for the transaction must be able to see the exact discrepancy and its cause. Review should focus on decisions that software cannot authoritatively infer: the true unit in an ambiguous message, whether a promotional exception is approved, which source document controls a dispute and whether a physical measurement is trustworthy. Routine exact arithmetic belongs in reproducible code, freeing human attention for evidence and judgment.
For education, this method links school algebra, percentages, measurement and dimensional analysis to software engineering. Students can practice by writing the formula first, specifying units and denominators, and testing a case that should fail. For work, it connects to finance operations, logistics, laboratory informatics, engineering quality and trustworthy AI product design. The transferable habit is to ask what the number means before asking whether the arithmetic looks right.
Read the Super Intelligence curriculum for the wider engineering context, the How X Works master hub for connected systems and the education-and-transfer guide for using classroom principles outside a worksheet.
Frequently asked questions
Is an AI model allowed to do arithmetic?
Yes. It can propose a calculation and explain its structure, but a consequential numerical result should be checked by a deterministic routine or independently verified tool with the appropriate units, precision and authority.
Should every number be rounded to two decimals?
No. Two decimals are not universal even for currency, and they are often inappropriate for physical measurements or intermediary arithmetic. Declare the domain-specific precision and the exact stage at which rounding occurs.
Why does a correct subtotal not prove an invoice is valid?
Arithmetic does not prove the prices were authorised, the tax treatment was correct, the goods were delivered or a payment settled. Those are separate evidence and approval questions.
Can small numerical errors be ignored as tolerance?
Only when the tolerance is defined for that quantity and decision in advance. A scientific measurement may permit bounded error; a ledger invariant in integer cents should usually remain exact.
What if the tool returns a correct number but no receipt?
Keep the computation result separate from proof of the external action. Reconcile by the stable operation identity; if the posting cannot be verified, mark the effect uncertain and avoid an automatic duplicate retry.
Does a more capable future model remove these controls?
No demonstrated artificial superintelligence currently removes the need to specify units, contract semantics, external authorisation and verifiable outcomes. More capable systems can still interact with inconsistent sources and services.
Verified primary sources and further reading
Python decimal module: exact decimal representation, contexts, rounding and signals. This source supports the technical mechanism, not the fictional figures used in the worked cases.
PostgreSQL numeric data types: exact numeric and floating-point behaviour. This source supports the technical mechanism, not the fictional figures used in the worked cases.
NIST AI Risk Management Framework: governance, mapping, measurement and management. This source supports the technical mechanism, not the fictional figures used in the worked cases.
Python floating-point tutorial: why decimal-looking values may be approximate. This source supports the technical mechanism, not the fictional figures used in the worked cases.