SCANNER · Shri

The problem

A generic health score ignores your actual condition

People managing chronic conditions get generic nutrition scores that treat every body the same. But what is fine for one condition can be dangerous for another. A potassium-chloride salt substitute looks like a healthy swap, yet it is genuinely harmful for someone on certain blood-pressure medications. No mainstream scanner calibrates its verdict to the user's specific clinical profile, so the one number they see can be confidently wrong for them.

The gap

One score for everyone

Mainstream scanners grade a food against a population average. They do not know whether you are managing diabetes, hypertension, weight, or a combination, so the verdict is not actually about you.

The danger

Fine for one, harmful for another

The same product can be a good pick for one condition and a real risk for another. Without condition calibration and a safety layer, a scanner can quietly recommend exactly the wrong thing.

The solution

A verdict calibrated to your conditions

The user sets their conditions once, and whether they take blood-pressure medication. From then on, each barcode scan returns a three-tier verdict, a per-condition fit score, a calorie-awareness label, and a hard safety override, all calibrated to that clinical profile. It is positioned deliberately as a wellness tool, not a medical device.

Verdict

Good · Caution · Skip

A clear three-tier call on any packaged food, calibrated to the user's specific conditions rather than a one-size-fits-all grade.

Fit score

0 to 100, per condition

A transparent score for each condition, so a food can read differently for diabetes than it does for hypertension, plus a calorie-awareness label.

Safety override

A hard stop when it matters

A priority safety check flags potassium-chloride salt substitutes for users on blood-pressure medication and short-circuits straight to Skip, no matter how the rest scores.

Wellness tool, not a medical device

SCANNER is designed and positioned as a wellness aid to support everyday food choices. It does not diagnose, treat, or replace clinical care, and it is scoped accordingly.

How it works

Deterministic, condition-specific, strictest wins

The engine takes two inputs: a normalized product (nutrients per 100g) and the user's condition profile. It runs condition-specific evaluators for diabetes, hypertension, and general wellness, a calorie-density label, and a safety check. The results aggregate on a strictest-wins basis, so the most conservative signal drives the final verdict. Each nutrient earns a 0 to 100 piecewise sub-score, combined into a weighted per-condition fit score, for example diabetes weights added sugar most and hypertension weights sodium most. Trans fat above zero hard-caps the score. Every clinical threshold is a named constant I defined from published guidelines. No AI runs at any point in this pipeline; it is a hand-specified rules-and-scoring system.

01 · Inputs

Product + profile

A normalized product record (nutrients per 100g) and the user's conditions and blood-pressure-medication flag.

02 · Evaluate

Condition evaluators + safety

Diabetes, hypertension, and general-wellness evaluators, a calorie-density label, and a priority safety check run over the product.

03 · Aggregate

Strictest wins

Per-nutrient piecewise sub-scores combine into weighted per-condition fit scores, and the most conservative result sets the verdict.

Technical highlights

The engineering decisions that make the verdict trustworthy

01

Lint-enforced portability boundary. The clinical engine is a fully headless TypeScript module with no React or UI dependencies, enforced by ESLint rules, so it could lift into a web app or server unchanged.

02

Exception-free, null-means-unknown. The verdict engine has zero throw statements. Every data-quality problem becomes a flag, never a crash, and missing data is never defaulted to zero, so incomplete label data yields a clearly labeled "insufficient data" verdict instead of a confidently wrong one.

03

Profile-aware three-source cascade. FatSecret is primary, USDA FoodData Central gap-fills only when the user's conditions require fields FatSecret is missing, and Open Food Facts is tertiary, merged field-by-field, with API keys hidden behind Supabase edge-function proxies.

04

Sodium unit-reconciliation. Open Food Facts stores sodium in grams even when labels show mg, so everything is normalized to mg with assumptions flagged, backed by the largest test file at 81 cases. This is exactly the class of silent bug that would produce dangerously wrong verdicts.

05

Potassium-chloride safety override. The clinical reasoning that potassium loading is dangerous for people on certain blood-pressure medications is encoded as deterministic, testable, priority-hoisted logic that short-circuits to a hard Skip.

Quality and testing

812 tests, 19 suites, zero failures

Correctness is enforced by tests, not hoped for. Coverage spans all verdict evaluators and the full data pipeline across 812 passing tests in 19 suites and 160 describe blocks, with zero failures. The discipline is built into the toolchain: an ESLint-enforced portability boundary keeps the engine headless, Prettier keeps the code uniform, and strict TypeScript keeps the types honest.

Tested where a wrong answer would hurt

The heaviest tests sit on the highest-risk logic: 81 cases on sodium unit-reconciliation alone, plus dedicated coverage for the potassium-chloride safety override and every condition evaluator. The failure modes that would produce dangerously wrong verdicts are the ones most heavily pinned down.

Jest Strict TypeScript ESLint portability rule Prettier Exception-free engine

My role

Clinical logic and direction, implementation through AI tooling

I am not a software engineer, and this page should not imply otherwise. What I own is the clinical and product thinking. I defined the clinical logic and thresholds from published guidelines, designed the product and its condition-calibrated verdict model, and architected the system as a portable clinical engine cleanly separated from the UI. I directed the full build through AI coding tools, Claude Code and Codex, selecting models via OpenRouter, working from written specs and the clinical logic I defined myself. I also set the quality discipline: portability enforced by linting, an exception-free engine, and comprehensive tests. The implementation was built through AI tooling under my direction, and the app itself runs no AI at runtime.

Clinical logic, product decisions, architecture direction, and quality discipline are mine. The implementation was built through AI tooling under my direction.

What I owned

Clinical logicThreshold definition Product decisionsVerdict model design Architecture directionQuality discipline

How it was built

Claude CodeCodex OpenRouter model selectionWritten specs Directed AI implementation

Tech Stack

Built with

A managed React Native stack on the New Architecture, with a deterministic clinical engine at its core. Monetization through RevenueCat is planned, not yet wired, and there is no runtime AI or ML anywhere in the app.

TypeScript (strict) React Native 0.81 Expo SDK 54 expo-router expo-camera react-native-mmkv v4 Supabase edge functions (Deno) Jest

Status and roadmap

Engine complete, in active development

The entire portable engine is complete and fully tested. Real barcode scanning is wired to the three-source data cascade and renders the full verdict card. It is in active development and not yet published.

Done

The clinical core

Complete, fully tested verdict engine, the three-source data cascade, and real barcode scanning rendering the full verdict card.

Remaining before ship

Around the core

Onboarding flow, paywall and RevenueCat, analytics, and App Store submission. No release date claimed; it is not yet published.