WORDWELLAI

WordWellAI is designed to be a privacy-first journal analyzer powered by a specialized small LLM. It screens your entries for mental health signals and routes high-risk users to life-saving resources.

Comment

WordWellAI

Inspiration

The integration of artificial intelligence within mental health spaces is an incredibly delicate process, particularly because of patient privacy and misdiagnosis. Today, the market often wraps a massive, closed-source model in a prompt and calls it a mental health app. This approach produces severe privacy risks by sending highly sensitive journal entries to third-party servers, and it often lacks domain-specific accuracy.

Inspired by this, we realized that massive scale is not the answer. We wanted to use a small, instruction-fine-tuned open-source model running on constrained hardware and prove that it could outperform generalized frontier models in mental health screening—all while guaranteeing that user data remains completely private. WordWellAI was born as a privacy-first reflection tool that screens journal entries for mental health signals and immediately routes high-risk users to professional crisis resources.

What It Does

WordWellAI is a privacy-first journal analyzer designed to act as a safe reflection tool, not a diagnostic device. The user types their journal entry into a clean Next.js interface. Instead of instantly going into the AI model, the text passes through a strict, zero-latency deterministic safety gate. Upon detecting high-risk crisis language, it immediately short-circuits the machine learning pipeline and routes the user to professional crisis resources.

If the entry is safe, it is processed by a highly compressed, instruction-fine-tuned open-source model (LiquidAI/LFM2.5-2.6B-Base) running locally via llama.cpp. The application returns a mental health signal prediction (e.g., "Low Stress Levels") alongside a confidence score and a permanent disclaimer. To ensure total user privacy, our backend uses a secure SQLite database to log anonymous device check-in counts without storing a single character of the journal entry.

How We Built It

We strictly separated our architecture to isolate heavy machine learning workloads:

  • Next.js & FastAPI Architecture: The frontend is built in Next.js, while the backend utilizes a Python FastAPI to handle the heavy lifting.
  • The Deterministic Safety Gate: LLMs are probabilistic, but crisis response cannot be. We built a zero-latency safety layer that intercepts user text before it reaches the model. If high-risk language is detected, the API immediately returns a crisis payload (e.g., suicide hotline resources).
  • Privacy-First Logging: We utilized a SQLite database to track usage analytics via anonymous X-Device-Id headers. The schema strictly prohibits columns that could store user text.
  • The AI Engine: We leveraged a quantized open-source model running via llama.cpp. By applying 4-bit NormalFloat (NF4) quantization, we compressed the model footprint drastically, allowing it to run efficiently on edge-like hardware without melting the servers.
  • Fine-Tuning Mathematics: To adapt the base model for specific mental health classification tasks, we relied on standard Supervised Fine-Tuning (SFT). The model optimizes the auto-regressive objective, minimizing the negative log-likelihood of the target mental health classification tokens $y$ given the journal input sequence $x$:

$$L_{SFT} = -\sum_{i=1}^{N} \log P(y_i | x, y_{<i})$$

This domain-specific tuning ensures the model outputs highly structured JSON (label and confidence score) rather than conversational hallucinations.

Challenges We Ran Into

The biggest hurdle we faced was cloud GPU infrastructure and memory bottlenecks. We initially used a 7B parameter transformer model, which required massive amounts of VRAM and crashed our standard free-tier instances. We refused to move toward third-party cloud APIs, as that would violate our "privacy-first" philosophy.

To solve this, we pivoted away from Mental-Alpaca and adopted LiquidAI/LFM2.5-2.6B-Base. This 2.6B parameter model is engineered for edge execution using a highly efficient hybrid architecture. It runs entirely on-device in under 2.6 GB of memory. This allowed us to fine-tune and execute the model locally on our PCs with zero dependency on the cloud. Furthermore, to protect the live demo, we designed a robust API contract with resilient fallback stubs in the Python backend so the Next.js frontend would gracefully recover even if local inference timed out.

Accomplishments That We're Proud Of

  • Zero-Data-Retention Architecture: We successfully engineered a logging system that tracks anonymous usage metrics and check-in streaks without ever touching, transmitting, or storing personally identifiable information (PII) or journal text.
  • The Deterministic Safety Gate: We built a bulletproof Python safety layer that intercepts crisis language instantly, ensuring our AI never has the chance to hallucinate when a user is in a state of high distress.
  • Edge-Native Inference: By swapping traditional transformer models for a 2.69B parameter hybrid language model designed for edge deployment, we shattered our hardware limitations. We proved you don't need a massive cloud GPU budget to build a lightning-fast screening tool.
  • Resilient API Design: Hackathon environments are notoriously unstable. We engineered a robust FastAPI contract with deterministic fallback stubs so the UI never crashes.
  • Test-Driven Development: Instead of hacking things together blindly, we wrote and passed 29 rigorous Pytest checks—including strict verifications against our database schema and safety filters—before wiring up the final UI.

What We Learned

We learned the immense value of Test-Driven Development (TDD) under pressure. Writing Pytest suites for our safety layers and database schemas before writing the actual endpoints allowed us to work in parallel without blocking frontend development. Most importantly, we learned that in sensitive domains like mental health, the most critical piece of AI software is often the code that prevents the AI from responding.

What's Next for WordWellAI

  • Domain-Invariant Hallucination Detection: We plan to integrate a rigorous hallucination detection probe to evaluate model outputs in real-time, ensuring responses remain purely supportive and never cross into clinical diagnosis.
  • Literature-Grounded Responses via RAG: To make the AI even safer, we want to introduce a Retrieval-Augmented Generation (RAG) pipeline using PostgreSQL with pgvector. This would ground the model's advice strictly in verified psychological first-aid literature and localized crisis protocols.
  • Scaling the Infrastructure: We aim to migrate our lightweight SQLite setup to a robust, distributed backend using FastAPI and Redis. This will allow us to support encrypted, opt-in user accounts for long-term mood tracking while maintaining our strict zero-data-retention philosophy for raw text.

Built With

Share this project:

Updates

Submission history