IndependentNot a client engagement. This study was not commissioned by, affiliated with or endorsed by Open Food Facts or the other organisations discussed. Findings, local experiments and proposed work are identified separately.
Evidence at a glanceWhat we can substantiate.
Real product records100100 distinct product codes. The full response and record-level decision audit are available. [1][2]
Comparable numeric pairs100 / 100Both sugars_100g and fiber_100g are numeric and within 0–100 in this snapshot. [1]
Filter matches33Test rule: sugars ≤10 g and fibre ≥6 g per 100 g. These are arbitrary software-test thresholds. [1]
Product names present99 / 100One record has no non-empty product_name in the returned field; 99 also have an a–e Nutri-Score grade. [1]
Public catalogue data audit · Studied 12 October 2026 · By SystemVale
The questionA filter can return a confident-looking list even when its inputs do not justify the conclusion a customer draws.
1Are compared quantities on the same basis and in a valid numeric range?
2Is an empty field being mistaken for a positive product attribute?
3Can someone inspect the reason a record was included or excluded?
Scope & methodA bounded question.
A repeatable method.
One API v2 response for category en:breakfast-cereals: page 1, 100 records, requesting sort_by=unique_scans_n. The query has no country filter. It is a popularity-sorted convenience sample, not a random or representative catalogue sample. Our work evaluates these saved records and a local comparison rule; it does not evaluate Open Food Facts’ live ranking algorithm.
Step 01Define a bounded sample
Capture one public search response and retain its exact URL, request fields, retrieval time and hash. Audit distinct product codes before calculating coverage. Do not extend the findings to another country, category or position in the catalogue.
Step 02Check the fields used by the decision
Read sugars_100g and fiber_100g, rather than mixing serving values with values per 100 g. Require finite numbers in the 0–100 range for both. A recorded zero is a number; a missing field is not silently converted to zero.
Step 03Evaluate a transparent test rule
Apply sugars ≤10 and fibre ≥6 per 100 g as arbitrary interface-test thresholds. Classify each record as matches, outside the rule or unknown because comparable values are unavailable. Retain the product code, input values and decision for every record.
Step 04Check what the answer cannot establish
Audit names, ingredient text, Nutri-Score grades and empty allergen tags separately. Availability of these fields does not validate their accuracy or establish suitability for a person. A deeper page-100 request returned HTTP 503, so no deeper-sample conclusion is reported.
FindingsThe evidence,
and what it means.
01
Observed in public dataThe measured numeric coverage is strong
Every sampled record has a valid numeric value for both selected nutrients, and every record has ingredient text. The result is 33 matches, 67 exclusions and no unknown numeric cases. We report that positive finding; we do not invent a missing-data problem that the sample did not exhibit. [1]
Why it matters. A useful audit can confirm that a bounded comparison is feasible. It should still state the sample selection and preserve the inputs.
02
Observed + proposed treatmentA record needs more than a valid comparison
One returned product_name is empty, and one record lacks an a–e Nutri-Score grade. These are independent checks; we do not assume the same record is responsible for both. A numeric match alone is not enough to guarantee an understandable product card. [1]
Why it matters. Use a clear name-unavailable fallback and the product code rather than inventing a title. Keep an unavailable grade visibly separate from a poor grade.
03
Observed + interpretationAn empty tag list cannot certify absence
Two records have empty allergen-tag lists. Our rules do not convert that into an allergen-free label, and the numeric filter makes no statement about allergens. The snapshot has not been independently checked against current packaging. [1][2]
Why it matters. Discovery systems need a distinction between recorded presence, explicit evidence for a property and information not established. A language model should inherit that distinction rather than fill gaps.
04
Method limitationThe sample does not justify a catalogue-wide score
The response requests popularity sorting and contains only the first 100 records. Highly visible products may have different contribution and review histories from the rest of the catalogue. The attempted deeper request was unavailable, so we have no measured coverage comparison. [1][2]
Why it matters. Use this study as a reproducible audit method and a bounded result, not a 100% completeness claim for Open Food Facts.
In detailInspect the results.
What the saved sample can actually support| Check | Observed | Interpretation |
|---|
| Distinct product codes | 100 / 100 | No duplicated identifiers in this response |
|---|
| Sugars and fibre comparable | 100 / 100 | Numeric comparison available for this rule |
|---|
| Matches the test rule | 33 / 100 | Both arbitrary thresholds satisfied |
|---|
| Outside the test rule | 67 / 100 | At least one threshold not satisfied |
|---|
| Unknown numeric comparison | 0 / 100 | No missing or out-of-range pair in this sample |
|---|
| Non-empty product name | 99 / 100 | One record needs a display fallback |
|---|
| a–e Nutri-Score grade | 99 / 100 | One record has no qualifying grade |
|---|
| Empty allergen-tag list | 2 / 100 | Not evidence that a product is allergen-free |
|---|
The filter thresholds are software-test parameters, not dietary advice, regulated nutrition claims or product recommendations. All coverage figures concern this exact response. [1]
Decision rule, record audit and reuse
The evidence download includes the unmodified API response, product-code audit and Python analysis. Run python scripts/analyze-public-studies.py. The published record audit is attributed to Open Food Facts contributors and made available under ODbL 1.0; individual database contents remain under the Database Contents License. No product images are republished.
For each record:
read sugars_100g and fiber_100g
if either is missing, non-numeric or outside 0..100:
state = unknown
else if sugars_100g <= 10 and fiber_100g >= 6:
state = matches
else:
state = outside
Do not infer dietary suitability from any state.
Recommendations · not deployedWhat we would do next.
These are SystemVale’s recommendations for a comparable product or service. They are not claims that the organisations studied implemented them.
01Make eligibility explainable
For a comparable product finder, store a reason alongside each decision: the field values, comparison basis, rule version and source timestamp. Let a product card explain which criteria were satisfied without suggesting an overall endorsement.
Represent unknown explicitly
Keep matches, exclusions and unknowns as separate states. This snapshot has no unknown numeric pair, so the missing-data branch is a proposed production requirement rather than a measured live defect. Test it with clearly labelled fixtures before release.
Separate facts from generated explanations
If adding an AI assistant, retrieve the product record first and restrict explanations to verified fields. A missing label, ambiguous unit or stale record should produce a clear limitation or a request for more evidence, not an invented product claim.
Measure discovery quality with actual tasks
Next, sample deeper catalogue positions and multiple categories using an appropriate export, then test find-and-compare tasks with users. Measure successful selection, zero-result searches and correction rates. We have not measured conversion, ranking quality or commercial impact.
SystemVale’s conclusionA useful product finder should explain both why a record matches and what the data does not establish.
Our interpretation of this study. Not a client quote or endorsement.
ApplicationWhat this brings to your work.
01Compare like with like
A field name, unit and quantity basis form part of the comparison contract. Serving values cannot silently replace values per 100 g.
02Keep evidence attached
A decision tied to a source record and rule is easier to audit, correct and explain.
03Do not manufacture certainty
Unknown information is a legitimate result. A confident interface should not conceal it.
Explore Discovery & Decisions →
Limits & sourcesCheck the evidence.
What this study does not establish
- One global, popularity-sorted sample of 100 cereal records; no representative sampling or deeper-catalogue coverage claim.
- Open Food Facts is a contributed database. We did not verify current packaging, product availability, formulation or individual field accuracy.
- No dietary suitability, allergen-safety assessment, health recommendation or regulatory nutrition claim is made.
- No live search, ranking or product-card implementation was changed. Customer task success and commercial results remain unmeasured.
Reproduce the analysis
Download the five-study evidence bundle: captured public data, source hashes, scripts, licenses and original result files. The README explains the commands and the boundaries of each experiment.
- SystemVale: field coverage and all 100 record decisions ↗
Derived from Open Food Facts contributors’ data, 12 October 2026. Record-level database shared under ODbL 1.0.
- Open Food Facts: API documentation ↗
Source API and field context. Exact v2 snapshot URL and checksum are in the evidence manifest; this study does not claim v2 is the recommended version for new integrations.
- Open Food Facts: terms of use and data attribution ↗
Database: ODbL. Individual contents: Database Contents License. No images used.
- Open Data Commons: ODbL 1.0 ↗
License for the attributed record-level data and derived audit.