The familiar economy formula does not rescue distance and fuel volume taken from different intervals. I first inspected whether the source’s confirmation input had an actual computational role.
The tool and its records distinguish a common fill basis from non-driving fuel. The shared example independently implements that relationship with fixed synthetic values; it does not diagnose a vehicle or establish savings.
Define the interval before the formula
The source requires beginning and ending odometer readings, interval fuel volume and an explicit common-basis confirmation. It rejects a non-increasing distance. This contract prevents precision-looking output from disguising mixed receipts and readings, while leaving actual measurement confirmation with the person or trusted caller.
The new measured_fuel function also requires explicit confirmation. It does not inspect tank levels or receipts. Its result describes caller-confirmed basis rather than claiming automated verification of the measurement. The presence of a checkbox must not be turned into a stronger statement about data provenance than the implementation supports.
Separate total fuel from driving fuel
The actual tool supports no adjustment, confirmed liters, or an estimate from non-driving hours and a caller’s rate. The independent shared example is narrower: it accepts confirmed liters only. That boundary avoids hiding the extra assumptions of an estimated rate behind an equally precise-looking result.
Total economy uses all interval fuel, while adjusted driving economy excludes the declared non-driving portion. These answer different questions. A larger adjusted ratio does not mean that actual fuel expense fell. The outputs keep original spending separate from the changed driving denominator instead of presenting the adjustment as a measured saving.
Inspect the denominator with fixed values
With synthetic distance one hundred and fuel twenty, the total ratio is five. Declaring five liters non-driving changes the driving ratio to one hundred over fifteen. Gross cost two hundred minus a confirmed deduction of twenty still leaves one hundred eighty; the denominator adjustment does not alter that spending.
Exact fractions preserve the ratios and only the displayed per-distance amount is rounded. The viewer exposes numerator and denominator as saved execution evidence. More digits do not reduce measurement error. I keep exact arithmetic separate from the trustworthiness of the supplied observations instead of calling both a single kind of accuracy.
Do not invent a deduction benefit
The original tool separates confirmed subsidies and discounts. The smaller contract accepts their declared confirmed total and rejects deductions exceeding gross cost. It does not determine eligibility or whether money was actually received. Entering a number must not establish that a real program or accounting treatment applies.
Non-driving fuel equal to or greater than total fuel, or a non-increasing distance, also fails. No unsupported default rescues the calculation. An unconfirmed input should postpone the result or remain a clearly stated scenario. Actual benefit rules or accounting guidance need separate current official verification; this code provides neither.
Share a way to inspect the record boundary
Local tests cover missing confirmation, invalid distance, excessive deductions and adjustment fuel, and unchanged spending after denominator adjustment. Historical project test counts are not presented as fresh success. The package contains the new implementation and actual fixed run records, not measurements collected in a vehicle or browser.
Other efficiency tools face a similar question: do electricity and production cover the same period, or raw materials and outputs the same boundary? I share a design that makes the beginning and end of the inputs inspectable before applying a familiar formula. That question is part of the program, not merely explanatory copy added afterward.