UMaine Student Food Security Assistant

An empathetic AI chatbot that analyzes a student's unique situation to break down food assistance criteria into clear next steps, guiding stressed UMaine students past the shame of asking for help.

Comment

Project Story

Inspiration

Moving off campus and living on your own for the first time is a massive wake-up call. We've all seen friends struggle to balance rent with groceries, but navigating the actual state system for help is incredibly intimidating and honestly, kind of embarrassing.

What it does

Our solution is an empathetic, AI-driven chatbot designed specifically for newly independent UMaine students who are facing sudden food insecurity but don't know where to turn or feel too intimidated by the system to ask for help.

How It Works:

  • Conversational Experience: Instead of forcing students to read through dense policy documents, the AI engages in a supportive, plain-language conversation to understand their work hours, financials, and enrollment situation.
  • Intelligent System Parsing: The AI analyzes the user's specific context against local and state food assistance criteria (such as SNAP eligibility rules for students or local pantry requirements). It translates complex bureaucratic jargon into clear logic.
  • Actionable Next Steps: Rather than just spitting out a generic list of links, the chatbot generates a personalized, step-by-step checklist. This includes exactly which local resources they qualify for (like the campus pantry or community programs), what documents they need to gather, and how to apply.
  • Stigma Reduction: Built with a trauma-informed, empathetic tone, the interface actively counters the shame and anxiety associated with seeking public benefits.

How we built it

Since this was our first time touching RAG pipelines and vector databases, we had a massive learning curve trying to figure out how embedding models actually talked to our Markdown files. Our process relied on clear engineering principles, moving from broad system logic to a hyper-localized, transparent data pipeline.

1. Data Collection & Knowledge Architecture

Initially, we focused broadly on SNAP benefits for generic college students. However, reading the system rules revealed a critical barrier: SNAP enforces strict exemptions for students (such as requiring 20 work hours per week). To prevent our AI from hitting a dead end when a student was ineligible for state aid, we pivoted to a hyper-local approach.

We chose the University of Maine (UMaine) to ground our prototype in a real-world context. We compiled a structured Markdown knowledge base containing:

  • State-specific Maine SNAP student exemption rules.
  • Localized UMaine campus resources (such as the Black Bear Food Pantry).
  • Community-level alternative food assistance programs.

2. The Technical Stack (No-Code Backend)

We wired up the backend using Flowise, dragging and dropping nodes to build out the logic:

  • LLM Engine: Powered by the llama-3.3-70b-versatile model via Groq AI for rapid inference.
  • Vector Pipeline: The Markdown knowledge base was embedded using HuggingFace Inference Embeddings and indexed into an In-Memory Vector Store for Retrieval-Augmented Generation (RAG).
  • Context Retention: Integrated a Buffer Memory node to ensure the chatbot retains stateful conversation history, preventing the user from having to repeat sensitive financial context.

3. System Prompt Engineering & Chatbot Logic

To satisfy the brief's requirement of a clear User Input -> AI Reasoning -> Actionable Output flow, we engineered a strict System Prompt dictating exactly how the LLM should parse information:

  • Empathetic Safeguard: Explicitly instructed the model to maintain a trauma-informed, non-judgmental tone to mitigate the stigma of food insecurity.
  • Paced Intake: Forbidden from overwhelming the user, the AI is hard-coded to collect situational data (enrollment status, weekly work hours, and income) one single question at a time.
  • System Reasoning: The prompt forces the LLM to run an internal eligibility check against the vector-stored rules before drafting a response, ensuring it translates complex bureaucratic jargon into simplified, conditional logic.
  • Actionable Output: Configured the final output to generate structured, step-by-step next steps (e.g., specific document checklists or pantry hours) rather than raw URLs or static lists.

AI Tools & Collaboration Disclosure

To maximize our development velocity and rigorously test our architecture, we utilized Gemini as an advanced AI pair-programmer and systems consultant throughout the building process. While the human team was entirely responsible for designing the solution architecture, formatting the UMaine knowledge base, mapping out the state eligibility rules, and configuring the Flowise canvas nodes, Gemini acted as an invaluable technical collaborator. The AI assisted us in rapidly drafting system prompts, diagnosing unexpected model deprecation errors, debugging conversational memory loops, and acting as a sounding board to refine our edge-case testing scenarios.

🧠 Algorithmic Eligibility Interpretation & Logic Flow

Because providing incorrect state policy guidance can cause real financial and emotional harm, we engineered a deterministic, conditional evaluation pipeline directly into our system prompt. Instead of letting the LLM loosely guess eligibility, it is forced to process student data through a strict three-part sequential gate matching Maine state regulations: Meal Plan Clearance ➔ Student Exemption Validation ➔ Gross Income Verification

  1. Gate 1: The Meal Plan Disqualifier (Boolean Check) The system first verifies if the student receives more than 50% of their meals through a campus dining plan. If True, the evaluation loop breaks instantly. The bot terminates SNAP screening and triggers a hard pivot to local campus resources like the Black Bear Exchange or Swipe Out Hunger.

  2. Gate 2: Student Exemption Verification (Conditional OR Logic) If the student passes Gate 1, the AI evaluates whether they meet at least one state-approved exemption for higher-education students. It naturally extracts conversational signals to check if the student works 20+ hours per week, participates in Federal Work-Study, or qualifies under other specific criteria (e.g., caring for a dependent child).

  3. Gate 3: Gross Income Baseline (Numerical Threshold Comparison) Only when Gates 1 and 2 are cleared does the AI interpret financial thresholds. It identifies the student's household structure (dynamically defining a "Household of 1" if they prepare food separately from roommates) and explicitly tests their gross monthly income against 200% of the Federal Poverty Level for Maine — verifying if they fall under the $2,609/month baseline.

By structuring the prompt this way, we transformed an unpredictable, open-ended language model into a reliable, sequential rule-interpreter that mirrors a real caseworker's intake workflow.

🧪 Verification & Test Matrix

To respect the strict video runtime, our pitch video focuses heavily on the happy-path logic and our immediate crisis safety override. However, our architecture was rigorously stress-tested across multiple boundary conditions. Complete conversational logs for these additional test cases can be viewed as high-resolution screenshots in our project gallery:

  • Test Case: Multi-Variable Extraction & Memory Retention

    • The Input: A complex, unstructured, multi-sentence paragraph outlining enrollment, off-campus housing, and specific weekly job hours.
    • The AI Behavior: The Flowise RAG pipeline cleanly maps individual variables into structured signals, references short-term memory to ensure it never asks a redundant question, and evaluates the data accurately against the Maine gross income threshold ($2,609/month for a Household of 1).

  • Test Case: The Ultimate Disqualifier (Campus Meal Plan)

    • The Input: A student sharing severe food anxiety but mentioning they have an active campus dining plan.

    * The AI Behavior: The system prompt executes an immediate hard stop on state SNAP screening to avoid giving misleading hope. It instantly shifts the conversation to on-campus resources like the Black Bear Exchange and the Emergency Meal Swipe Bank.

Challenges we ran into

1. Massive System Prompt Re-Engineering & Guardrail Loops

  • The Challenge: Large Language Models are naturally biased to be chatty and keep checklists going. Initially, when a student stated they had a full campus meal plan (an absolute disqualifier for state SNAP), the LLM would acknowledge the rule but then counter-productively keep asking about work hours anyway. Additionally, it suffered from conversational short-term memory blind spots—blindly asking, "Are you enrolled at least half-time?" even if the student had just stated they were full-time in their very first sentence. This was a bit exhausting at one stage as creators.
  • The Solution: We had to completely tear down and re-engineer our System Prompt from scratch multiple times. We designed a highly rigid, deterministic Strict 3-Part Evaluation Chain directly into the prompt. We coded hard-stop attention commands ("STOP screening immediately") and engineered an explicit memory-validation layer. This forced the agent to cross-reference the user's past state declarations and execute an instant, aggressive routing pivot the exact moment a disqualifier or exemption was met.

2. Knowledge Base Alignment & Formatting for High-Stress UX

  • The Challenge: Connecting raw government policy data to an LLM created a terrible user experience. The bot initially responded with massive "walls of text" that would completely overwhelm a stressed, food-insecure student reading on a mobile phone. Furthermore, our semantic vector database struggled to balance technical SNAP rules with immediate campus relief protocols.
  • The Solution: We heavily restructured and rewrote our underlying Knowledge Base Markdown files. We stripped out dense bureaucratic jargon and re-indexed the data so the vector nodes could cleanly isolate campus-specific metadata (like the exact address of the Black Bear Exchange at 139 Rangeley Road or the Emergency Meal Swipe Bank). We paired this database overhaul with strict markdown formatting constraints in our prompt to guarantee that every output automatically parsed into clean, scannable bullet points, bold headers, and exact step-by-step document checklists.

3. Overriding the RAG Pipeline for Safety Triage

  • The Challenge: When simulating a student experiencing severe, immediate crisis (e.g., sharing that they had "$5 left" or "haven't eaten in days"), our semantic search vector database couldn't find a clean mathematical match for extreme hunger inside the technical policy files. This caused the model to default back to regular, clinical SNAP screening questions instead of offering urgent help.
  • The Solution: We engineered an authoritative Critical Override Rule at the absolute top of our prompt hierarchy, completely bypassing the standard RAG retrieval loop during a crisis. By putting this safety filter ahead of the vector database search, we guaranteed that a student in severe distress is immediately recognized and routed to the UMaine Dean of Students crisis matrix ([email protected]) in a single turn.

4. The Infrastructure Pivot: API Instability

  • The Challenge: Right in the middle of our core testing loop, our backend completely died with 400 and 404 network errors. We realized our original models were deprecated mid-weekend, forcing us to scramble through documentation to swap over to llama-3.3-70b-versatile under a ticking clock.
  • The Solution: We scrambled into the API documentation, successfully re-configured our Flowise environment parameters, and seamlessly migrated our newly engineered RAG structure onto the state-of-the-art llama-3.3-70b-versatile model to restore 100% system uptime.

Accomplishments that we're proud of

  1. Zero-Failure State Machine Implementation in a Natural LLM: We successfully tamed the unpredictable nature of an LLM and forced it to act like a strict, reliable state machine. We flawlessly executed a Strict 3-Part Evaluation Chain (Meal Plan -> Student Exemptions -> Gross Income Verification) where a single gatekeeper disqualifier triggers an immediate operational pivot.
  2. Crafting a Trauma-Informed Safety Override: Technology fails if it lacks human empathy. We engineered an instant Critical Override Guardrail that monitors student distress levels. If a user inputs an extreme financial or hunger crisis, our system immediately suppresses all standard bureaucratic intake loops and serves up direct crisis contact information for the UMaine Dean of Students in less than a second.
  3. Turning Bureaucratic Jargon into Highly Scannable UX: We successfully optimized both our raw Knowledge Base data and our system's output formatting to completely eliminate "walls of text," translating dense legal requirements into intuitive Markdown complete with bold headers, bullet points, and explicit document checklists.
  4. Technical Resilience Under Infrastructure Pressure: When our initial backend models were suddenly deprecated mid-hackathon, we didn't panic. We rapidly diagnosed the API errors, refactored our Flowise configuration parameters, and seamlessly migrated our complex RAG pipeline over to the llama-3.3-70b-versatile architecture without losing any of our custom logic.

What we learned

  1. Deterministic Logic Requires Hard Engineering: LLMs are inherently built to be conversational, making them naturally bad at following strict, legal gatekeeper logic out of the box. Forcing an AI to act like a strict state machine requires meticulous prompt architecture and structured evaluation chains to eliminate redundant loops.
  2. Vector DBs Need Upstream Safety Valves: Semantic search is blind to human emotion. If a student inputs an extreme crisis, a standard vector database will mechanically try to match technical policy jargon instead of offering immediate help. We learned how to build a dual-path pipeline to sort triage issues from standard informational queries.
  3. Data Formatting is 80% of the UX Battle: Dumping raw government text into a database results in overwhelming text clusters. Aggressively cleaning, chunking, and indexing our markdown files allowed the AI to blend strict compliance with human-centric formatting tailored for mobile screens.
  4. Navigating Infrastructure Volatility: The AI landscape moves fast. Dealing with mid-hackathon model deprecations taught us how to rapidly diagnose API network errors under pressure, read infrastructure logs, and confidently pivot backend assets without breaking core software layers.

What's next for our project

  1. Direct API Integrations with Live Campus Resources: Instead of just routing a student to an email address during an emergency, we want to integrate our assistant directly with the UMaine Student Life calendar API. This would allow a student experiencing an immediate food crisis to instantly book an emergency intake appointment right inside the chat window.
  2. Multi-State Policy Scaling via Dynamic RAG Routers: While our current vector database is calibrated for Maine's SNAP guidelines, the core architecture is state-agnostic. Our next step is to engineer an upfront geolocation router to dynamically swap out underlying vector databases based on the user's specific university campus and state thresholds.

Built With

Share this project:

Updates

Submission history