Skip to content
Recipe Timer Lab

Decision record · DR-002

Rebuild the three duration classes as under 35 minutes, 35 minutes to 4 hours, and over 4 hours

Status
Accepted
Date
2026-10
Applies to
scripts/common.py, scripts/prepare_data.py, web/src/lib/classes.ts, web/src/lib/rule-baseline.ts, /data

Decision in one line

Label each recipe from its listed total time with round thresholds of 35 minutes and 4 hours, chosen because they give class shares closest to the report's, and then sample the training set to the report's exact class counts.

Context

In 2021 the staff supplied each recipe with a label of 1 (quick), 2 (medium) or 3 (slow). The README that defined the cut-offs was lost with the rest of the bundle, and the report only gives the class counts of the 40,000 training recipes: 17,705 quick, 20,246 medium and 2,049 slow. The public crawl has a listed total time (an ISO 8601 duration such as PT1H20M) for each recipe, so the classes have to be rebuilt from minutes.

Decision

  • Quick is under 35 minutes, medium is 35 minutes to 4 hours inclusive, and slow is more than 4 hours.
  • Recipes published after 2018 (the end of Majumder et al.'s crawl), with no valid time, with a time over 30 days (entry errors) or with no name, ingredients or steps are dropped. That leaves 514,623 recipes, of which 42.0% are quick, 52.4% medium and 5.7% slow.
  • The training set is a random sample with exactly the report's class counts, and the 10,000-recipe hold-out set keeps the same proportions (4,426 / 5,062 / 512), all with seed 30027.

Options considered

  1. Quantile cut-offs that reproduce the report's shares exactly on the pool. Exact, but the thresholds would be odd numbers (such as 33.5 minutes) that nobody would choose.
  2. Round thresholds closest to the report's shares, then sample to its counts (chosen).
  3. Keep the natural class mix of the crawl. Simpler, but the class balance would differ from the report, and the slow class drives most of the report's discussion.

Why

Round thresholds are explainable to anyone who cooks: "under 35 minutes" and "over 4 hours" mean something. Sampling to the report's exact counts then removes class balance as a reason for the rebuild to differ, so the remaining differences come from the recipes and the features. The pool shares (42% / 52% / 6%) are close to the report's (44% / 51% / 5%), which suggests the staff thresholds were similar.

What happened

  • The minutes inside each class look sensible: the median training recipe takes 20 minutes in the quick class, 60 in the medium class and 430 in the slow class.
  • The thresholds are a guess. A model's accuracy depends on where the boundaries sit, because recipes near 35 minutes or 4 hours are the hardest to call. This is one of the reasons the rebuilt scores are lower than the report's (DR-001).
  • Listed times are entered by recipe authors and are noisy. Some include overnight chilling and some do not, so a share of the "errors" on every model is label noise that no model can fix.

What I'd change

  • Rerun the main models with the thresholds moved by plus or minus 5 minutes and 30 minutes, and report how much the scores and the findings move. That would turn the guess into a sensitivity analysis.
  • Measure label noise directly by hand-checking a small random sample of recipes against their method text.