Case Management Automation — California Law Firm

The problem

Case status at the firm was maintained by hand. Case coordinators watched for documents added to case files and relied on information shared between team members to know whether a case had advanced — then tracked the corresponding status manually. The firm had no systematic view of movement through its litigation pipeline.

The system

The system is a plaintiff-side litigation case-tracking system — it turns unstructured legal documents into structured facts and deterministic case-state updates. Six months from start to first production use, and the firm changed nothing about how it operates: documents land in the same cloud drive they always did.

From there the pipeline runs end to end. Webhook synchronization picks up new files, OCR reads them, an LLM extracts and classifies the facts inside, and a deterministic rule engine applies those facts to an append-only record and a derived case state.

The architecture rests on one principle: unstructured documents, probabilistic fact extraction, deterministic state transitions. The LLM does not decide case state — it extracts facts, held behind confidence and document look-alike gates. Deterministic code owns the state transitions: case stages move forward only, the current stage is derived as a pure fold over the accumulated facts, and applying the same fact twice changes nothing. Anything the system cannot resolve becomes an explicit, typed anomaly instead of a silent guess. That separation is why the system can be trusted with operational state.

Under the hood: Microsoft Graph feeds documents in, Azure Document Intelligence handles OCR, Azure OpenAI runs extraction, and PostgreSQL holds the record — and serves as the processing queue — behind a Drizzle, Hono, and React stack.

• Microsoft Graph

  Document intake

• Azure Document Intelligence

  OCR

• Azure OpenAI

  Fact extraction

• PostgreSQL

  Record and queue

• Drizzle, Hono, React

  Application layer

The pilot

Before the system took over live work, it ran against 30 live cases — 25 selected before the pilot, 5 more during a call with the firm. The cases were chosen deliberately across different points of the litigation pipeline, not as a random sample, to exercise the system across multiple stages.

The firm’s subject-matter expert documented each case’s known stage at the start of the evaluation. The metric was stage-tracking accuracy — whether the system accurately recognized movement as new documentation entered each case file.

It matched the documented baseline on 26 of the 30 cases. On 4 it tracked ahead — cases that genuinely progressed during the pilot, evidenced by new documents, never an incorrect skip of a stage. It was behind on none. iQonAi performed the initial evaluation, and the firm’s internal stakeholders reviewed and confirmed the results.

Measured results

The system is in production on the firm’s live caseload. All new case intake now flows through it — an expansion from the original 30-case pilot scope — and in its first three months it carried 200+ cases, all live intake against active production work rather than a curated historical dataset.

What the firm gains is systematic visibility into movement through the litigation pipeline — where each case stands, and when new documentation shows it has moved.

1. Six months

   Start to first production use

2. 30 cases

   Live pilot against the firm’s baseline

3. All intake

   Expanded beyond pilot scope

4. 200+ cases

   First three months in production