Oscar Nutrition — Rafael

Rafael transforms complex nutrition requests—including sensitive profiles—into explainable meal, day or week workflows through Oscar’s 13-layer educational engine for users and health professionals.

Comment

Inspiration

Real people do not arrive as clean database records.

They arrive with incomplete sentences, conflicting objectives, different budgets, food preferences, allergies, activity levels, pregnancy, health conditions and questions they may not know how to organize. A request that sounds simple—“create a meal plan”—can hide dozens of decisions that must be interpreted before any food is selected.

Oscar Nutrition was created to make nutritional information easier to understand and food planning more structured. Its permanent intention is to teach and inform. It does not diagnose disease, prescribe or change medication, promise a cure, or replace physicians, registered nutrition professionals or any other qualified healthcare professional.

The central question behind this project was:

What if a nutritional application could understand the person first, explain what it is doing, and then execute a complete workflow instead of merely producing chatbot text?

That question gave life to Rafael.

Before the hackathon

Oscar already existed as a conventional nutritional application foundation, but many parts were still incomplete, undefined or awaiting substantial refinement.

Rafael existed only as a visual element—a wallpaper inside an empty screen. He could not talk, interpret a request, remember context, use a tool or execute any action.

The application had an existing nutritional foundation, but its entities, interface, professional workflow and internal layers had not yet reached the structure represented by this submission.

What was built and transformed during All Things Agentic

During the submission period, Oscar underwent a major technical, visual and conceptual transformation.

Rafael was implemented as a real conversational and operational entity powered by Gemini 3.5 Flash Lite through the Google GenAI SDK. He gained structured interpretation, session context, missing-field resolution, identity separation, an authorized Tool Belt, explicit confirmation boundaries and real execution through Oscar’s official generator.

The Profile was expanded and refined into the system’s sovereign source of truth. Activity level was implemented, additional diseases and conditions were incorporated, client workflows were strengthened, and the nutritional matrices and generator layers were expanded.

The Hecatoncheir—the name given to Oscar’s many-handed generator—received deeper and more structured layers for input, completeness, diseases, priorities, conflicts, decisions, food knowledge, planning, calculation, educational narrative, formatting, validation, History and result presentation.

The Gastronomic Maestro was implemented and refined as a passive shadow system attached to the official Planner. It currently observes culinary coherence, meal identities, food families, combinations, preparations, beverages, variety and meal-experience signals without changing the official result.

The easiest mental image is a Venom-like symbiosis: the Maestro surrounds the Planner and develops a richer culinary representation while the Planner remains the official decision authority. Mechanically, however, this is a controlled passive-shadow architecture—not an organic intelligence or an unsupervised self-learning system. The Maestro will remain attached to the Planner until simulations and audits demonstrate that it can safely assume greater responsibility.

The Client area received new operations and stronger profile isolation. Plans and Settings were redesigned and refined. Light and dark themes were introduced. White and black premium icon collections were added. Animations were improved. Male and female Rafael bodies were refined. The original home stage was reconstructed with new visual elements, including its platform, ring, light cannon and loading presentation.

This submission therefore represents much more than an API added to an existing interface. It represents the transformation of an earlier application foundation into a layered nutritional-intelligence system with a real agent capable of understanding, preparing and executing work.

What it does

Oscar can serve a straightforward user who wants one practical meal, but it can also process substantially more complex profiles involving:

  • Age, sex, height and weight
  • Activity level
  • Primary and secondary goals
  • Budget
  • Preferences and dislikes
  • Allergies
  • Lifestyle and religious constraints
  • Pregnancy and other special conditions
  • Multiple declared health conditions
  • Nutritional priorities and conflicts

Conditions such as diabetes, hypertension, tuberculosis and HIV/AIDS are not used as decorative labels. When declared, they participate in disease, priority and conflict matrices that can change educational priorities, restrictions, warnings and composition behavior.

These conditions never turn Oscar into a medical diagnostic or treatment system. They make the educational engine more conservative and context-aware while keeping professional-care boundaries visible.

Rafael: from wallpaper to operational agent

Rafael is the conversational bridge between human language and Oscar’s official machinery.

He can:

  • Hold a normal conversation within Oscar’s nutrition domain
  • Interpret text or voice input
  • Read the current user profile
  • Check whether the profile is complete
  • Distinguish the device owner from a saved client or a new third person
  • Preserve identity boundaries between different people
  • Extract structured information from an unstructured request
  • Ask only for information still required
  • Maintain the state of the workflow across messages
  • Prepare a simple meal, complete day or full-week generation
  • Display an inspectable internal action plan
  • Wait for explicit authorization
  • Execute through Oscar’s official generator
  • Save the real result to History
  • Open the same result on the Result Wall
  • Offer to save a newly generated third-person profile as a client

Rafael does not directly invent the official nutritional output.

Gemini interprets the human request. Oscar’s local schemas validate the response. The Capability Map determines what Rafael is allowed to access. The Tool Belt isolates every available action. Confirmation rules protect mutations and generation. The official nutritional engine remains responsible for the final result.

This creates an agent that does not merely describe what could be done. It performs the authorized workflow and exposes visible proof of its execution.

The four entities behind Oscar

Profile / One Above All

The Profile is the sovereign source of truth.

It defines who the generation is for and establishes the constraints that every downstream layer must respect. It can represent the device owner or an isolated client without mixing their identities, preferences, conditions or results.

Generator / Hecatoncheir

The Generator is called the Hecatoncheir because it behaves less like a single hand and more like many coordinated hands working on one request.

Its operational chain contains thirteen stages:

  1. Profile and generation input context
  2. Minimum-data and completeness assessment
  3. Disease Matrix
  4. Priority Matrix
  5. Conflict Matrix
  6. Decision Engine
  7. Nutritional Knowledge Base and compatibility
  8. Official Nutrition Planner
  9. Gastronomic Maestro passive shadow pass
  10. Nutrition Calculator and quantity resolution
  11. Educational Nutrition Narrative
  12. Result Formatter and structural validation
  13. History persistence and Result Wall presentation

This layered chain is why a healthy profile and a profile involving diabetes, pregnancy, tuberculosis, HIV/AIDS, allergies or conflicting objectives do not travel through the same decision path.

Planner / Gastronomic Maestro

The Planner remains the official food-selection and composition authority in version 0.0.13.

The Maestro observes its results through passive contracts and develops a richer representation of culinary coherence. In this release, it cannot change the official food, quantity, score, slot, budget boundary or visible result.

This controlled limitation is intentional. Culinary intelligence should not silently assume authority before its behavior has been tested against the safety and reproducibility of the official engine.

Rafael

Rafael understands the human request, converts it into structured intent and coordinates authorized actions. He is the visible intelligence that connects conversation, Profile, Clients, Generator, History and results without bypassing their contracts.

Value for health professionals

Oscar is not limited to direct-to-user meal generation.

It can become a high-value operational support tool for nutrition and healthcare professionals working in both in-person and virtual appointments.

A professional can create isolated client profiles, organize declared conditions and objectives, identify missing information, prepare structured educational material, review the reasoning path and preserve each generated result in History.

Rafael can transform an unstructured client description into a complete and reviewable workflow instead of forcing the professional to repeatedly transfer the same information between disconnected screens.

This can accelerate preparation before an appointment, support explanations during the consultation and make follow-up more consistent afterward.

The value is not that Oscar replaces professional judgment. The value is that it protects professional time for the work that cannot be automated: listening, investigating, understanding the complete clinical context and making the final individualized decision.

How we built it

The agentic pipeline follows a controlled sequence:

  1. The user writes or speaks naturally.
  2. Rafael sends one structured interpretation request to Gemini.
  3. The server validates the response against local schemas.
  4. The Capability Map checks whether the requested operation exists.
  5. The Tool Belt isolates the selected action.
  6. Missing information is collected without discarding previous context.
  7. Mutations and official generation require explicit confirmation.
  8. The official generator executes through its local deterministic layers.
  9. The result is persisted to History and presented on the Result Wall.
  10. Rafael reports only actions that actually reached a terminal execution state.

The model key remains on the server and is never exposed to the browser.

The application runtime is deployed on Render Free. The required Google Cloud backend infrastructure is implemented with Cloud Firestore. Firestore contains only a sanitized, public, read-only capability document. Profiles, clients, health conditions, messages and generated results are not stored in that public registry.

The live health endpoint verifies the deployed version, immutable build and real Firestore connection.

Technologies used

  • Gemini 3.5 Flash Lite
  • Google GenAI SDK (@google/genai)
  • Node.js
  • JavaScript
  • Cloud Firestore
  • Firebase security rules
  • Render Free
  • HTML and CSS
  • Local schema validation
  • Rafael Capability Map
  • Rafael Tool Belt
  • Session-based structured clarification
  • Disease, Priority and Conflict matrices
  • Decision Engine
  • Versioned nutritional Knowledge Base
  • Nutrition Planner
  • Nutrition Calculator
  • Educational Narrative
  • Result Formatter
  • Gastronomic Maestro passive-shadow contracts
  • Automated Node test suite

Oscar’s nutritional data architecture combines project-authored, versioned nutritional rules and matrices with food-composition references including USDA FoodData Central records where applicable.

Challenges we faced

The hardest challenge was not making Gemini produce a pleasant answer. The hardest challenge was preventing a pleasant answer from being mistaken for real execution.

We had to separate:

  • Conversation from action
  • Intention from execution
  • Preparation from mutation
  • The device owner from third-party clients
  • Model interpretation from official nutritional decisions
  • Visible progress from fabricated progress
  • Maestro observation from Planner authority

Another major challenge was preserving context while collecting missing information. A complex profile may arrive across several messages, and the system must retain previously confirmed information without silently replacing one person’s data with another’s.

We also had to keep model usage controlled. Rafael is designed around a maximum of one Gemini request per user message, with no background polling or hidden retry loop that could create unpredictable cost.

Finally, we had to deploy with no active Google Cloud billing account. We used Firestore’s no-cost capacity as the required Google Cloud infrastructure and Render Free for the Node runtime, while making the architecture and hosting boundary completely transparent.

Accomplishments that we are proud of

We are proud that Rafael is no longer a decorative screen.

He can now receive a complex natural-language request, identify who the request concerns, preserve the profile across multiple messages, ask what is missing, present an inspectable plan, wait for authorization and execute a real generation through Oscar’s official engine.

We are proud that the model does not replace Oscar’s deterministic nutritional architecture.

We are proud that a complex condition is not reduced to a keyword in a prompt. It enters structured matrices and remains subject to educational warnings and professional boundaries.

We are proud that every visible completed execution corresponds to a real terminal action, and that generated results are preserved in History rather than disappearing after a chat response.

We are also proud that the visual identity evolved together with the engineering: Rafael’s bodies, the reconstructed stage, light and dark themes, premium icon collections, animations, Plans, Settings, Client workflows and loading experience now communicate the depth of the system more faithfully.

What we learned

We learned that a useful agent needs less freedom in some places and more responsibility in others.

Gemini is powerful at understanding human language, but the official decision path must remain explainable, scoped and testable. Tools must be isolated. Confirmation must be explicit. State must have a clear owner. A timeline must report reality rather than theater.

We also learned that food planning becomes far more complex when a system respects identity, budget, preference, disease, special condition and conflict simultaneously.

Most importantly, we learned that an educational health-support system becomes more trustworthy when it clearly explains what it can do and, with equal strength, what it must never claim to do.

What is next

The next major milestone is the controlled evolution of the Gastronomic Maestro.

It will remain attached to the official Planner until large simulations, before-and-after audits and safety tests demonstrate that its culinary observations can become active decisions without breaking reproducibility or profile constraints.

Future work also includes:

  • Deeper professional workflows
  • More structured appointment support
  • Expanded client follow-up
  • Stronger long-term preference and meal-experience memory
  • Additional explainability tools
  • Greater accessibility
  • More regional food knowledge
  • Continued disease and conflict-matrix refinement
  • Production-ready deployment beyond the evaluation environment

Oscar’s long-term goal is not to replace the human professional.

It is to become a powerful nutritional-intelligence companion that helps individuals understand their choices and helps professionals spend less time moving information between screens—and more time caring for people.

Built With

Share this project:

Updates

Submission history