Overview
A tool that handles legal intake and case management from end to end, built around the Claude API. It captures a client inquiry, uses Claude to triage it, stores it as structured data, and gives staff a dashboard to track the whole caseload. Privacy is part of the design, not something added at the end.
Built solo as a take-home project for a Claude AI Specialist role. The brief asked for an Intake Assistant plus one of two additional components. I built the Intake Assistant and the Case Tracking System, because the two connect naturally: an intake flows straight into the tracker.
The Problem
Law firms receive client inquiries through many channels: web forms, email, phone notes, chat. Someone has to read each one, work out what kind of case it is, judge how urgent it is, and route it to the right person. That work is slow, easy to get wrong when volume is high, and every inquiry is full of sensitive personal information that has to be handled carefully.
What It Does
1 Intake Assistant
Captures an inquiry from a structured form, a pasted email, or a chat transcript. Uses Claude to summarize the matter, categorize it into one of 11 practice areas with a confidence level, assign an urgency level against a written rubric, and extract key facts, potential deadlines, recommended next steps, and missing information. The result is saved as structured data with a one-click Excel export.
2 Case Tracking System
A dashboard with caseload metrics and filters by practice area, urgency, and status. Per-case detail views with an editable status workflow. An AI generated caseload briefing that summarizes the whole caseload and flags priorities. One-click Excel export of the full case list.
3 Data Privacy and Confidentiality
Detects sensitive data in free text (emails, phone numbers, SSNs, payment card numbers, addresses, dates, and known client names) and redacts it to placeholder tokens before any text is sent to the Claude API, so the model never receives raw client PII. Contact details are masked by default in the interface, with reveal as a logged action. Only the minimum is stored, the raw inquiry text is never persisted, and an append-only audit log records every privacy-relevant action.
Tech Stack and Why
| Layer | Choice | Why |
|---|---|---|
| LLM | Claude Opus 4.7 via the official Anthropic Python SDK | Nuanced legal triage benefits from the most capable model. |
| Structured output | messages.parse with a Pydantic schema | Guarantees a validated result object instead of brittle text parsing. |
| Cost control | Prompt caching on the intake system prompt | The system prompt is identical on every intake, so repeat runs reuse the prefix. |
| Interface | Streamlit | Fast to build a clear, usable interface that a reviewer can run locally. |
| Storage | SQLite with openpyxl for Excel export | Self-contained, no external accounts needed to run or review it. |
Architecture
The flow is: capture the inquiry, detect and redact PII, show a transparency panel, send only redacted text to Claude, get back a validated structured result, store it, and surface it in the dashboard and insights views.
A key design point: redacted text is the only thing that ever reaches the API. The privacy layer sits between the user and the model, not after it. The full workflow diagram and a component breakdown are in docs/architecture.md in the repository.
Project Scope
This was a time-boxed take-home project, roughly 6 to 10 hours. The goal was to demonstrate practical solution design for a legal workflow, not to ship a production system. The scope was set deliberately.
In scope and built
- The Intake Assistant: capture, summarize, categorize, prioritize, extract.
- The Case Tracking System: dashboard, filters, case detail, status workflow, insights, export.
- The full privacy layer: detect, redact, mask, minimize, audit.
- Complete documentation: README, architecture diagram, Microsoft 365 integration plan, and data privacy notes.
Intentionally out of scope
- Authentication and multi-user roles. Described in the integration plan.
- Hosting and deployment. The app runs locally with documented steps.
- ML-based PII detection. The prototype uses pattern matching, which is reliable and auditable for structured identifiers.
- A live Microsoft 365 integration. Planned in detail, not implemented.
Why these boundaries: the goal was a clear, working demonstration of the core idea, with the production path documented rather than half-built. Knowing what to leave out, and writing down why, is part of the work.
Design Decisions and Tradeoffs
- Case Tracking System over Knowledge Assistant. It forms one coherent story with the Intake Assistant: an intake flows straight into the tracker.
- Redact before send, not after. The model never receives raw PII at all. That is a stronger guarantee than relying on the model to behave correctly with sensitive data.
- SQLite over a hosted database. A reviewer can clone the repo and run it instantly, with no accounts to set up.
- Structured outputs over free-text parsing. The triage result is always a valid, typed object, which removes a whole class of bugs.
What I Would Build Next
- Authentication and role-based access for intake staff, attorneys, and admins.
- Named entity recognition to catch free-form names that pattern matching misses.
- The Microsoft 365 integration: Outlook intake capture, Dataverse or SharePoint storage, Power Automate routing, Teams alerts for urgent cases.
- Conflict checking against existing clients.
- Automatic notifications for high-urgency intakes.
What This Project Demonstrates
- Designing a practical workflow around an LLM, not just calling an API.
- Working with the Claude API: structured outputs, prompt caching, adaptive thinking.
- Privacy-first engineering: detection, redaction, masking, data minimization, and auditing.
- Clear technical writing: README, architecture diagram, integration plan, privacy notes.
- Scoping judgment: deciding what to build, what to document, and why.
Live Demo
The app is deployed and running here: kimbrough-legal-intake-z65qurjkiezgbwebcxepdz.streamlit.app
The live demo is access-protected with a password, in keeping with the project's privacy-first design, so confidential data stays private. The app can also be run locally with streamlit run app.py. Full setup steps are in the README in the repository.