# Do Not Let Display Rounding Decide a Commodity Specification Check

A specification dashboard displays both the reported result and the contractual minimum as 12.5. Its status badge says “pass.” The original result, however, was 12.46: the interface rounded before the comparison.

That is a decision-rule defect even if every arithmetic operation was performed correctly. The application has silently replaced a recorded value with a presentation value.

**The records, limits and code below are synthetic examples for a hypothetical application. They do not describe a Zenith Eclipse system, a shipment or an agreed product acceptance rule.**

## Define the comparison contract first

For a numerical check, store the parameter, unit, reporting basis, method reference, specification revision, comparison operator and decision-rule version. Keep the source result text and document locator separately.

Zenith Eclipse's [milling wheat specification page](https://zenitheclipse.com/milling-wheat-supplier/) illustrates why those fields matter: protein has a stated moisture basis, while moisture and falling number answer separate questions. Its indicative enquiry targets are not a universal acceptance standard. Software should use the approved specification for the particular purchase.

This example deliberately implements only an unrounded minimum comparison after a reviewer has established that the measurements are comparable. It does not interpret measurement uncertainty, convert moisture bases or determine whether a laboratory's conformity statement is valid.

## Parse the original decimal text

Use a strict machine-input contract. Here, an unsigned percentage has at most three integer digits and four fractional digits, with a dot separator. The limits are application choices, not laboratory reporting requirements.

```python
import re
from decimal import Decimal, ROUND_HALF_UP

PATTERN = re.compile(r"[0-9]{1,3}(?:\.[0-9]{1,4})?")

def percentage(text):
    if not isinstance(text, str) or not PATTERN.fullmatch(text):
        raise ValueError("Expected a bounded decimal string")
    value = Decimal(text)
    if not Decimal("0") <= value <= Decimal("100"):
        raise ValueError("Outside percentage range")
    return value

def minimum_check(result_text, minimum_text):
    return percentage(result_text) >= percentage(minimum_text)

assert not minimum_check("12.46", "12.50")
assert minimum_check("12.50", "12.50")

display = percentage("12.46").quantize(
    Decimal("0.1"), rounding=ROUND_HALF_UP
)
assert str(display) == "12.5"
```

Python's [decimal documentation](https://docs.python.org/3/library/decimal.html) explains decimal construction, precision and quantization. Constructing from the original string avoids importing a binary floating-point approximation. Decimal arithmetic still has a precision context; it is not a promise of unlimited exact arithmetic.

The grammar also excludes NaN, infinity, exponents, commas and embedded whitespace. Rejecting those inputs does not mean all are intrinsically invalid measurements. It means this particular interchange format does not accept them. A user interface may support localized input through a separate, explicit parser.

## Keep three outputs separate

Store the original text, the parsed comparison value and the display string. A compact display should expose the full result on inspection. Never feed the formatted string back into the decision function.

If the agreed rule requires rounding before comparison, implement that as a named, versioned rule with an explicit rounding mode and stage. Do not borrow the user's display precision or silently add an epsilon to make borderline records pass.

A result such as “less than 0.1” is a qualified observation, not the exact decimal 0.1. Route it through a different model. Likewise, a missing value must not become zero. Where basis, unit or method compatibility is unresolved, the outcome should be “needs review,” not a numerical verdict.

## Make the decision reproducible

Record the input result identifier, specification revision, rule version and comparison output together. If a report is corrected, create a new decision referencing the amended evidence; retain the previous outcome for explanation.

Test exact equality, values immediately above and below the limit, trailing zeros, malformed input and locale-specific text. Add cases where two different values render identically. If a later calculation is introduced, test its precision and rounding independently from this comparison.

A passing numerical predicate establishes only that one approved comparison succeeded. It cannot release a lot, certify quality or substitute for the remaining contractual checks. The useful engineering boundary is narrower: the screen must never invent an acceptance rule through formatting.

---

**About the publisher:** [Zenith Eclipse Co](https://zenitheclipse.com/) works across agricultural commodities, international logistics and machinery sourcing.