Exhibit builder

Exhibit packages are foundational to litigation. Every document, every page, every sort order reflects case strategy and firm convention. A missing record or misordered section can undermine a demand letter that took weeks to prepare. I designed the system that lets legal professionals assemble court-ready exhibit packages from thousands of case documents, starting from manual operations and ending in conversational automation.

Supio is an AI-powered legal platform. Attorneys and paralegals use it to build exhibit packages that accompany demand letters, deposition outlines, and other legal documents. These packages pull from massive case files: medical records, police reports, billing statements, and correspondence, often spanning hundreds of PDFs and thousands of pages. I joined as lead product designer on the drafting intelligence team.

I designed the exhibit builder end-to-end: preference-driven assembly powered by timeline events, page-level document control, reusable templates with dynamic fields, and document linking that closes the loop with Agentic Drafting. The system evolved from an internal operations workflow to a self-service builder to a conversational agentic experience.

Visuals shown here are simplified representations of production systems. Additional detail can be discussed in interviews.

The core problem was not assembling documents into packages.

It was encoding firm-specific assembly preferences, sort orders, section structures, and page-level selections, into a system structured enough to automate the majority of assembly but flexible enough that legal professionals maintain full control over the result. Every firm builds exhibit packages differently. The system had to absorb that diversity without becoming rigid or overwhelming.

Exhibit assembly operated under constraints that compounded at scale. A single personal injury case might contain hundreds of PDFs spanning thousands of pages across medical records, billing statements, police reports, and correspondence. The right pages had to be identified, grouped into sections, sorted by firm convention, and linked to the demand letter they supported.

The platform's initial approach relied on an internal operations team to assemble packages on behalf of users. This worked but was slow, costly, and positioned the company away from where it needed to go: AI-powered self-service. The system needed to give users the same quality that operators delivered, without the overhead.

• Cases contain thousands of pages across hundreds of PDFs; page-level precision is required

• Sort order varies by firm: chronological by date of service, grouped by provider, by facility

• Section structures differ across case types and firm conventions

• Exhibit packages must link to demand letters as a complete deliverable

• Users need to verify individual pages, not just whole documents

The builder translates case data into structured exhibit packages that users can refine. The design challenge was replacing a manual operations workflow without losing the assembly quality that users depended on.

The foundation was timeline events. Supio's medical chronology extracts structured data from case documents: dates of service, providers, facilities, diagnoses, and their source pages. Instead of asking users to browse entire case files to find the right documents, the builder uses timeline events to pre-populate exhibit sections with the relevant documents and pages. This shifted the starting point from "find everything" to "verify and refine what the system found."

Page-level control was table stakes. A 200-page medical record might contain only 4 relevant pages for a specific exhibit section. The system defaults to timeline event pages, but users can zoom into any document, select or deselect individual pages, and add page ranges in bulk. Without this precision, the builder would produce packages that paralegals had to manually reconstruct anyway.

The builder interface gives users a split view: case documents on the left with filtering by timeline events, facilities, providers, and document types; the exhibit package on the right with draggable sections and multi-select. Users control the assembly at whatever level of granularity their firm requires.

A single template definition generates multiple exhibit sections from case data. Dynamic fields like {facility} resolve to each provider found in the case, producing a structured package sorted by firm preference.

The template system lets firms encode their assembly conventions into reusable structures. The design challenge was making preference configuration powerful enough for the diversity of firm conventions without making it complex to set up.

Templates use dynamic fields. A section named "{facility name} Medical Records" automatically generates one section per facility found in the case data, each pre-populated with the matching documents sorted by first date of service. Firms define their section order, sort criteria, and document type filters once; the template applies them across every new case.

This is what makes the builder feel firm-specific rather than generic. Without templates, every exhibit package starts from scratch. A paralegal rebuilding the same section structure for the twentieth time will look for a different tool. With templates, the builder produces a package that matches the firm's conventions on the first run, and users refine from there.

Exhibit packages exist to support documents. A demand letter without its exhibits is incomplete. I designed the linking system so that exhibit packages attach to their parent document, and on completion, the package inserts at the bottom of the demand letter as a single deliverable.

With the agentic layer, this connection becomes conversational. Users drafting a demand letter through chat can request "include exhibit package" in the same flow. The system matches a template from the knowledge base based on case type and firm preference, assembles the package, and presents it for review alongside the demand letter. Users can make changes to exhibit sections through chat commands, the same way they edit the demand letter itself. This closes the full loop: draft, assemble, review, and export as one experience.

I led product design end-to-end: research, prototyping, and iteration from the initial operations workflow through the self-service builder to the agentic integration. I prototyped in Claude Code, delivered high-fidelity designs in Figma, then implemented frontend directly for seamless delivery. For the agentic exhibit builder, I created agent skills that guided the process using existing builder functionality. I coordinated closely with PMs, an engineering manager, and a lead developer on the drafting intelligence team to ship each phase.

Exhibit package adoption increased 16% after the self-service builder launched. Human-in-the-loop assembly dropped 14%, shifting that work from operations to users who preferred the control. The builder became the foundation for agentic exhibit generation, closing the loop between document drafting and exhibit assembly in a single conversational experience.