SkinShelf

Understand the scan before you buy. Keep the reasoning, including buying nothing.

Comment

Inspiration

The moment before a cosmetic purchase often mixes an impressive-looking skin score, a marketing promise and a budget. Those are different kinds of evidence. SkinShelf asks: can a shopper keep them distinct and leave with an explanation they can inspect later? This is a proposed need for cosmetic shoppers, not a claim from interviews or a user study.

What it does

SkinShelf turns YouCam Skin Analysis context into a before-you-buy decision receipt. Choose a concern, inspect its exact raw and adjusted scores and their different roles, then compare three explicitly fictional cosmetics against your budget and fragrance-free/lightweight preferences. Every exclusion has a reason. Keeping your existing routine at INR 0 remains an option.

The receipt combines the selected concern's API-derived context, source provenance, chosen preferences, catalog exclusions and limits. Download it as JSON. Changing a concern, source or preference clears the old receipt and download so a stale decision cannot masquerade as the current one. Missing raw data produces an explicit gap; adjusted values do not fill it in.

The API is used for cosmetic score context, not a diagnosis or an invented product-efficacy ranking. Higher raw scores mean better condition within that concern; a common scale does not establish comparability between different concerns. Preferences determine product eligibility. SkinShelf deliberately preserves that evidence boundary.

A concrete example

In the completed provider-sample test, Moisture displayed a raw score of 37.05 and an adjusted score of 65 (rounded here). SkinShelf keeps both values and their labels visible. Neither number means "37% hydrated," a diagnosis, or evidence that a particular cream will work. The recorded view preserves the observed normalized values without uploading the sample again.

Set the shopping budget to INR 0: all three fictional products are excluded, their reasons stay visible, and keeping the existing routine remains available. The downloadable receipt retains the chosen Moisture context, the recorded source, the budget and the exclusions. It records the reasoning without turning a cosmetic score into a purchase requirement.

How we built it

Original Node.js and vanilla JavaScript/HTML/CSS, using Node's built-in HTTP server and test runner, with no third-party packages. The server resolves receipt scores from its own recorded/fixture registry or last successful normalized live result. It rejects client-supplied fake scores and forged live provenance.

The YouCam adapter implements metadata registration, presigned PNG upload, four-concern SD/JSON task creation, bounded polling and response validation. One authorized provider-supplied full Sample 1 completed the entire adapter-to-UI path on October 25, 2026: metadata, upload, one task and two polls. The account's free Bonus balance changed from 40 to 31, with no card, subscription or auto-refill. Temporary test credentials were revoked. No photo, key, signed URL, account or task identifier is distributed.

The public test build reviews those observed normalized scores with a prominent saved-result banner; it does not make another inference. Separate fixtures are explicitly invented. Live setup is disabled by default and requires independent authorized sample/access checks. This is not a public unrestricted live-analysis service.

How judges can test

Download the repository ZIP, extract it, run node server.mjs with Node.js 24 LTS, and open http://127.0.0.1:4176 in a desktop browser. No package installation is needed. The recorded-result, fixture and receipt experiences require no account, API key, payment card or external network after download and obtaining Node. Fresh live inference is a separate, disabled-by-default operator workflow requiring independently authorized credentials and input. No entrant credential is shared.

Quick walkthrough after launch

  1. Click Review completed API sample, then choose Moisture. Inspect the raw/adjusted values and expand Recorded sample provenance.
  2. Set the budget to INR 0 and inspect why every fictional product is excluded. Keeping the existing routine remains available.
  3. Click Build my decision receipt, then Download receipt JSON. Change a preference and confirm that the old receipt/download clears until a new receipt is built.
  4. Select the invented partial-response scenario to inspect missing data. Unavailable raw scores remain missing instead of being replaced by adjusted scores.

For the automated engineering checks, run node --test from the extracted repository. This walkthrough and the tests do not require a new YouCam analysis.

The public 2:20 video uses timed captures of the running browser application, edited into seven scenes with embedded English captions and no audio. It demonstrates recorded and synthetic states; it does not perform new API analyses. Source and video remain the proposed judge-access artifacts; organizer acceptance is not claimed.

Challenges

We corrected reversed score-direction assumptions, removed unjustified cross-concern ranking, preserved missing data, and made source transitions and stale exports explicit. Rather than attaching a shopping recommendation to a cosmetic number without evidence, the final interaction saves what that number actually establishes alongside the shopper's own constraints.

Accomplishments and evidence

The public source archive was downloaded through the browser and all 24 files matched the reviewed manifest. All 40 engineering tests passed from the extracted public download. Checks cover response validation, mocked provider failures, unit reservations, local-origin/upload-host boundaries, canonical receipt sources, missing values and rejection of forged live scores. Browser checks verified recorded-score parity, concern/source changes, receipt download and zero-budget/stale-export behavior.

Twelve synthetic shopping scenarios had zero hard-constraint violations, deterministic output and an available no-purchase option in every case; a price-only baseline missed a selected preference in six cases. These are engineering results, not human, clinical or commercial outcomes. One actual adapter sample does not establish general model accuracy or robustness across photos.

What we learned and what is next

Useful integration includes explaining what an API result does not justify. Next work should test whether real shoppers understand raw/adjusted scores and the receipt, then add a licensed real catalog and evaluate usability. We have not conducted that validation and do not claim improved purchase decisions, product effectiveness, a competition rank or an award.

Development and browser QA were delegated to an AI coding agent; the entrant has not been represented as personally writing or testing the code. Existing Pro research and ordinary critiques shaped the scope. Receipt/demo implementation used the human-authorized agent-led fallback while Pro failed. When the session recovered, Pro reviewed the reported final evidence and official rules, recommended retaining the receipt and freezing scope, and explicitly could not retrieve the public code/video for independent inspection. No independent Pro verification of implementation or footage is claimed.

Built With

Share this project:

Updates

Submission history