By Sandeep Dhuri
Ask an AI assistant to "calculate the order total" in any mainstream language and, more often than not, you will get binary floating point: double, float, number. It is the most common representation of money on the public internet, so it is the most common completion. It is also wrong for money in every regulated domain, for a reason IEEE 754 makes non-negotiable: 0.1 + 0.2 ≠ 0.3 in binary floating point. The error is tiny per operation and compounding at scale. Reconciliation drift, rounding disputes, audit findings.
Delta's Law 5 states it in five words: “No float for money. No exceptions.” The corollary the book builds on: types are constraints. (A generation of engineers learned the failure mode from a movie: the salami-slicing scheme in Office Space is, mechanically, a rounding story. The float made it plausible.) Two moves implement it.
Move 1: say it in the prompt
The model cannot honor a constraint it never received. Every prompt that touches monetary values carries one line in its constraints block:
“No float for money. No exceptions.”
Monetary values MUST use exact decimal representation (C#: `decimal`; Java: `BigDecimal` or integer minor units; Python: `decimal.Decimal`; TypeScript/JS: integer cents or a decimal library). Binary floating point (`double`/`float`/`number`) for money is prohibited. Rounding: banker's rounding at aggregation boundaries only, per [your policy].
That single constraint changes what "plausible" means for the model. Veracode's 2026 report findings on why models fail security tasks apply here exactly: the training corpus encodes the historical pattern, and only your stated constraint outweighs the corpus.
Move 2: make the type system enforce it
Prompts steer generation; types catch what steering misses. The book's pattern is a domain Money type whose float-based constructors exist but are marked unusable — in C#, an [Obsolete(error: true)] constructor taking double, so any AI- or human-written code that tries to build Money from a float fails to compile with a message explaining why. Java: a Money wrapper over BigDecimal/long-cents with no float factory. Python: a Money dataclass that raises on float input. TypeScript: a branded Cents integer type. The companion repository (MIT-licensed) has all four, with tests.
The pairing matters more than either half. The prompt constraint prevents most bad generations; the poisoned constructor converts the survivors from silent drift into a compile error. From the most expensive failure class to the cheapest. That is the general shape of Delta's approach: specification first, verification designed into the artifact, so "looks right" is never the last gate.
Why this is worth an article-sized habit
Because the ambient rate of the underlying failure class is not falling. Across 2025–2026, the share of AI code-generation tasks introducing a known vulnerability held near 45% (Veracode, 150+ models), and AI-attributable CVEs are accelerating month over month (Georgia Tech's Vibe Security Radar: 6 in January 2026, 35 by March). Float-money is the same phenomenon in financial clothing: a correctness constraint the corpus does not encode and the model will not supply unbidden. One constraint line and one type close it permanently.
I have chased this exact cent-drift through three different codebases over the years. Every commit message in the fix was an apology.
Adapted from Delta: Closing the Specification Gap (Dhuri, 2026), Law 5 and Chapter 4 — free: https://acuity.press · DOI: 10.5281/zenodo.21584309. Companion code (MIT): github.com/sandeep-dhuri/specification-frame.
Sources: Veracode, 2026 GenAI Code Security Report (2026); Georgia Tech SSLab, Vibe Security Radar (2026).