Clean Slate Agent

Demo

About

The problem it solves Nearly 1 in 3 American adults has a criminal record. Most are eligible for some form of expungement or record sealing — but the legal system is expensive, confusing, and intimidating. Clean Slate Agent removes those barriers. **For individuals:** Talk to the agent in plain language about your situation. It assesses your eligibility based on the expungement laws of your state, covering 10 states with different rules, terminology, and waiting periods. You can upload a photo of your RAP sheet and the agent reads it. If you're eligible, you receive a privacy-preserving credential — a proof that you can share with employers without revealing any details about your record. **For employers:** Verify a candidate's eligibility using only a credential ID. You receive a single answer: eligible or not eligible. You never see the offense type, conviction date, or any underlying record detail. This is what Ban the Box laws intended — and what cryptographic privacy now makes enforceable. **The privacy guarantee is structural, not policy.** Canton Network's sub-transaction privacy ensures that employers *cannot* see redacted fields — they are cryptographically invisible, not just hidden by the application. The agent operates its own wallet on Base, funded by employer verification micropayments, so individual help is always free. Use of AI tools and agents Claude (Anthropic) is the core intelligence layer. It serves three distinct roles within the system: **1. Conversational Legal Aid Agent** The primary interface is a chat powered by Claude claude-sonnet-4-20250514. A dynamic system prompt is built at runtime from a structured JSON knowledge base containing the expungement rules, statutes, waiting periods, and exclusions for 10 U.S. states. When the user mentions a state, the prompt narrows to only that state's rules. The agent guides the user through questions about their offense, timing, and sentence status, then makes an eligibility determination. That determination is the trigger — the backend automatically creates a Canton Network credential when the agent says "eligible." **2. Document Analysis (Claude Vision)** Users can upload a photo of their RAP sheet (criminal record summary). The image is sent to Claude as a base64 content block alongside instructions to extract offense types, charge codes, dates, dispositions, and sentence details. The agent confirms what it found before assessing eligibility, since RAP sheets are often hard to read. **3. Structured Data Extraction** Every chat exchange runs through a second Claude call with a dedicated extraction prompt. This silently parses the conversation into structured JSON — state, offense type, conviction date, sentence status, eligibility determination — which the backend uses to create Canton credentials and populate the case file. This extraction runs in parallel with the user-facing response. **How the AI connects to the broader system:** - Claude determines eligibility → backend creates a Daml credential on Canton Network - Canton credential gives the individual a credential ID → shareable with employers - Employer verifies credential via x402 micropayment → receives only "eligible" or "not eligible" - Agent logs activity to its smart wallet on Base Sepolia The AI never sees or stores the credential itself. It makes a determination; the cryptographic and economic layers handle the rest.

How it's made

Challenges we ran into **Canton's Daml type system vs. real-world data.** The Daml `Date` type requires strict YYYY-MM-DD format, but people describe dates loosely — "back in 2019" or "a few years ago." The AI extraction would return `convictionDate: "2019"` and Canton would reject the contract creation with a cryptic `spray.json.DeserializationException`. We had to build a date normalization layer that gracefully converts partial dates into valid Daml values while preserving accuracy. **Privacy architecture contradictions.** Our first employer flow had employers *typing in* the offense details themselves to get an assessment — which completely defeated the purpose of Canton's privacy layer. We had to rethink the entire flow: the individual now receives a credential ID in the chat, shares it with the employer, and the employer verifies using only that ID. They never input or see any record details. This was the hardest design problem — making sure the privacy guarantee held end-to-end, not just at the ledger layer. **Consuming vs. nonconsuming Daml choices.** Our initial `VerifyEligibility` choice was consuming, meaning it archived the credential contract after a single employer checked it. A credential that can only be verified once is useless. We had to add the `nonconsuming` keyword, rebuild the DAR, and redeploy — a small code change but a fundamental correctness issue. **LLM output parsing.** Claude would intermittently wrap JSON responses in markdown code fences (```json ... ```), causing `JSON.parse()` to fail silently and break the case extraction pipeline. We built a `parseLLMJson()` helper to strip formatting, but the deeper lesson was that every LLM output boundary needs defensive parsing.