Zero Is the Most Dangerous Sustainability Default in Recipe Data

Two fallback fixes changed the meaning of a score

Environmental estimates are starting to influence recipe ranking, meal-plan comparisons, grocery substitutions, and supplier reporting. That makes a quiet implementation detail newly important: what does the calculator do when it recognizes an ingredient or origin but cannot find an exact row in its reference data?

Two fresh Open Food Facts changes make the risk concrete. On August 6, its Forest Footprint 2026 calculator was fixed to match relevant ingredients found below a parent ingredient in the parsed ingredient tree. The updated fixtures show that adding previously missed palm-oil contributions can change not only a total but a letter grade. In one mixed-label fixture, the grade changed from b to d; in another fixture with an RSPO label, it changed from c to d.

On August 10, a second fix addressed origins that are present in product data but absent from the footprint table. An origin such as Africa, when the table contains country-level rows but no Africa row, had previously produced a zero origin footprint. The new behavior uses the method's unknown-origin value instead.

The repeated angle to avoid is the July article on this blog arguing that sustainability signals need ingredient-level provenance. That remains true, but it does not answer today's narrower operational question: how should an API represent the path from incomplete inputs to a usable estimate?

The thesis: recipe and grocery APIs should return environmental estimates as auditable fallback traces, not bare scalar scores, because hierarchy matching and missing-origin policy can legitimately change totals, grades, rankings, and substitutions even when the source recipe has not changed.

Source map

Fresh primary evidence from the last seven days:

Source	Date	Contribution
Open Food Facts parent-ingredient matching fix	2026-08-06	Shows that relevant child ingredients can be omitted from an aggregate when traversal stops at the wrong hierarchy level; updated fixtures demonstrate changed totals and grades.
Open Food Facts unknown-origin fallback fix	2026-08-10	Shows that a recognized but unsupported origin previously became zero and now falls back to the method's explicit unknown-origin value.

Older background context:

• Open Food Facts introduced the Forest Footprint 2026 calculation and ingredient-level knowledge panels in July. That launch explains the method context; the two new fixes reveal the fallback semantics API builders need to expose.

Missing, zero, unmatched, and inapplicable are different facts

A recipe API often receives a clean-looking result from an enrichment service and serializes it like this:

{
  "forestFootprintPerKg": 0,
  "grade": "a"
}

That response is impossible to interpret. Zero might mean a measured or defined zero. It might mean no relevant commodity was found. It might mean the ingredient parser missed a nested ingredient. It might mean the origin was recognized but unsupported by the method. It might be a programming default applied to a missing lookup.

At minimum, an environmental field needs distinct states:

State	Meaning	Safe aggregation behavior
observed_or_defined	The method has a value for the matched ingredient and origin	Include the value and its source.
fallback_unknown_origin	Ingredient matched; exact origin row did not	Include the configured fallback, but disclose it.
fallback_parent_ingredient	Exact food form lacked a row; a governed parent category supplied one	Include only if the method permits inheritance; return the path.
unmatched_ingredient	The parser or taxonomy could not connect the line to the method	Exclude from the point estimate and reduce coverage; never insert zero.
not_applicable	The method intentionally does not cover this ingredient class	Exclude, while distinguishing it from failed matching.
defined_zero	The method explicitly defines a zero contribution	Include zero with evidence; do not infer it from null.

This vocabulary matters beyond sustainability. Nutrition APIs face the same distinction between absent micronutrient data and measured zero. Grocery pricing systems face it between no price observation and a free item. The environmental case is especially sensitive because a false zero can improve a grade and rank an under-described recipe above a better-documented one.

Hierarchy traversal is part of the calculation contract

Recipe ingredients are trees, even when an API returns them as strings. Consider:

vegetable oils
├── palm oil
└── rapeseed oil

A calculator that checks only the top-level vegetable oils node can miss palm oil even though the parser found it correctly as a child. The August 6 fix is therefore not just a taxonomy patch. It changes the set of inputs included in an aggregate.

A robust API should expose both the observed identity and the method identity:

{
  "ingredient": {
    "observedId": "ingredient:palm-oil-and-fat",
    "parentPath": ["ingredient:vegetable-oils", "ingredient:palm-oil"]
  },
  "environmentalMatch": {
    "methodIngredientId": "forest-footprint-2026:palm-oil",
    "matchType": "parent_or_equivalent",
    "matchedPath": ["ingredient:palm-oil-and-fat", "ingredient:palm-oil"],
    "taxonomyVersion": "2026-08-06"
  }
}

The exact identifiers are illustrative. The contract is the important part: clients should be able to tell whether an exact ingredient, an ancestor, a descendant, or an equivalence rule supplied the value.

Hierarchy fallback creates useful coverage, but it also creates failure modes. Cocoa butter can inherit from a cocoa family for one environmental method while requiring a distinct food-composition record for nutrition. A generic vegetable oil should not automatically inherit the worst, best, or average value of all possible oils unless the method explicitly defines that policy. One shared taxonomy can support several calculations, but each calculation needs its own allowed traversal rules.

Origin fallback must preserve the failed lookup

The August 10 change exposes a second dimension of uncertainty. origin = Africa is not the same as origin = unknown. The first contains information, but at a granularity the footprint table cannot use directly. Replacing it with the method's unknown-origin value may be the correct fallback, yet the API should preserve both facts:

{
  "origin": {
    "observedId": "origin:africa",
    "lookupStatus": "recognized_but_unsupported",
    "methodOriginId": "origin:unknown",
    "fallbackPolicy": "use_method_unknown_origin",
    "fallbackPolicyVersion": "2026-08-10"
  },
  "estimate": {
    "value": 0.296,
    "unit": "method-specific-footprint-per-kg",
    "status": "estimated_with_fallback"
  }
}

The number is an example consistent with the new cocoa test fixture, not a universal cocoa value. A client should not detach it from ingredient, method, origin policy, and version.

Preserving the failed lookup helps operators improve coverage. They can count unsupported continental origins, prioritize mappings, and recompute affected records when new rows arrive. If the API stores only origin: unknown, it loses evidence that the source actually said Africa. If it stores only the numeric fallback, it cannot target a backfill at all.

Aggregates need coverage and recomputation metadata

A recipe-level estimate should answer two questions separately:

1. What is the total under the current method and fallback policy?
2. How much of the recipe was evaluated with exact, fallback, unmatched, or inapplicable evidence?

A practical summary might look like this:

{
  "environmentalSummary": {
    "method": "forest-footprint-2026",
    "methodVersion": "2026-08-10",
    "total": 0.1755,
    "grade": "d",
    "coverage": {
      "ingredientMassEvaluated": 0.91,
      "exact": 0.54,
      "fallback": 0.37,
      "unmatched": 0.09
    },
    "fallbacksUsed": [
      "parent_ingredient",
      "unknown_origin"
    ],
    "inputFingerprint": "stable-hash-of-ingredients-quantities-and-origins",
    "computedAt": "2026-08-10T14:00:00Z"
  }
}

The figures are illustrative. The design principle is not: publish one confidence score and move on. Coverage should show what fraction of the calculation depended on which evidence class. A recipe with an attractive total and nine percent unmatched mass should not automatically outrank a fully evaluated recipe without a product policy deciding that trade-off.

inputFingerprint and method version also separate source edits from calculator edits. When parent traversal or origin fallback changes, a cached recipe can be recomputed even though its ingredients did not. Clients can then explain that the estimate changed because coverage improved, not because the recipe author altered the dish.

Product rules should consume state, not just grade

Search and recommendation systems are where false zeros become business bugs. Before offering sort=lowest_footprint, define an eligibility rule. For example:

• require a minimum evaluated ingredient mass;
• cap the share supplied by broad parent-category fallbacks;
• exclude records with blocking unmatched high-impact ingredients;
• return grade and gradeEligibility separately;
• recalculate after a grocery SKU or ingredient substitution;
• avoid presenting fallback-heavy estimates as exact differences.

The same discipline applies to meal planning. A weekly plan can have a point estimate while still exposing which recipes drive uncertainty. Grocery selection can improve an origin or product match, but it should not silently overwrite the generic-recipe estimate. Keep scenario results separate so users and operators can compare like with like.

Validation checklist for environmental API fields

Before using an environmental estimate in ranking, personalization, or reporting, verify that the API can answer:

• Does zero always mean an explicitly defined zero?
• Are unsupported origins separate from absent origins?
• Is the original origin preserved when a fallback is used?
• Does every ingredient match report exact, parent, child, equivalent, or unmatched status?
• Are hierarchy traversal rules scoped to the environmental method?
• Do totals include evaluated-mass coverage and fallback coverage?
• Can a method or fallback-policy update invalidate cached results?
• Are historic estimates reproducible from method, taxonomy, and policy versions?
• Can product teams set eligibility thresholds independently of the displayed grade?
• Can support teams trace a changed ranking to the specific fallback that changed?

The lesson from this week's fixes is not that environmental calculators are unreliable. It is that they are real data pipelines, and real data pipelines have missing values, hierarchy mismatches, fallback policies, and migrations. Recipe API builders should expose those mechanics before a convenient zero becomes a flattering grade, a misleading recommendation, or an untraceable buyer claim.

Sources

• Open Food Facts, fix: also match parent ingredients for Forest Footprint 2026, merged August 6, 2026.
• Open Food Facts, fix: Forest Footprint 2026, origins with no data should get the en:unknown origin footprint value, merged August 10, 2026.
• Open Food Facts, feat: new Forest Footprint 2026 and knowledge panels in ingredients test tool, merged July 3, 2026, background context.