DEV Community

Multigrid
Multigrid

Posted on • Originally published at multigrid.ai

Extracting Case Numbers and Docket Entries From a Court Filing

Every court filing prints its case number in at least two places, and the one at the top of page one — inside the caption — is the one that is hardest to read reliably. The other one is a machine-generated stamp on every page.

The caption is a table without rules

The caption block is a two-column layout with no visible grid. On the left sit the parties; on the right sit the case number, the judge and sometimes a jury demand. The columns are separated by a vertical line of closing parentheses, or by a single drawn rule, or by nothing but whitespace. It looks like this:

            UNITED STATES DISTRICT COURT
         FOR THE DISTRICT OF EXAMPLE

NORTHWIND TRADING CO.,           )
                                 )
          Plaintiff,              )   Case No. 1:24-cv-01234-JKL-MNO
                                 )
     v.                          )   Judge Jamie K. Lee
                                 )   Magistrate Judge M. N. Ortiz
HARBORLINE SYSTEMS, INC.,        )
                                 )   JURY TRIAL DEMANDED
          Defendant.             )
_________________________________)
Enter fullscreen mode Exit fullscreen mode

Extracted as lines of text in the order they appear in the file, that becomes “NORTHWIND TRADING CO., ) Plaintiff, ) Case No. 1:24-cv-01234-JKL-MNO” — the party name and the case number welded into one string, with the party’s role attached to the wrong side. Ask a model for “the plaintiff” from that text and you may well get the case number appended to the name.

This is a coordinate problem, not a prompting problem. The fix is to cluster text by horizontal position before reading it: everything left of the parenthesis column is one block, everything right is another, and each is read top to bottom. The same technique that fixes two-column academic PDFs fixes captions, and it is covered in general in PDF parsing and specifically in two-column reading order. What is specific here is the separator: the column boundary is a run of ) characters, which is a reliable and easily detected anchor when it is present, and absent entirely on filings that use a drawn rule or plain indentation.

The header stamp is the better source

Federal documents filed through CM/ECF, the electronic case filing system operated by the federal judiciary, carry a stamp applied at the top of every page when the document is filed:

Case 1:24-cv-01234-JKL-MNO   Document 47   Filed 03/12/25   Page 6 of 21   PageID #: 812
Enter fullscreen mode Exit fullscreen mode

This line is worth more than the caption for four reasons. It is machine-generated, so it is in a consistent typeface at a consistent position rather than in whatever the drafting attorney’s template produced. It carries the docket entry number for the document, which the caption does not. It carries the page position and total, so a truncated or mis-split PDF is detectable arithmetically — if you have a page 6 of 21 and no page 7, you are missing pages. And because it repeats on every page, a disagreement between pages tells you that two documents have been concatenated into one file, which happens constantly in production sets.

Read the header first, take the case number from it, and use the caption as corroboration rather than as the primary. Where they disagree, the header is the filing system’s own record and the caption is what somebody typed. The Administrative Office of the U.S. Courts documents the system at uscourts.gov, and the public access interface at PACER is where the canonical docket lives.

The header stamp is present only on documents that passed through electronic filing. Scanned older filings, state court documents, exhibits produced in discovery and courtesy copies have no such stamp, so the caption path has to exist as a fallback rather than being skipped.

What a federal case number encodes

A federal district court case number is not opaque. Reading 1:24-cv-01234-JKL-MNO left to right: the leading digit is the office or division within the district, so the same district can have a 1: and a 3: running independent sequences; 24 is the two-digit year the case was filed; cv is the case type; the five-digit block is the sequence number within that office and year; and the trailing letter groups are the initials of the assigned district judge and, where one is assigned, the magistrate judge.

The case type codes are the part most often needed and most often guessed at. cv is civil and cr criminal; md appears on multidistrict litigation, mc or mj on miscellaneous and magistrate matters, and bankruptcy courts use their own including bk for the main case and ap for an adversary proceeding. Districts do vary, so treat the code as an extracted token to be validated against a list you maintain, not as a closed enumeration you assert.

The judge initials are the volatile part. Cases are reassigned, and when they are, the initials change while the rest of the number stays the same. That means the full string is not a stable key: the same case appears as 1:24-cv-01234-JKL in early filings and 1:24-cv-01234-PQR after reassignment. Store the full string as written and a stripped form — office, year, type, sequence — as the join key.

State numbering and why you cannot generalise

State court numbering has no common grammar at all. Formats include a year and sequence with a case-type letter, a county code prefix, a division code, and in several states a number that encodes the filing court’s branch. Some jurisdictions renumber on appeal, so the same dispute carries two live numbers and filings in the appellate court recite both.

The only safe design is to store the number as a string exactly as printed, alongside the court name and the state, and to apply per-court parsing rules as configuration that a person has verified against that court’s own published guidance. A regular expression inferred from a sample of documents will match the sample and fail on the neighbouring county. Where you cannot parse, an unparsed string plus a court identifier is still a usable record; an incorrectly parsed one is not.

Docket entries, attachments and consolidation

A docket sheet is a numbered, append-only list. Each entry has a number, a filing date, entering text and often a set of attachments numbered as children: entry 47 with exhibits at 47-1, 47-2 and so on. Preserve that hierarchy. A flat list of documents loses the fact that an exhibit is part of a filing, and the parent’s entry text is usually the only description the exhibit has.

Two structural cases break single-value case-number fields. Related cases are frequently consolidated, and filings then bear a lead case number plus one or more member numbers, sometimes with “Consolidated with No. ...” printed under the caption. And a document filed in a case on appeal may carry both the district court number and the appellate number. Model the field as an array of case references with a role — lead, member, appellate — which is the multi-entity schema shape rather than a scalar, and record which one the header stamp used, because that is the one the filing system indexed the document under.

A docket-scale run is where per-request accounting stops being optional: tens of thousands of pages, an image token cost that varies with page resolution, and a mix of clean electronic PDFs and scanned exhibits that need a different, more expensive path. Multigrid is an LLM gateway, so the per-request cost of each page lands in one log across whichever providers the run used, and a spend cap stops a mis-configured resolution setting before it becomes a month of budget.

Once the case is identified, the next two questions on the same document are what kind of filing it is and what dates it creates — see extracting motion type and filing party and extracting hearing dates and deadlines.

Related

Top comments (0)