A portable dietary identity and coordination layer for allergies, restrictions, preferences, and food needs.
PassPlate helps people communicate what they can eat without repeatedly explaining sensitive or safety-relevant information. It turns fragmented dietary notes into a structured, user-controlled profile that can be shared with hosts, restaurants, caterers, and events.
Current focus: HostPlate, a lightweight workflow for collecting guest dietary needs and generating a clear, actionable group summary.
Live Site · Product Overview · AI System · Design · MVP
Dietary information currently lives across reservation notes, text messages, catering spreadsheets, server conversations, and unstructured form fields.
These systems were not designed to preserve dietary identity across different meals, groups, venues, or platforms. As a result, people repeatedly disclose the same information while hosts and food-service teams receive inconsistent, incomplete, or difficult-to-use notes.
PassPlate explores a different model:
Create dietary information once, control how it is shared, and make it usable wherever food is coordinated.
The product is designed as a layer on top of existing hospitality, reservation, ordering, and event systems rather than as a replacement for them.
PassPlate began with a problem I've lived with for most of my life.
Growing up with food allergies, I became used to explaining the same information over and over again.
Every restaurant, birthday party, school event, family gathering, or dinner with friends started with the same conversation:
- "What are you allergic to?"
- "How severe is it?"
- "Can you eat this?"
- "What happens if there's cross-contact?"
Sometimes the information was written in a reservation.
Sometimes it was buried in a text message.
Sometimes it had to be repeated to a server, who repeated it to a manager, who repeated it to the kitchen.
Even today, I still find myself re-explaining the same information in different ways depending on the situation.
Over time, I realized the problem wasn't simply food allergies.
It was how dietary information moves between people.
Every restaurant, event, reservation platform, and catering workflow asks for roughly the same information, but each collects it differently. The burden almost always falls on the individual to repeatedly communicate personal health, religious, cultural, or lifestyle needs and hope they are understood correctly.
As an engineer, I became less interested in the allergy itself and more interested in the system surrounding it.
Why is the same information collected repeatedly?
Why doesn't a person have a reusable dietary identity they control?
Why does every platform ask the same questions from scratch?
Those questions became the foundation for PassPlate.
Rather than building another restaurant marketplace or food discovery app, PassPlate explores whether dietary identity itself can become portable, structured, permission-based, and reusable across restaurants, events, catering, and hospitality.
Today, PassPlate serves as both an active product concept and a public case study in product strategy, systems design, AI-assisted workflows, and human-centered design.
I am designing and implementing PassPlate as an end-to-end product, systems, and interface case study.
My work includes:
- Product strategy and positioning
- Problem definition and opportunity analysis
- MVP scoping and prioritization
- User and stakeholder workflow design
- Dietary identity and permission-model design
- Product architecture and system-flow planning
- Data-model and decision-logic design
- Front-end implementation
- UI and interaction design
- AI-assisted structuring and summarization workflows
- Product analytics and success-metric planning
- Public product documentation
Communicating food needs is still fragmented, repetitive, and emotionally loaded.
Today, dietary information may be stored in:
- Reservation notes
- Group text messages
- Event registration forms
- Catering spreadsheets
- Restaurant point-of-sale systems
- Server and kitchen conversations
- Delivery-app instruction fields
This creates friction on both sides.
- The same information must be entered repeatedly.
- Sensitive information may need to be explained publicly.
- Preferences, intolerances, and severe allergies are often grouped together.
- Guests cannot always tell whether their information was received or understood.
- Asking for accommodation can feel socially uncomfortable.
- Dietary responses arrive in inconsistent formats.
- Free-text notes are difficult to summarize.
- Important severity or cross-contact details may be unclear.
- Information must be manually transferred between people and systems.
- Group-level conflicts are hard to identify quickly.
The core problem is not simply finding food.
It is communicating dietary identity with clarity, context, and dignity.
flowchart LR
A[Guest] --> B[Text, Form, or Reservation Note]
B --> C[Host or Organizer]
C --> D[Spreadsheet or Manual Summary]
D --> E[Restaurant or Caterer]
E --> F[Kitchen and Service Staff]
F --> G[Guest Experience]
- Dietary information is collected repeatedly.
- Inputs are usually unstructured.
- Preferences and safety-critical needs may be mixed together.
- Information is manually copied between systems.
- Updates do not carry forward to future meals.
- Guests have limited visibility into whether their needs were acknowledged.
- Hosts must interpret and summarize information without a consistent framework.
flowchart LR
A[Guest] --> B[PlateID]
B --> C[Permissioned Share]
C --> D[HostPlate]
D --> E[Structured Group Summary]
E --> F[Host, Restaurant, or Caterer]
F --> G[Accommodation Confirmation]
PassPlate separates the workflow into three layers:
- Identity: What the person can eat, avoids, prefers, or needs communicated.
- Handoff: How relevant information is shared for a specific meal or event.
- Coordination: How hosts and food-service teams understand and act on the group’s needs.
The future of food coordination is not only restaurant discovery.
It is dietary compatibility.
People need a portable, structured, and shareable way to express:
- What they cannot eat
- What they choose not to eat
- How serious each restriction is
- What accommodations may work
- What information they consent to share
- How they prefer their needs to be communicated
PassPlate is the identity and handoff layer that makes this information reusable across the places where food happens.
Think of it as a wallet pass for dietary identity.
PassPlate is envisioned as one system with four connected surfaces.
| Surface | Purpose | Current Stage |
|---|---|---|
| PlateID | A reusable, user-controlled dietary profile | Core identity concept |
| The Pass | A fast way to share relevant dietary information | Initial sharing experience |
| HostPlate | A workflow for collecting and summarizing group dietary needs | MVP wedge |
| ScanPlate | A future compatibility layer for menus, meals, and events | Future direction |
A structured dietary identity containing information such as:
- Allergies
- Dietary restrictions
- Sensitivities and intolerances
- Religious or cultural food requirements
- Lifestyle preferences
- Severity levels
- Cross-contact concerns
- Safe alternatives
- Preferred disclosure language
- Sharing permissions
A portable version of a PlateID that can be shared through:
- A web link
- QR code
- NFC or tap interaction
- Apple Wallet-style pass
- Event or reservation form
A host-facing workflow for dinners, events, group meals, and catering orders.
A host creates a HostPlate link, guests submit their dietary needs, and the system generates a structured summary for the group.
A future compatibility layer that could compare a PlateID against:
- Menus
- Ingredient lists
- Events
- Catering options
- Group meal plans
ScanPlate is not part of the initial MVP.
Portable identity products face a cold-start problem.
A dietary profile only becomes useful when another person or system is prepared to read it. Consumer-only applications may struggle because users do not immediately have somewhere to use the profile. Restaurant-only tools may struggle because restaurants do not see enough demand to change their workflows.
HostPlate starts with an existing job that already needs to be completed:
Collecting dietary information for a group.
Hosts, caterers, event organizers, and dinner planners currently solve this through texts, forms, notes, and spreadsheets. HostPlate can provide value during a single event without requiring an existing user network.
The proposed growth loop is:
flowchart LR
A[Host Creates Event] --> B[Guests Submit Dietary Needs]
B --> C[Host Receives Structured Summary]
B --> D[Guest Saves Reusable PlateID]
D --> E[PlateID Is Shared at Future Meals]
E --> F[More Hosts and Venues Encounter PassPlate]
A one-time intake workflow becomes an entry point into a reusable dietary identity system.
- A host creates a HostPlate link for a dinner, event, group meal, or catering order.
- Guests submit allergies, restrictions, preferences, severity, and relevant context.
- HostPlate converts the responses into a structured group summary.
- The host identifies needs that require follow-up or accommodation.
- Guests are invited to save their answers as a reusable PlateID.
- The PlateID can later be shared through a link, QR code, tap, or wallet-style pass.
- Future versions may compare PlateIDs against menus, venues, and event options.
Needs to communicate dietary information clearly while retaining control over what is shared.
Needs to collect information efficiently, understand the group as a whole, and identify unresolved needs.
Needs concise, operationally relevant information that can be understood by service and kitchen teams.
Reservation, ordering, event, or hospitality software may use structured dietary information without rebuilding the identity layer itself.
PassPlate would work with several categories of data.
- Allergens
- Ingredients to avoid
- Dietary patterns
- Sensitivities
- Intolerances
- Religious or cultural requirements
- Lifestyle preferences
- Severity
- Cross-contact sensitivity
- Safe alternatives
- Preferred explanation language
- Meal or event type
- Host or organizer
- Venue
- Restaurant or caterer
- Date and time
- Group size
- Menu availability
- Location
- Language
- Accommodation deadline
- Fields approved for sharing
- Intended recipient
- Sharing purpose
- Access duration
- Full-profile versus event-specific access
- Consent history
- Revoked access
- Profile completion
- Form completion
- Share events
- Repeat usage
- HostPlate-to-PlateID conversion
- Fields frequently edited
- Drop-off points
- Summary correction rates
- Acknowledgment events
- Sharing-method usage
- Number and type of restrictions in a group
- Potentially conflicting requirements
- Missing or ambiguous responses
- Follow-up requirements
- Accommodation status
- Common substitution needs
- Unresolved safety concerns
erDiagram
USER ||--|| PLATE_ID : owns
USER ||--o{ SHARE_PERMISSION : controls
HOST ||--o{ EVENT : creates
EVENT ||--o{ GUEST_RESPONSE : collects
PLATE_ID ||--o{ GUEST_RESPONSE : supplies
EVENT ||--|| GROUP_SUMMARY : generates
VENUE ||--o{ EVENT : supports
MENU ||--o{ MENU_ITEM : contains
VENUE ||--o{ MENU : provides
- User ID
- Display name
- Contact preferences
- Consent settings
- Account status
- Plate ID
- Allergies
- Restrictions
- Preferences
- Severity levels
- Cross-contact concerns
- Safe alternatives
- Disclosure language
- Verification status
- Last updated date
- Event ID
- Host ID
- Venue
- Date and time
- Guest count
- Submission deadline
- Accommodation status
- Event ID
- Guest or Plate ID
- Event-specific needs
- Additional notes
- Follow-up required
- Submission status
- Restriction categories
- Number of affected guests
- Severity distribution
- Conflicts
- Missing information
- Recommended follow-up questions
PassPlate is not only a place to store information. Its value comes from helping people make better coordination decisions.
- What information should I share for this event?
- Should I share my full profile or only relevant fields?
- How should I explain a dietary need clearly?
- What questions should I ask the host or venue?
- Does the available information suggest that additional confirmation is needed?
- Can the current venue or menu support the group?
- Which responses require clarification?
- Are there restrictions that are difficult to accommodate together?
- Should the menu, restaurant, or caterer change?
- Which details need to be communicated to the kitchen?
- Which guests still need confirmation?
- Which guests require direct follow-up?
- Which requests involve cross-contact concerns?
- Where may substitutions be needed?
- What information must be surfaced to kitchen and service teams?
- Which requests cannot be confidently accommodated?
- Where do users abandon profile creation?
- Which fields are frequently misunderstood?
- Which sharing method creates the least friction?
- Does HostPlate lead to reusable PlateID creation?
- Which parts of the generated summary require correction?
- What integrations would eliminate the most manual work?
- What information is useful enough to collect and safe enough to retain?
AI is positioned as a communication and coordination layer, not as a medical, nutritional, or allergy-safety authority.
Potential uses include:
- Converting free-text responses into structured categories
- Separating preferences from hard restrictions
- Producing host-facing group summaries
- Translating dietary information into clear language
- Identifying missing or ambiguous responses
- Generating follow-up questions
- Comparing structured profiles with menu descriptions
- Reducing repeated manual data entry
flowchart LR
A[Guest Free-Text Response] --> B[Structured Extraction]
B --> C[User Confirmation]
C --> D[Normalized Dietary Record]
D --> E[Event-Specific Summary]
E --> F[Host Review]
- Users confirm extracted information before it is saved.
- AI output is treated as assistance, not verification.
- Safety-critical claims are never inferred without confirmation.
- Ambiguous information is surfaced rather than silently resolved.
- The system does not claim that a food, meal, or venue is medically safe.
- Human confirmation remains necessary for allergy and cross-contact decisions.
The individual owns and controls their dietary identity.
Users should share only the information needed for a particular context.
Hosts and restaurants need concise, actionable information rather than raw profile data.
The product should reduce awkward disclosure and avoid making users feel like a burden.
The system should standardize information without forcing every dietary need into the same category.
The product should surface uncertainty rather than make unsupported safety claims.
PassPlate should work with existing food, event, ordering, and hospitality systems.
Dietary information may reveal personal, health-related, religious, or cultural details. PassPlate should therefore be designed around data minimization and explicit user control.
The proposed privacy model includes:
- Collecting only information needed for the selected use case
- Event-specific sharing controls
- Clear recipient visibility
- Time-limited or revocable access
- Separate treatment of preferences and safety-critical restrictions
- User confirmation before information is structured or summarized
- Avoiding unnecessary long-term storage
- Clear deletion and export controls
- No selling of sensitive dietary-profile data
The initial MVP is a web-based HostPlate intake and summary workflow with a reusable PlateID path.
- HostPlate event creation
- Guest dietary intake form
- Allergy and restriction entry
- Severity and cross-contact tagging
- Structured host summary
- Guest follow-up indicators
- Reusable PlateID creation
- Shareable profile link
- QR-based profile access
- Apple Wallet-style pass concept
- AI-assisted dietary explanation
- Basic waitlist and validation capture
- Restaurant marketplace
- Payments
- Reservation infrastructure
- Medical or nutritional recommendations
- Claims of verified meal safety
- Full menu-compatibility engine
- Deep restaurant-platform integrations
- Native mobile applications
- Automated accommodation guarantees
Meals or events in which dietary needs are clearly communicated and acknowledged before food is served.
- HostPlate creation rate
- Guest response completion rate
- Time required to create an event
- Time required to submit dietary information
- Host summary usefulness rating
- Number of responses requiring clarification
- HostPlate-to-PlateID conversion
- Repeat PlateID sharing
- Profile completion rate
- Summary correction rate
- Waitlist conversion
- Return usage across multiple events
- Hosts experience enough friction collecting dietary information to use a dedicated workflow.
- Guests prefer a structured intake experience over explaining their needs through text.
- Hosts find a consolidated summary more useful than raw individual responses.
- Guests are willing to save their information as a reusable PlateID.
- Users value selective sharing rather than sending their full dietary profile.
- A link, QR code, or wallet-style pass reduces repeated explanation.
- Restaurants and caterers can use structured summaries without adding excessive workflow burden.
- AI-generated summaries save time while remaining accurate after user confirmation.
- Host interviews
- Guest interviews
- Landing-page conversion
- Waitlist signups
- Prototype usability tests
- Form-completion analysis
- Summary-correction analysis
- PlateID save conversion
- Repeat-event usage
- Caterer and restaurant workflow interviews
- Publish the landing page
- Capture waitlist demand
- Interview hosts and guests
- Test dietary-intake language
- Validate the HostPlate workflow
- Event creation
- Guest intake
- Structured summary
- Follow-up indicators
- Basic sharing and permissions
- Save guest responses
- Create portable profiles
- Add event-specific sharing
- Add QR and wallet-style access
- Group compatibility insights
- Menu and venue context
- Caterer-facing summaries
- Accommodation confirmation workflows
Potential integrations may include:
- OpenTable
- Resy
- Toast
- Square
- DoorDash
- Uber Eats
- Partiful
- Luma
- Apple Wallet
- Google Wallet
These are future integration directions, not current product partnerships.
PassPlate/
├── AI/ # AI workflows, logic, safeguards, and future concepts
├── Design/ # UI, UX, information architecture, and design assets
├── MVP/ # Current front-end prototype and MVP implementation
├── Product/ # Product strategy, requirements, decisions, and roadmap
├── assets/ # Images, diagrams, branding, and supporting media
├── PROJECTBRIEF.md # Extended product brief
└── README.md # Executive project overview
Concept · product strategy · systems design · front-end prototype · MVP validation
PassPlate is an active portfolio and product-development project. The current repository documents the problem, thesis, system model, user workflows, AI layer, data strategy, MVP direction, and early implementation.
It is not yet a fully launched or safety-validated product.
The repository is being expanded to include:
- Detailed system architecture
- Data schema
- Permission model
- End-to-end user journeys
- Product requirements document
- Decision log
- HostPlate workflow specification
- Interface designs
- Product analytics plan
- AI evaluation framework
- Competitive landscape
- User-research findings
PassPlate is a conceptual product and portfolio project at the intersection of dietary identity, hospitality, product design, and AI-assisted communication.
It is not a medical, nutritional, diagnostic, or allergy-safety tool. It should not be relied on to determine whether food, a restaurant, or an event is safe for a specific person.
Users should confirm allergy, ingredient, preparation, and cross-contact information directly with qualified food-service staff.
Nitin Bhogaraju
Biomedical Engineering graduate focused on consumer health, product systems, AI workflows, and human-centered design.