The Loans & Credit Pack: Eight Models and the Cent That Mattered

Loan math looks like one calculator from the outside. From the inside it is eight distinct decisions, each with its own edge cases — and the interesting engineering is in the conventions that keep all eight honest.

The loans and credit pack shipped as eight models, built on the published amortization, growth, and payoff primitives and verified the same way as everything else in the catalog: a spec per model, an independent second implementation, two hundred fifty agreed cases per model per release. The roster: auto loan, loan comparison, extra-payment impact, biweekly mortgage, points break-even, PMI removal, ARM versus fixed, and credit-card minimum payment.

The cent that mattered

The pack's most instructive engineering decision is invisible in every answer: simulated payments round up to the next cent. The first draft rounded half-up, the way most code rounds money. The pack's pre-release adversarial review — a reviewer with fresh context, no authorship stake, and instructions to break things — found the flaw: a payment rounded down by half a cent can land at or below the monthly interest accrual on knife-edge inputs, and a loan whose payment never exceeds its interest never amortizes. Both implementations would have shared the flaw, because both implement the spec faithfully — the class of bug that dual implementation cannot catch, and exactly what the adversarial layer exists for.

The fix is the servicer convention, now in each affected spec: payments round up to the cent, which guarantees amortization by the stated term and kills the knife-edge. The extra-payment spec records the finding and the fix in its known-issues section, and every affected spec states the convention in its computation rules — a verification story you cannot audit is just a story.

“Dual implementation catches disagreement. It takes an adversary to catch agreement on the wrong answer.”

Sentinels with a design rule behind them

The points-break-even model answers whether paying points recovers its cost in monthly savings. When the reduced rate saves nothing, there is no recovery month — and the model returns Infinity, exported as the string "Infinity", rather than a magic number. The design rule, applied pack-wide after review: a finite sentinel is only legal where legitimate values are bounded. An early draft used 9999, and the review killed it — real break-evens are unbounded, so any finite stand-in could collide with a legitimate answer. Free points that save nothing break even at month zero, a separate rule the spec states so the boundary case has one defined answer.

The credit-card-minimum model faces the opposite problem: its simulations are capped at a twelve-hundred-month defensive horizon, so a payment path that never retires the balance would truncate silently. The contract makes the truncation impossible to misread — two booleans, one per payment path, are the authoritative never-pays-off signals, and the spec's constraint note tells integrators to never compare month counts to the horizon. The minimum-payment formula itself is the modern convention — interest plus a percentage of the balance, with a dollar floor — chosen over the pre-2003 pure-percentage formula precisely because the older convention produces the negative-amortization pathology regulators pushed issuers away from.

• ✓Amortizing payments in the extra-payment, biweekly, and PMI-removal simulations round UP to the cent — the servicer convention, adopted after adversarial review.
• ✓points-break-even: never = Infinity (the string form in JSON), never a finite magic number; free points that save nothing = month 0.
• ✓credit-card-minimum: the two never-pays-off booleans are authoritative; month counts truncate at a defensive horizon.
• ✓arm-vs-fixed: an initial period longer than the term minus twelve months is rejected — never silently shortened.
• ✓All eight: out-of-domain inputs are rejected with structured errors, never clamped.

Scenario models, labeled as such

The ARM-versus-fixed model prices one specific scenario: the rate adjusts once, at the end of the initial period, to a caller-supplied rate, and stays there to payoff. It does not project index paths, caps, or margins — it answers what if it adjusts to X and stays there, which is the question a borrower can actually reason about, and the spec says so plainly. The constraint that the adjustment happen at least a year before payoff is enforced by rejection: a violating request returns an error naming the rule, because a model that silently shortens your initial period has answered a question you did not ask.

The loan-comparison model carries the pack's most repeated caveat in its own constraint note: costs are lifetime nominal dollars, undiscounted, and comparing offers with different terms ignores time value — a longer loan's lower nominal total can still be worse in present-value terms. The note travels in the machine-readable contract, so an integrating UI can render the warning without having read the spec prose.

Small models, sharp edges

The remaining models earn their places with specific conventions. The auto-loan model applies sales tax to the price net of trade-in — the trade-in tax-base rule most states use and most quick calculators skip. The PMI-removal model runs scheduled amortization only, to the caller's choice of the eighty or seventy-eight percent loan-to-value threshold, with extra-payment acceleration named as an exclusion rather than half-implemented. The biweekly-mortgage model implements the honest version of the thirteen-payments trick — the equivalent extra monthly principal — and its spec excludes the enrollment fees that third-party biweekly programs charge for automating what a borrower can do free.

Every response in the pack carries the standard envelope: spec version, assumptions naming that version plus any constraint notes, sentinel annotations where the spec defines them, and the record.sha256 over model, spec version, inputs, and outputs that makes any stored answer recomputable byte-for-byte.