Case Resolution Copilot

The problem

Complex support escalations are rarely blocked by a lack of prose. They are blocked by fragmented facts, unclear policy authority, risky side effects, and uncertain outcomes after an external system times out.

This product is therefore not a general chatbot. It is a governed decision workspace for cases that need investigation, policy evidence, human authority, and a recoverable action trail.

What I built

The role-aware workspace supports Specialists, Supervisors, Administrators, and Auditors across case queues, review workspaces, controlled actions, policies, quality reporting, connections, and team administration.

The core journey is:

1. Ingest or open a case and gather the relevant business evidence.
2. Retrieve only policy versions that are applicable and currently valid.
3. Build a Decision Brief that separates verified facts, missing information, risk, uncertainty, and the proposed response.
4. Bind human review to an immutable snapshot of the exact evidence, policy, and recommendation that was reviewed.
5. Register a controlled action with idempotency and receipt tracking.
6. Reconcile an unknown outcome before another side effect is allowed.

The frontend and FastAPI backend are organized as a modular monolith. Domain services, PostgreSQL persistence, and role-aware UI commands stay separated by business boundary without introducing a distributed runtime the product does not need.

Architecture and authority

The implementation uses Next.js, React, TypeScript, Clerk, FastAPI, PostgreSQL/pgvector on Neon, LangGraph, OpenAI, and Vercel. PostgreSQL, rather than the model or graph runtime, is the durable source of truth for business state.

OpenAI is deliberately bounded to narrative work. It may improve the rationale, uncertainty explanation, response subject, and response body derived from a deterministic control record. It cannot change verified facts, risks, actions, financial impact, tenant scope, permissions, or the approval requirement.

The backend owns role checks, organization scope, policy lifecycle, stale-review detection, idempotency, redaction, audit events, and recovery. If case evidence or policy changes after submission, the review becomes stale instead of silently retaining old authority.

Verified outcomes

Reduced median case-resolution workflow time by ~84% (582s to 95s) while completing the full safe workflow in 3/3 test cases, compared with 0/3 through the manual path.

The developer-operated benchmark used three matched synthetic cases. Because the manual runs did not complete the same full safe-workflow boundary, the raw timing difference is descriptive and is not presented as a correctness-controlled speedup.

Three targeted safety tests passed, and every Copilot outcome was re-read from the disposable Neon validation database rather than accepted from interface state alone.

Public evaluation keeps 86 CFPB, Financial Ombudsman Service, and UCI records separate from three synthetic production-engine controls. These records test the evaluation pipeline; they are not presented as complete customer cases or one aggregate product-accuracy score.

Production and engineering evidence

The controlled-pilot readiness gate covered a real, bounded Gmail journey that created an approved persisted draft without automatically sending it, plus PostgreSQL 18.6 and pgvector persistence on a disposable Neon database.

Supporting checks included 73 backend unit and contract checks, 3 PostgreSQL integration checks, 4 provider-fault scenarios, and 35 frontend recovery checks. Warm authenticated primary content was ready in 375 ms against a 2,500 ms gate. That browser timing is a readiness measurement, not an exact Core Web Vitals LCP measurement.

How this was verified

• Developer workflow benchmark
• Operational readiness evidence

Failure handling

Consequential actions are registered before execution and protected by idempotency. A successful provider response produces a receipt that can be traced back to the reviewed snapshot.

If a timeout means the side effect may have occurred, the system records an unknown outcome and blocks blind retry. Recovery uses a read-only status check or a human-confirmed resolution before the workflow can continue. This prevents “retry” from becoming a duplicate refund, credit, or account change.

Current boundary

Historical hosted evidence records the predecessor frontend and backend running in Singapore with Clerk identity and a Neon database, including Specialist submission, Supervisor approval, one controlled action, duplicate blocking, and Auditor read-only inspection. It is not current-deployment proof.

The evidence covers synthetic cases, one developer operator, a disposable Neon database, and one bounded hosted Gmail draft journey. It supports a controlled-pilot readiness claim, not production-user adoption, customer impact, automatic email sending, production accuracy, or general enterprise readiness.