Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

instrument mechanism / verified-clean

Grocery Recipe Cost Estimator mechanism

The inspectable method record for Grocery Recipe Cost Estimator, kept separate from implementation and qualification.

Status: VERIFIED_CLEANLifecycle: verified-clean

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.json
  • evidence-tranche5/tranche5-results.json
  • BOUNDARY_HAZARD_CATALOG.json