I built a complaint-review application around public CFPB data. It brings routing suggestions, emerging themes and supporting evidence into one queue, while keeping the final decision with a person.
Why it mattered
A queue needs more than a prediction
A high-confidence label is not enough to handle a complaint. Reviewers need the source evidence, clear reasons for manual attention and a way to see when the system cannot answer.
What I built
One path from data to review
I connected validated public-data snapshots to a DuckDB analytical layer, a calibrated product router and evidence-backed narrative summaries. A FastAPI service and React interface expose the queue, trends and model-monitoring views.
What I checked
Quality before efficiency claims
The documented frozen sample contains 50 summaries reviewed manually with AI assistance. Forty-five were marked as having every claim supported; all 50 had exact supporting quotes. Those checks assess this selected sample, not every complaint or a reduction in handling time.
What comes next
Measure the work it helps someone do
A useful next evaluation would compare manual and assisted handling on the same task design, measuring time, corrections and unresolved cases. Staff time saved and operational adoption have not yet been measured.
Evidence and limits
The frozen review reports a mean factuality score of 4.86/5, 45/50 summaries with all claims supported and 50/50 with exact quotes. The trained routing evaluation uses a separate chronological test window. These are bounded snapshot results. Public complaint counts are not a representative measure of consumer experience or a basis for ranking companies. The public demo reads a limited set of current complaints; trained routing, LLM generation and persistent review writes are unavailable there. It is a demonstration rather than a production case-management system.