Problem
Legal intake is high-friction for callers and high-risk for firms when urgency, jurisdiction, conflict checks, and advice boundaries are handled inconsistently.
R&D case study
RoboReceptionist
Legal intake workflow that screens urgency, gathers structured information, and routes cases without inconsistent or unsafe responses.
At a glance
Context
R&D
Current state
Prototype
Role
Sole architect and backend engineer
Solution / What I Built
Built as a guarded intake architecture. A deterministic policy engine enforces jurisdiction, emergency, conflict, and legal-advice constraints before an AI layer can respond. Validated outputs are persisted with transcripts and routed to intake specialists through notification workflows.
Results
Working prototype with policy-gated intake flow, jurisdiction detection, and conflict-check pipeline
Architecture
The pipeline is shown as explicit stages so the system boundary is inspectable.
Key system pieces
Policy engine gates every interaction before LLM output can be returned.
State-driven intake flow keeps conflict checks and urgency triage early.
Transcript persistence and notifications keep the system auditable.
Core constraint
Validation and safety boundary: every LLM response must pass through a deterministic policy engine before reaching callers
Technical Stack
FastAPIPolicy EngineLLM ValidationSQLite / PostgresEmail Notifications
Applied Relevance
Where the pattern matters
- Workflow analysis
- Operational software design
- Prototype planning
- System architecture review
Proof Surfaces
Available artifacts are labeled directly. Missing visuals stay as placeholders until real screenshots are added.
System Walkthrough
Available nowThe system walkthrough is currently grounded in the intake flow and the architecture shown on this page.
- Policy-gated intake flow shows where emergency, conflict, and jurisdiction checks happen.
- Validated-response boundary keeps unsafe or non-compliant output from reaching callers.
Architecture / Flow
Available nowThe architecture diagram on this page is the strongest current proof artifact for how the system is structured.
- Policy engine sits in front of the AI layer.
- Stateful intake flow keeps high-risk questions early.
- Persistence and notifications make the system auditable after each interaction.
Operational Surfaces
Available nowThis system has real operator-facing surfaces even at the prototype stage.
- Conflict and urgency checks drive routing outcomes.
- Transcript persistence supports later review.
- Notification workflows keep intake specialists in the loop.
Artifacts & Evidence
Available nowCurrent evidence is architectural and workflow-based rather than public-production proof.
- Architecture diagram on this page.
- Intake state flow supporting the policy boundary.
- Validation boundary definition showing how unsafe output is blocked.
Limitations
What this does not claim
- This page describes the current proof available for the project.
- Additional screenshots, logs, or usage artifacts should be added before making stronger claims.
Next Improvements
Reasonable next steps
- Add stronger screenshots or walkthrough artifacts.
- Document validation checks and edge cases more completely.
- Tighten public write-up as the system matures.
Related Case Studies
More portfolio context.
Prototype / Academic ProjectApplied dashboard prototype
WeatherForge
A Minnesota severe-weather analytics dashboard that turns large NOAA weather datasets into county-level risk views, cleaned analytics layers, and decision-support reporting surfaces.
PythonShinyPlotlyParquet
Read case studyPrototype / Academic ProjectLocal RAG prototype
RAGeATM
A small explainable Retrieval-Augmented Generation prototype that retrieves local evidence first, applies a relevance threshold, and refuses unsupported questions when the corpus does not justify an answer.
PythonTF-IDFCosine SimilarityLocal Retrieval
Read case study