AI trading numeric unit validation: check the meaning

AI trading numeric unit validation checks that parsed numbers use the intended asset units and percentage scales, then verifies relationships between fields. Convert only explicitly declared units, recompute derived amounts outside the model and reject unresolved disagreements. A valid JSON object can still confuse 0.5% with 50%, or base quantity with quote notional.

The difficult errors often look reasonable in isolation. A quantity is positive, a percentage falls within an allowed range and a claimed risk amount looks small. Together, however, they may describe different proposals. A useful validator checks the meaning of each number and the equations connecting them. The following review method and spot-trading example are hypothetical engineering designs, with invented prices and policy limits.

Define meaning before inspecting magnitude

A field needs more than a numeric type. Its contract should identify the asset or dimension, scale, reference and role. For example, a risk budget is a ceiling, while estimated loss at a specified stop is a measurement under assumptions. Those amounts can legitimately differ.

JSON Schema's numeric reference documents minimum, maximum and multiple-of constraints. They help constrain individual values. The application still needs a contract specifying what a particular number means and independent calculations connecting fields. For the broader parsing and schema boundary, use the structured-output validation guide.

Bind these meanings through trusted configuration and instrument metadata. A model-written unit label cannot redefine the consumer's contract. If a field allows several units, accept only an explicit supported choice and validate its conversion.

Normalize percentages once, with a declared scale

The following three inputs express the same proportion:

One percent is one hundredth; one basis point is one ten-thousandth. The conversion belongs to the declared scale, rather than to a guess based on magnitude. An unlabelled 0.50 is ambiguous: interpreting it as a fraction produces 50%, a hundred times 0.50%.

Keep the original text, original scale and normalized fraction in the calculation record. Downstream code should consume the canonical representation so another component cannot divide by 100 a second time. Do not change a field's established meaning during normalization; changes to contracts need the separate schema migration checks.

Also distinguish percentage points from relative change. Moving from 0.50% to 0.75% increases the value by 0.25 percentage points and by 50% relative to its starting value. A field called risk_change_percent needs to specify which question it answers.

Reconcile a proposal field by field

Assume a hypothetical spot-long candidate contains an entry price of 40,000 USDT per BTC, a stop price of 39,200 USDT per BTC and a quantity of 0.050 BTC. Independently supplied policy and account evidence establish 10,000 USDT equity and a maximum risk fraction of 0.005.

The candidate expresses its selected risk as 0.50 with scale percent. It claims 2,000 USDT notional, a 50-USDT risk budget and a 50-USDT planned stop loss. Suppose every field passes its selected schema, which accepts decimal strings and the declared scale. Now calculate from the inputs.

First check the assumed branch: quantity is positive and entry is above a positive stop. Then normalize the percentage and reconcile the derived amounts.

The units cancel in the multiplication: BTC times USDT per BTC produces USDT. Planned stop loss is 0.004 of the stated equity, or 0.4%. Its being below the 0.5% ceiling is consistent. The error is specifically the candidate's claim that this quantity and price distance produce a 50-USDT loss.

Reject that unreconciled candidate or return a separately identified correction for the required review. Do not silently alter quantity to make a claimed loss true. The stop-distance sizing guide covers calculating quantity from a chosen budget; this example checks whether a supplied quantity and its description agree.

These calculations exclude fees, slippage, gaps and uncertainty about stop execution. The 40 USDT is an illustrative loss at the specified prices, rather than a guaranteed maximum account loss. A cost-inclusive policy needs additional terms with named assets and assumptions.

Make invariants specific to field meaning

An invariant is a relationship that must hold under the selected contract. Use equality for a recomputed claim such as entry notional. Use an inequality for a ceiling such as planned loss being no greater than the risk budget. Requiring the two risk amounts to be equal would incorrectly reject a smaller permitted proposal.

Branch conditions matter too. The stop-below-entry rule above belongs to this long-loss example. Applying it indiscriminately to short positions would encode a different error. Likewise, the simple quantity-times-price equation assumes base-asset quantity. A derivatives contract count requires its documented multiplier and valuation formula before comparison.

Asset names are part of the unit. A 40-USDT amount and a 40-USD amount do not establish equality without an approved conversion basis. Even matching units do not prove that a price or equity observation is true or appropriate: resolve each observation against its trusted evidence record.

Venue rules add another independent layer. Binance Spot documents separate price, quantity and notional filters; its LOT_SIZE rule includes a quantity step, and MIN_NOTIONAL checks price times quantity under its documented conditions. Apply the actual instrument's rules from the Binance Spot filter reference when integrating that venue. Those rules do not establish that an AI proposal's risk claims reconcile.

Keep arithmetic exact and tolerances justified

Preserve decimal inputs through parsing and calculation. Python's decimal arithmetic documentation explains exact decimal representation and demonstrates that constructing a decimal from a binary float preserves that float's approximation. Parse original decimal text directly into the chosen representation, with sufficient working precision and defined rounding. The API decimal-precision guide develops that representation problem separately.

Also check that required inputs are finite and denominators are valid before calculating. A decimal parser can accept special values in strings even when the field contract forbids them. An equity-relative loss ratio is undefined when its equity denominator is zero.

Normalize units before comparing amounts. Retain full calculation precision and round for display according to an explicit rule. If reconciling a rounded reported amount, define an appropriate comparison interval from that reporting rule. A generic “close enough” epsilon should not enlarge a financial ceiling or excuse a factor-of-100 scale mistake.

Use rejection cases that a parser would miss

Start from the worked candidate with its planned-loss claim corrected to 40 USDT, then mutate one assumption at a time. These are proposed checks against a mocked submission boundary, rather than reported KLINEO test results.

Check evidence timing separately. Matching arithmetic can still use information that was unavailable at the decision time. Preserve the distinction between event, publication and ingestion timestamps described in the as-of evidence timing guide.

Record a numerical validation receipt

A candidate moves from parsed to normalized only after its units are recognized. It moves from normalized to reconciled only after the required equations and inequalities pass. An unresolved unit, invalid denominator or inconsistent claim stops that progression and produces no submission call.

Record the original payload, unit-contract version, trusted input snapshots, conversions, equations, unrounded results, reporting rules and rejection reasons. If a correction creates a new candidate, preserve its relationship to the original and run the checks again. This makes a later disagreement traceable to a specific interpretation or calculation.

Numerical validation also needs an authority boundary. A reconciled research result does not grant account-write permission; the tool least-privilege guide addresses that separate control.

Start with one real proposal format and write down the unit and role of every financial number. Recompute each derived field from trusted inputs, then introduce one scale error and one cross-field disagreement. The useful acceptance evidence is a correct calculation accompanied by an explicit reason for every stopped candidate.