Unnamed Law Firm

Litigation finance firms make high-stakes funding decisions on U.S. federal court cases, where speed and accuracy directly affect investment returns. This firm built an AI pipeline to identify relevant cases, download court PDFs, and use large language models to extract key facts — targeting roughly 400 cases per day. The initial implementation collapsed under real-world conditions: browser automation moved faster than court websites could respond, PDFs were not immediately available after case creation, and Azure Service Bus dead-letter queues accumulated failures that were re-queued without resolution. Error rates of 90–95% across download, processing, and interpretation stages rendered the platform entirely unusable by downstream analysis and funding teams.

SPR re-architected the platform end-to-end, replacing fragile automation with deliberate court-site navigation that waited for full page loads before proceeding — mimicking careful human interaction rather than millisecond-speed clicking. A critical design change introduced explicit 'PDF not yet available' lifecycle states, recognizing that court documents can take days to appear after case creation. Case lifecycle logic was added to filter self-represented parties, duplicates, and closed cases before they entered the main pipeline. On the AI side, the Azure OpenAI LLM integration — using Large Language Models for extraction and interpretation — was hardened to produce structured outcomes when source PDF sections were missing, rather than crashing into the dead-letter queue. The PostgreSQL schema was redesigned from a denormalized structure to a properly normalized one, and Azure Service Bus and Azure Functions orchestration was rebuilt to address root causes rather than blindly requeue failures. The client's engineering team was coached throughout, inheriting a stable foundation for independent feature development.

The platform's error rate dropped from 90–95% to 10–15%, with residual failures primarily attributable to source PDFs missing required sections — a data quality issue outside the system's control. With approximately 400 federal cases arriving daily, the rebuilt pipeline moved from near-total failure to production viability:

• Error rate: 90–95% → 10–15% across download, processing, and interpretation stages
• Daily volume: ~400 U.S. federal cases processed per day in production
• Deployment status: Successfully live, adopted by content analysis and review teams for daily funding workflows

Beyond the metrics, the client's engineering team received a stable, extensible codebase, enabling independent feature development without ongoing vendor support.

• Treat 'document not yet available' as a tracked lifecycle state, not a system error — external systems like court databases have their own posting schedules that AI pipelines must accommodate.
• Dead-letter queue accumulation signals unresolved root causes; re-queuing failed messages without fixing the underlying issue compounds failures at scale.
• Browser automation against unpredictable court websites requires deliberate pacing — waiting for full page loads prevents the bulk of download errors.
• When a pipeline's foundation is structurally unsound, incremental patching is less effective than a full re-architecture.
• LLM extraction workflows must handle missing document sections with structured null outcomes rather than unhandled exceptions.