Inspir## Inspiration
Online fashion shopping runs on trust that listings don't earn. Fabric is missing or buried, "long sleeve" turns out to mean three-quarter, and virtual try-on adds a new problem: the preview can quietly change the garment's neckline, sleeves or color. Most AI shopping assistants only recommend products that sound relevant. None of them tell the shopper what is actually proven, what conflicts, and what is simply unknown.
ProofPick is built around that gap: Find it. Check it. Try it on.
What it does
- Describe. The shopper writes a request in plain language. Gemini turns it into editable must-haves and preferences. Nothing is searched until the shopper confirms.
- Check. Deterministic backend rules compare every product with its documented evidence. Each requirement gets one of three outcomes:
meets_documented_requirementsconflicts_with_requirement(e.g. "100% polyester" vs. a cotton must-have)insufficient_evidence(the listing doesn't say) Missing information is never treated as a mismatch, and every verdict links to its evidence source.
- Rank. Gemini orders only the eligible products by preference. It cannot change eligibility, and any invented product or evidence ID is rejected.
- Try on. Shortlisted products go to the YouCam Cloth Virtual Try-On API with the shopper's photo.
- Inspect. A separate visual inspection compares each original garment with its preview, feature by feature (neckline, sleeves, color appearance, silhouette, visible details). Results are
no_visible_mismatch_detected,possible_mismatchornot_assessable. - Decide. The shopper sees an evidence comparison, the try-on, the integrity report and the uncertainty, plus a link to the exact retailer listing. ProofPick never buys anything.
Product checking and preview inspection are deliberately separate systems, so a bad preview can never make a suitable product look unsuitable.
Why it matters
- Shoppers can see which claims are documented before they buy, instead of finding out when the package arrives.
- Retailers could add this as a trust layer on top of a VTO widget: previews that admit uncertainty instead of overpromising.
How I built it
- Frontend: Next.js (request, confirmation, evidence comparison and try-on screens).
- Backend: Python and FastAPI with SQLite.
- Models: Google Gemini for requirement parsing, ranking and preview inspection. Rules, not the model, decide eligibility.
- YouCam integration (server-side only):
- Request upload slots (
POST /s2s/v2.0/file) and upload the person and garment images - Create the task (
POST /s2s/v2.0/task/cloth-v4,garment_category: upper_body) - Poll the task about every 10 seconds, then download the result before its URL expires
- Task and file IDs are stored, so a restart resumes an existing task instead of duplicating it
- Per-session limits and a deployment-wide daily cap protect API units
- Request upload slots (
- Privacy: API keys never reach the browser. Uploads are re-encoded to strip metadata, stored privately per session, and removable with "Delete my data". YouCam documents keeping files for 30 days, so provider copies are not deleted by this.
Challenges
- Keeping the model out of the verdict. It was tempting to let one model recommend and judge. Splitting rules, ranking and inspection into separate stages made the system explainable.
- Honest uncertainty. A three-state result is less impressive than a confidence score, but it is more truthful. I wanted a tool that can say "not documented."
- Try-on inputs. YouCam needs front-facing, single-garment images, so catalog image quality matters as much as the code. [Add one specific issue you actually hit and how you fixed it.]
What I learned
I leaned how to submit and how to use the api keys and built a relaible hackathon as well how to brainstron good idea.
Data and limitations
- The catalog contains [N] real listings. Each attribute stores its source URL, source type and collection date, and links to the exact retailer page. Product photos are use with perm
- The catalog is fictional demo data with illustrated images, labeled in the interface. The architecture accepts a real catalog with the same evidence format.
- ProofPick does not verify physical fit, comfort, opacity under real lighting, or exact color. Style fit is a judgment, not a verified fact. It never scores a person's body or attractiveness.
- The preview inspection reports visible observations, not guarantees.
- My own evaluation set was labeled by the same people who wrote the rules, so it shows the logic behaves as specified, not real-world accuracy.
What was built during the submission period
the whole project was built in the submission period.
What's next
- Care-label photo extraction as shopper-confirmed evidence
- "No match" flow that suggests relaxing preferences, never must-haves
- Re-checking a live listing against stored evidence
- More garment categoriesation
Built With
- ai
- computer-vision
- ecommerce
- fashion-tech
- fastapi
- google-gemini
- llm
- nextjs
- python
- react
- rest-api
- sqlite
- typescript
- virtual-try-on
- youcam-api
Log in or sign up for Devpost to join the conversation.