Advocate

Because navigating a denied claim shouldn't require a law degree.

Inspiration

One of our teammates got hit with a denied health insurance claim. Confusing paperwork, strict deadlines, expensive lawyers, and zero real support. The system felt impossible to navigate alone — so we built something to change that.

Advocate turns a denial into a strategy.

What It Does

A user uploads or pastes a denial letter, EOB, policy excerpt, or medical bill. Advocate then:

Extracts the key case details
Identifies the likely reason for denial
Detects deadlines and escalation risk
Builds a visual attack-tree strategy
Scores evidence by relevance using transformer-based analysis
Drafts the appeal documents needed to move forward

As new evidence is uploaded, the strategy updates dynamically.

Our in-app assistant BERT keeps users grounded throughout — explaining the case, missing evidence, deadlines, and next steps in plain language.

How We Built It

Frontend

// Next.js + React + TypeScript + Tailwind
const Advocate = () => <ClaimWorkspace strategy={attackTree} />

Backend AI Pipeline

# FastAPI + PyTorch + scikit-learn + BERT
pipeline = ingest → extract → analyze → strategize → score → draft → update

The math behind evidence scoring — each piece of evidence gets a relevance weight:

$$ R(e_i) = \frac{\sum_{j} w_j \cdot \text{sim}(e_i, c_j)}{|C|} $$

Where $ w_j $ is the weight of case feature $ j $ and $ \text{sim} $ is semantic similarity to the denial context.

Tech Stack

Layer	Tools
Frontend	Next.js, React, TypeScript, Tailwind CSS
Backend	FastAPI, Next.js API routes
AI/ML	OpenAI API, PyTorch, scikit-learn, BERT
Auth + DB	Firebase Auth + Firestore

Challenges

Real PDFs are messy. Image-heavy, badly structured, inconsistent across environments — making reliable document parsing took serious iteration.

Data quality was a wall. Most public datasets were synthetic or too clean to reflect real-world denial reasoning.

And beyond the technical: the product had to feel trustworthy. It wasn't enough to generate a summary — users needed to understand why a branch was recommended and whether a next step was worth their time.

What We Learned

The hardest part of building an AI product isn't model performance — it's turning complex reasoning into something a person can actually trust and act on.

The best AI doesn't just impress. It clarifies.

What's Next

Expanding into tenant rights, employment disputes, and consumer protection
Mobile OCR for bills and EOBs
Expert escalation workflows for cases that need legal review
Better model-backed explainability and scoring

AI Use

Yes, we used AI heavily during development.

More than 70% of the code was AI-assisted in some form, but the architecture, product direction, integration decisions, debugging, and final product shaping were team-driven.