PKU Market Atlas Everything PKU, at your fingertips. Open the atlas
For Developers

Build tools that families can trust.

Contribute to open PKU infrastructure. It works like any other open-source project: issues, PRs, and a public benchmark that gates quality automatically.

The one problem we most need help with: for a mixed food, a fruit salad, a rice-and-carrot bowl, an estimator has to guess how much of each ingredient is in it before it can compute anything. That single guess is our largest source of error. No one has a method that reliably beats a rough guess from the label alone. That is the open problem we bring to the developer community.

It's one of four measured reliability gaps; the other three already have a known path forward. Read the reliability map

What developers are actually working on

We broke "the app feels unreliable" into four specific, measurable gaps. Three have a known path forward. One is the real open problem.

The open problem, Gap 3: the recipe factor. For a mixed food, how much of each ingredient is in it? That guess drives most of the error. No known method beats a rough estimate from the label. This is the one we're asking the community to crack. Because the same problem (estimating hidden proportions from an incomplete description) shows up far beyond PKU, a solution here is reusable everywhere.

The three with a known path:

  • Gap 1, converting protein to phe. The ratio varies by food; the fix is a better cited reference table.
  • Gap 2, labels round protein. In the very-low-protein range PKU lives in, that rounding hides a lot; the fix is looking the food up in the cited food list instead of trusting the label.
  • Gap 4, the AI answering differently each time. The fix is tightening how the method is applied so the same food gives the same number.

See the full reliability map, with the numbers

Where to contribute

Three building blocks, standard GitHub workflow. Fork, branch, PR.

phe-estimator/

Claude Skill

The label-parsing + recipe-factor method as a Claude Skill. Priority target: reduce non-deterministic reasoning, harden behavior under real-world conditions (weak Wi-Fi, partial labels).

Open the Skill

food-list/

Living food list

A maintained low-protein reference (USDA FDC / Open Food Facts derived). Add rows with provenance, improve the ingredient-to-phe classifier, expand very-low-protein coverage.

Open the food list

scale/

Scale integration

Bluetooth gram-scale support, reverse-engineered per device. Add a new scale by following the tutorial; goal is "connect the scale you own."

Open the scale module

The benchmark is the quality gate

You don't argue that your estimate is accurate. You measure it.

Any estimator that implements the interface can be scored against the public test set. Ground truth is computed from documented sources (USDA FoodData Central / Open Food Facts), so it's reproducible by anyone.

  1. Implement the estimator interface (one function, label in and phe estimate out).
  2. Run python benchmark/run_benchmark.py --estimator your_module.
  3. Get MAE, per-case error, and % within the tolerance band, plus regression vs. the last version.
  4. Open a PR. CI runs the same benchmark; merges require no regression.

Why this matters for sustainability: quality is guaranteed by the eval, and not by the author. An app can change hands, or lose its original developer entirely, and families still know it meets the bar, because every version is scored.

Read BENCHMARK.md  ·  See the leaderboard

How we review: two layers

Method and data, citation-backed

Every rule and every food-list row carries a citation to authority (USDA FDC id, Open Food Facts code, or named clinician sign-off), a version, and a reviewer of record. Challenges become issues; resolutions become the audit trail.

Estimator output, benchmark-gated

Accuracy claims are settled by measurement against the public test set, with regression checks in CI. No number goes up without evidence.

Read the full peer-review model

Tell us what you think

Found a gap, a failure case, or a scale we should support? We want it. File it as an issue, or leave a note here.

Open an issue

Fastest path:

Open an issue with your idea, failure case, or a scale we should support. It goes straight into the review queue where contributions are triaged.

A no-login web form is on the roadmap; for now feedback flows through GitHub Issues.