ZYRA Guardian

Company: ZYRA Guardian

Self-reported basis: The description is from a Devpost submission by one individual for the OpenAI 2026 hackathon. It is unverified and self-reported.

What it appears to be: A proof-of-concept feature added to an existing multilingual food scanner (ZYRA), designed to help travelers with allergies interpret foreign-language food labels by mapping them to personal allergen profiles.

What changed: During Build Week, a new vertical slice was added to ZYRA that enables users to define personal allergy profiles and receive structured, personalized allergen warnings from scanned product labels.

Most important open question: Is there evidence of traction or adoption beyond the author’s own testing?

The description states that ZYRA Guardian is a personalized allergen decision layer inside ZYRA, an existing multilingual food-analysis platform.

It adds:

• A persistent personal allergy profile
• Personalized matching against structured allergen results from scanned products
• Separate handling of direct ingredients and “may contain” warnings
• Four clear decision states: DANGER, MAY CONTAIN, NO PROFILE MATCH, SCAN INCOMPLETE
• Mobile-first interface
• Preservation of original evidence from the label

The system integrates with an OCR pipeline that processes package images, extracts ingredients, normalizes them multilingually, and detects allergens.

Inference: The feature appears to be a vertical slice built during a hackathon, not a full product. It was tested in a real-world scenario (Warsaw trip) using a Polish product.

The description states that food labels are written for local shoppers, but allergies travel across borders.

ZYRA Guardian is positioned as:

• A tool to help travelers with allergies interpret foreign-language food labels
• An “allergen decision layer” that distinguishes between direct ingredients and trace warnings
• A system that prioritizes evidence over certainty

It claims to:

• Turn foreign-language labels into personalized, evidence-based allergen warnings
• Distinguish between direct ingredients, trace warnings, and incomplete scans
• Avoid false confidence by not showing “SAFE” or “safe to eat”

Inference: The positioning is rooted in a personal problem (traveler with allergies) and a technical solution (AI-assisted multilingual parsing + decision logic). It does not claim market traction or commercial adoption.

The description states that the user selects allergens to watch for, and the system compares these against structured ingredient results from scanned products.

It is designed for:

• Travelers with allergies
• Users who need to make food decisions from labels in languages they do not understand
• People with severe allergies who require clear, actionable warnings

Inference: The ICP appears to be a niche group of travelers with specific allergy concerns. No evidence of broader customer segments or personas is provided.

The description does not state anything about:

• Revenue model
• Pricing structure
• Monetization strategy
• Customer acquisition costs
• Unit economics

Not evidenced

The system uses:

• Next.js and TypeScript frontend
• FastAPI and Python backend
• OCR (Tesseract, Vision)
• Multilingual normalization using GPT-5.6
• Codex for auditing and implementation
• SQLite for data storage
• REST APIs
• React, JavaScript, and TypeScript

It is described as:

• Deterministic in decision-making
• Not inventing or removing allergen warnings
• Integrating with an existing OCR pipeline
• Supporting mobile-first interface
• Including regression tests

Inference: The technical stack suggests a modern, scalable architecture. However, no evidence of production deployment, scalability, or performance metrics is provided.

The description states:

• A real trip to Warsaw was used for testing
• A Polish product was scanned and matched to tree-nut profile
• The feature was built during Build Week
• It preserves the original evidence from the label
• It was tested with a real-world scenario

Not evidenced: No data on:

• Number of users or scans
• Retention or engagement metrics
• Adoption beyond one user
• Commercial use cases or partnerships

The description does not mention any competitors.

Not evidenced

• No commercial traction: The system is described as a hackathon project with no evidence of adoption.
• Single-person team: Only one person built the feature.
• Unverified claims: All functionality and testing are self-reported.
• Limited scope: The feature was built for a single use case (Warsaw trip) and not validated at scale.
• AI dependency: Reliance on GPT-5.6 for normalization, but no clarity on how this is integrated or controlled in production.

1. What is the current status of ZYRA as a product? Is it used by others beyond the author?
2. How was the Polish label validated — was it tested with multiple products or just one?
3. Has the system been tested with other languages or packaging types?
4. What are the plans for integrating Guardian into the broader ZYRA platform?
5. Are there any legal or regulatory considerations around allergen warnings and liability?
6. How is the multilingual normalization handled in production — is GPT-5.6 used in a controlled, traceable way?