A nutrition database
built around validation.

The problem.

A nutrition product depends on reliable data. An item from the wrong country, a shifted column in a PDF, or a plausible but incorrect nutrient value can make the product wrong while the database still looks healthy.

The client needed multilingual records that could be traced to published sources and refreshed through maintainable ingestion pipelines. Different source licenses also needed to remain distinguishable.

The system.

What I changed.

Structure the data for use and inspection

I built a PostgreSQL schema separating canonical foods, translated names, portions, and branded products. Python pipelines normalized incompatible source formats.

Make quality checks part of ingestion

Validation checked plausible ranges, duplicate records, and energy coherence. An extraction can look reasonable cell by cell and still fail when the values are considered together.

Keep a trail back to the source

Source URLs, publication information, licenses, and evidence grades were stored alongside the records. Unverified gaps stayed documented as gaps rather than being filled with estimates.

Separate storage and control search

The commercial product catalog was held in a separate store. Search indexing used a safe-to-show filter, and the handover included schema documentation, a refresh runbook, and a validation suite.

The result.

A maintainable nutrition data system with ingestion, validation, storage, and search working as a connected pipeline. The important property is inspectability: the client can trace a record, understand its evidence, and repeat the quality checks.