Page actions
instrument mechanism / verified-clean
Grocery Recipe Cost Estimator mechanism
The inspectable method record for Grocery Recipe Cost Estimator, kept separate from implementation and qualification.
Model scope
The honest label is directionally accurate because prices are user-entered and may become stale. It should additionally state that results are prorated estimates based on entered package prices and quantities, require compatible units, exclude taxes and shopping-package effects unless entered, and may be rounded for display. Add validation requiring purchase_qty > 0 and servings > 0, and define currency and rounding rules before release.
- The formulas are standard and correct when each ingredient's used quantity and purchase quantity use the same compatible unit.
- The specification does not define unit normalization or how incompatible units such as grams versus milliliters should be handled.
- The specification does not define monetary rounding or precision for displayed costs.
- The meaning of total cost should be labeled as prorated ingredient consumption cost, not necessarily the amount required to purchase complete packages.
Units and conventions
- ingredient_qty_used and purchase_qty must represent the same physical quantity dimension for each ingredient, such as grams with grams, milliliters with milliliters, or items with items.
- Unit conversions such as kilograms to grams and liters to milliliters are assumed to be performed before applying the ratio.
- purchase_price is assumed to be the price for the entire stated purchase_qty, in one currency.
- servings is assumed to be a positive count of servings.
- All prices and quantities are assumed nonnegative.
Inspectable vector
One of 4 source-bound review vectors:
{
"inputs": {
"ingredients": [
{
"name": "flour",
"purchase_qty": 2,
"purchase_unit": "kg",
"purchase_price": 4.8,
"qty_used": 0.5,
"used_unit": "kg"
},
{
"name": "sugar",
"purchase_qty": 1,
"purchase_unit": "kg",
"purchase_price": 2.5,
"qty_used": 0.2,
"used_unit": "kg"
},
{
"name": "eggs",
"purchase_qty": 12,
"purchase_unit": "count",
"purchase_price": 3.6,
"qty_used": 3,
"used_unit": "count"
}
],
"servings": 8
},
"expected_outputs": {
"total_cost": 2.6,
"per_serving": 0.325
},
"working": "Flour: (0.5 kg / 2 kg) × $4.80 = 0.25 × $4.80 = $1.20. Sugar: (0.2 kg / 1 kg) × $2.50 = 0.20 × $2.50 = $0.50. Eggs: (3 / 12) × $3.60 = 0.25 × $3.60 = $0.90. Total cost = $1.20 + $0.50 + $0.90 = $2.60. Per serving = $2.60 / 8 = $0.325."
}Failure boundary
BREAK_CLAIMED · SELF_FLAGGED
The formula has an unhandled zero-denominator case when purchase_qty is zero, which can yield Infinity in plain JavaScript instead of a rejected input. Mixed quantity units can also produce a 1,000-fold cost error if no unit convention or conversion is enforced.
Other records
Sources and evidence
These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.
VERIFIED_LEDGER.jsonevidence-tranche5/tranche5-results.jsonBOUNDARY_HAZARD_CATALOG.json