Inspiration

About 42 million Americans rely on SNAP to put food on the table. When a state agency cuts or ends those benefits, the decision arrives as a letter, and federal law is specific about what that letter has to say: when the change takes effect, why, the old and new amounts, and how to appeal.

A lot of notices fall short of that, and most families have no way to tell. The letter reads like a final verdict, so they skim it, worry, and file it away. Fair-hearing rights only help people who know a notice can be challenged. We wanted anyone holding one of these letters to know in seconds whether it meets the law, and what to do if it doesn't.

What it does

ClaimGuard checks a SNAP notice against federal notice requirements.

Add the notice. Paste the text, upload a PDF, or load a sample.
Claude reads it. The letter becomes structured fields: notice date, effective date, action type, old and new benefit amounts, appeal deadline, and whether appeal rights, hearing instructions, and language assistance are present.
Ten deterministic rules check it against 7 CFR 273.13 and 273.10(g). Each result is a pass, a critical defect, or a warning, with the regulation it cites and a plain-language next step.
Draft a hearing request. If there are defects, ClaimGuard drafts a fair-hearing letter that lists each one with its citation. The letter also asks for benefits to continue during the appeal under 7 CFR 273.15(k), and the user can edit it before sending.

Two of the checks are arithmetic, not just "is this field present." A notice labeled a reduction has to actually reduce the benefit:

$$ \text{action} = \text{reduction} \;\Rightarrow\; B_{\text{new}} \le B_{\text{old}}, \qquad B_{\text{new}} \ge 0 $$

And the household has to get at least ten days' warning:

$$ \Delta = d_{\text{effective}} - d_{\text{notice}} \ge 10 \text{ days} $$

Our defective sample shows why the first check matters. It calls itself a reduction but moves the benefit from $280 to $315, so it's a contradiction on its face.

When a notice is clean, ClaimGuard says so, and doesn't invent a problem to look useful. It's free, it needs no account, and it stores nothing.

How we built it

Frontend: Next.js 16 and React 19. The landing page is a scroll-driven story: painted scenes rendered with custom WebGL shaders, which carry the product's message as you scroll. /dashboard is the working checker.
API layer: a Next.js route (/api/analyze) that validates input (text up to 50,000 characters, PDFs up to 10 MB) and forwards it to the engine, so the browser never needs CORS or the backend's address.
Engine: a FastAPI service in Python.
- pdf_parser.py pulls text from PDFs with pdfplumber.
- extractor.py asks Claude (claude-sonnet-4-6) to return the notice as a fixed JSON schema. If no API key is set, it falls back to a keyword extractor.
- rule_engine.py runs the ten rules as plain Python functions. Each one returns rule_id, citation, passed, severity, defect_message, and action_hint.
Privacy by construction: notice text is checked in memory and never written to disk or logs. Only the text's length and the defect count are logged.

The core design choice is that the model reads and the rules decide. Claude never judges whether a notice is compliant. It only fills in fields. That makes the outcome deterministic: the same notice always gets the same answer, and every finding traces back to a specific regulation.

Challenges we ran into

Keeping the AI out of the verdict. It was tempting to ask the model "is this notice legal?" We deliberately didn't. Pinning the extraction to a strict schema and moving every judgment into code took more work, but it's the only way we could stand behind a citation.
Extraction quality really matters. When we ran the engine on the keyword fallback without Claude, it missed dates and amounts that were clearly in the letter. It flagged a compliant notice as defective, and it missed the $280 → $315 contradiction. That convinced us the fallback is only for when the service is degraded, and the UI now tells users when it's active.
"Missing" and "unknown" are different things. If a date can't be read, the timing check can't fail the notice on it. We had to decide, rule by rule, when missing data is itself a defect (no appeal deadline) and when it just means the check can't be run.
Two runtimes, one deploy. The Next.js frontend deploys easily. The Python engine has to be hosted separately and reached through the proxy. The dashboard reports the engine's status (online, fallback, or offline), so nobody gets a silent failure.
Talking about the law without giving legal advice. Every screen, and the landing page, says ClaimGuard is not a law firm. A clean result means the federal basics are present, not that the agency's decision is correct.

Accomplishments that we're proud of

A checker whose answers are explainable and repeatable: ten rules, each with a citation, and no black-box verdicts.
Catching defects a person skimming the letter would miss, like a "reduction" that raises the benefit, or ten days' notice that turns out to be seven.
Going from finding to action: every defect comes with a next step, and the hearing request is drafted with the citations already filled in.
A no-account, nothing-stored design, built for households that are right to be wary of handing their data to another system.
A landing page that explains fairly dry federal procedure through a story people actually scroll through.

What we learned

In legal tech, trust is the product. One confident, wrong citation undoes a hundred correct ones. The most valuable things we built were constraints: the schema, the rules, and the disclaimers.
LLMs are excellent at turning messy documents into structure, and they're the wrong tool for deciding legal outcomes. Splitting those two jobs made the system simpler to test and easier to explain.
Communicating honestly about scope matters as much as the scope itself. Users should know that a clean result means "the federal floor is met," nothing more.
Designing for people under stress means plain words, obvious next steps, and no sign-up.

What's next for ClaimGuard

State rules on top of the federal floor. Many states add requirements. We'd add them state by state, and only once each rule is verified.
Deploy the engine next to the frontend so the live checker works end to end on the public site.
More programs. Medicaid and TANF notices follow similar due-process rules, so the extract-then-rule architecture should carry over.
Languages. Notices and results in Spanish and other common languages, matching the language-assistance rule we already check.
Partners. Legal aid offices, food banks, and benefits navigators could put ClaimGuard in front of every family they serve, and send the hard cases to a human advocate.