DEV Community: Maya Chen

Our New Proofreader Can't Write a Single Word

Maya Chen — Wed, 07 Oct 2026 00:40:13 +0000

We had an AI that only answers yes or no reread every rule we publish. Here is how that went.

Last week TypeSafe released Jev, an AI model that can't write. You give it some text and a list of questions, and it answers with things like "yes, 0.96" or "option B." It won't summarize the text or explain itself, and an answer usually comes back in about a sixth of a second. TypeSafe calls it a System One model, after the fast, gut-reaction half of Kahneman's two kinds of thinking.

Their launch demos have it playing Doom and racing through Wikipedia links. We had a duller job in mind. Every rule on Court Rules comes with the judge's own words attached, so that a reader can check our summary against the sentence it came from. A model that does nothing except compare a claim to a piece of text is pretty much a proofreader, and we had about 64,000 rules that had never had a second pair of eyes on them all at once.

Twenty minutes and $1.34

Each rule we publish starts with the judge's sentence, quoted word for word. Under that is our plain-English summary, and under that a handful of structured fields (a page limit, say, or a number of days). The quote gets matched against the source document before a rule goes live. The summary and the fields are written by an extraction model, and until now the only way to double-check them was to pay a second large model to reread everything. That is slow and expensive enough that we had only ever done it in samples.

Jev read all of it in twenty minutes, and the bill was $1.34. For each rule we asked it two things: does the summary say what the quote says, and is each structured field something the quote states?

What it caught

About 95 percent of rules came back clean. In the rest, the quote and the citation were fine, and the trouble was a summary or a field that said slightly more than the judge did. One judge wrote that a party "may submit" two courtesy copies of a compendium of authorities, and our summary had turned that into a requirement. Another judge encourages junior attorneys to argue motions, and our structured data had attached a years-of-experience cutoff the judge never gave. A rule about tabbing exhibit binders had picked up page margins from somewhere.

A litigator mostly reads a rule to find out whether something is required or just allowed, so we took these seriously. We went through a sample by hand, agreed with Jev, and fixed the flagged rules the same day.

We also changed the form our extraction model fills in. It used to have required blanks for things like margins and experience cutoffs, and a model handed a required blank will find something to put in it. Those fields are optional now, and an empty one means the judge didn't say.

Where it was bad

Our first multiple-choice question was a flop, and it was our fault. We gave Jev a menu of eleven document types and asked which one a page was, and it decided that nearly every blank template order was an order entered in one particular named case. We blamed the model and switched to separate yes-or-no questions, which worked.

Then Jerry Liu published DocJev, which classifies documents with Jev by defining each category in one sentence about the document's main purpose. Our eleven options had been bare labels with nothing telling them apart. We rewrote the menu that way and ran it on a batch of documents, five of which we had already read by hand. It agreed with our reading on four. The miss was a links page that talks about filing rules without stating any, which a second yes-or-no question now catches. Parallel found that very long label lists still hurt it, so we keep the menus short.

Its confidence scores only mean something at the ends. When it was 95 percent sure a summary contradicted its quote, it was usually right. At 60 percent it was right about one time in four, and once it insisted that "at least 21 days before" and "no later than 21 days before" were in conflict. Another time it pulled the correct number out of a 90-minute time limit and then told us the unit was hours.

And it has no ideas of its own. It will count any category you hand it across every rule we have, for pennies, but we had to bring the categories.

Questions we couldn't afford before

The cheapness changes what you bother to ask. We would never have paid a big model to find out how judges phrase deadlines, but at these prices we just ran the question across the nearly nine thousand rules that have one. More than a third just say "days" and leave you to work out which kind. About one in fourteen say "court days," which skip court holidays and are not the same thing as business days. We are reworking our deadline fields around what that survey found.

We also ran it over about four thousand source documents with a single question: does this page tell a litigant to do something? That took 70 seconds. It turned up several hundred pages we had set aside, most of them the blank template orders judges post for parties to fill in, which do carry requirements if you read them. A second model that had to quote its evidence agreed on 39 of the 40 we pulled at random. Those documents are in the extraction queue.

What it does now

Jev now gets the first say on whether a document we collect contains rules at all. The large model only weighs in when Jev is unsure. It also has the proofreading job for good. Every new rule's summary and values are checked against the judge's sentence before the rule shows up on the page you search, and a rule it can't stand behind gets flagged for us to look at. We will write again once that has been running for a while and we can say how much it catches.

Originally published on Court Rules.

Privacy Enforcement Is Becoming Product Data

Maya Chen — Wed, 30 Sep 2026 18:24:06 +0000

No one should read 1,338 enforcement releases and regulatory records one at a time. The useful work begins when those materials become source-linked records: dates, regulators, violation types, remedies, penalties, and citations that a legal workflow can actually use.

Regulatory enforcement is usually consumed as a stream of press releases. A new FTC settlement, a state attorney general investigation, an HHS breach report, a warning letter, a consent order. Each item matters, but the stream is hard to use. It tells you what happened, then leaves your team to decide whether it affects contracts, product settings, vendor reviews, board reporting, or customer-facing policy.

That is the wrong shape for modern legal work. A legal team does not need another inbox. It needs enforcement data that can move through systems.

1,338 Enforcement records: Source-linked actions, guidance, investigations, settlements, and regulatory updates.
14 Jurisdictions: Federal and state authorities, including FTC, HHS OCR, state AGs, and CPPA.
$50B+ Tracked penalties: Monetary exposure is only one signal. Remedies and warnings often move first.

As of May 23, 2026, the CourtRules.app enforcement tracker contains 1,338 records across 14 jurisdictions. The tracker covers monetary penalties, but the more interesting signal is not the penalty total. It is the combination of violation type, remedy, source language, and regulator behavior.

The top enforcement signals in the dataset

Data breach: 789 records
Health data: 780 records
Security failure: 747 records
Unauthorized data sharing: 221 records
Notice failure: 146 records
Consent failure: 121 records

The recent feed is already changing shape

The most recent privacy and platform-safety records are not just classic data breach settlements. They are about nonconsensual intimate images, AI-enabled devices, sensitive location data, youth social media design, consent flows, and biometric capture. Those categories look less like after-the-fact litigation and more like product governance.

FTC: May 20, 2026

Warning letters to 12 nudify tool providers

The useful field is not a fine amount. It is the remedy clock: covered platforms must remove qualifying nonconsensual intimate images within 48 hours of a valid request.

Official source

TX: May 20, 2026

Investigation into Meta AI glasses

The event clusters biometric data, notice failure, consent failure, unauthorized data sharing, and dark patterns in one record. That is exactly the kind of bundle a privacy team needs to route correctly.

Official source

FTC: May 4, 2026

Kochava sensitive location data settlement

The headline is location data. The workflow signal is stronger: consent assessments, retention schedules, incident reporting, data deletion, and a ban on certain sensitive-data sales.

Official source

CT: May 1, 2026

Youth social media and AI harm legislation

This is not a company settlement. It is still operationally important because it creates future enforcement hooks around minors, addictive algorithms, AI chatbots, reporting, and consent.

Official source

Put those events side by side and a pattern appears. The enforcement system is moving earlier in the product lifecycle. It is not waiting for one giant fine to tell the market what matters. Warning letters, investigations, civil investigative demands, new enforcement authorities, and remedy terms all tell a product and compliance team where regulator attention is headed.

Fine amount is a weak sorting key

A fine is easy to sort. It is also late. By the time a large penalty appears, the market has usually had months or years of warning. In our data, many important records have no penalty at all: warning letters, investigations, guidance, new laws, complaint filings, and consent orders with operational restrictions.

That matters for legal operations. A zero-dollar enforcement record can still trigger contract review if it names a sensitive data category. It can trigger a product review if the remedy involves deletion, affirmative consent, reporting, or a ban. It can trigger a vendor review if the source language names subcontractors, data brokers, or onward sharing.

In other words, the workflow question is not only "how much did they pay?" It is "what conduct did the regulator identify, and what would we have to prove if asked?"

Structured records make the pattern visible

The same enforcement action can be read several ways. A press release is a news item. A consent order is a legal document. A source quote is evidence. A violation type is a routing key. A remedy is a product requirement. A source URL is an audit trail.

Fields that turn news into workflow

jurisdiction tells the system which regulator is moving.
violation_types normalize messy agency language into a usable taxonomy.
remedy_types show what the company has to change, not only what it paid.
primary_source_url preserves the official record for verification.
source_quotes make the extracted claim auditable.

This is why the data model matters. A plain-English summary is useful for a reader, but a workflow needs stable fields. An AI agent cannot reliably answer "show me recent actions involving consent failure and children's data" unless those concepts are normalized. A contract system cannot flag a vendor agreement for review unless it can connect the event to search terms, industries, laws, and remedies.

The next alert is not an email

Most enforcement monitoring still looks like a newsletter. That is fine for awareness, but it is not enough for operational response. The useful version is an event record that can be routed.

A healthcare record with security failure and health data should go to privacy and security. A youth social media record involving dark patterns and children's data should go to product counsel. A data broker record involving sensitive location data should go to vendor management and commercial contracting. A biometric investigation should go to the team that owns device features, notices, and consent.

That is why we are building enforcement data next to court rules. Both domains have the same underlying problem. The source material is public, but it is not workflow-shaped. Lawyers can read it, but systems cannot reliably act on it until it has been normalized, cited, and connected to the decisions teams actually make.

Data notes

The counts above come from the CourtRules.app enforcement tracker as of May 23, 2026. Records are extracted from official government sources and linked back to the source release or document. The tracker includes privacy enforcement, consumer protection records with privacy implications, HHS OCR breach records, state attorney general actions, FTC actions, CPPA activity, guidance, investigations, and new enforcement authorities.

Start with the enforcement tracker, or read the enforcement data docs for the fields exposed through our MCP tools.

Originally published on Court Rules.

Court Deadline Calculator for Business Days, Court Days, and Holidays

Maya Chen — Tue, 29 Sep 2026 16:55:36 +0000

A deadline calculator is only useful if it knows when the court is closed. Court Rules now handles federal and selected state court holiday calendars in the same workflow.

Counting days is the easy part. The hard part is knowing what the rule means by days, which court calendar applies, and whether a holiday moves the answer. That is where most deadline mistakes start.

The Court Rules Deadline Calculator is built for that exact problem. Pick a court, choose a start date, choose a counting method, and get a date that uses that court's holiday schedule.

Pick the counting method before you count

A rule that says 10 business days does not mean the same thing as 10 calendar days. Before you count anything, decide which of these modes the rule is using.

Business days: skip weekends and court holidays
Calendar days: count every day, then check whether the final day needs to move under the governing rule
Court days: use only when the rule or local practice says court days

Federal Rule of Civil Procedure 6 is the starting point for federal civil cases. State courts can use different terminology, different holidays, and different local tools. The calculator keeps those calendars tied to the court you select.

Why the court matters

Court holidays are not just federal holidays. California courts, for example, publish statewide judicial holidays that include dates like Lincoln Day, Farmworkers Day, Native American Day, Thanksgiving, and the day after Thanksgiving. The California Judicial Branch publishes those dates on its court holidays page.

Los Angeles Superior Court also maintains its own judicial holiday schedule and an official court date calculator. For critical filings, use the official court source as the final check.

Example: Los Angeles Superior Court

Start with Friday, November 20, 2026. Add 10 business days in Los Angeles Superior Court. A weekend-only calculator lands on Friday, December 4. A court-aware calculator lands on Tuesday, December 8, because Thanksgiving Day and the day after Thanksgiving are court holidays.

That is the difference between adding weekdays and calculating a court deadline. The calculator shows the skipped holidays, then gives you a calendar export so the result can go straight into Outlook, Apple Calendar, or Google Calendar.

Use the holiday pages with the calculator

The calculator is the fastest path when you already know the date and the rule. The court holiday index is better when you need to inspect a court's full schedule first.

For state courts, start with high-volume calendars like Los Angeles Superior Court holidays, New York Court of Appeals holidays, and Delaware Court of Chancery holidays.

Originally published on Court Rules.

Checking missing dates in a legal metadata CSV with Python

Maya Chen — Mon, 28 Sep 2026 23:54:14 +0000

A small Python audit that separates missing source dates from malformed values, preserves judge-page URLs and reports what a dated metadata snapshot can actually show.

A court-rules index is a list of pages with dates attached, and a date is the field most likely to be empty. The Court Rules Judge Index snapshot for September 28, 2026 has 1,233 rows across 39 courts, and 486 of them carry no date at all. Before quoting any count from a file like this, run a quick audit of the dates.

The snapshot

The CSV has nine columns. The one this post cares about is rules_last_changed, an ISO date such as 2024-09-01, or an empty cell when the judge page shows no date.

column	meaning
judge_name	the judge or commissioner on the page
judge_status	Judge, Senior Judge, Magistrate Judge and similar
court_name	the court the page belongs to
court_slug	the court's short id, for example sdny
court_type	federal or state
rule_topics	the rule topics the page covers, separated by semicolons
rule_count	how many rule records the page lists
rules_last_changed	the date the page displays, or empty
url	the judge page on courtrules.app

The audit

The script uses only the standard library. It never writes today's date into a missing cell, and every line of the report repeats the judge-page URL so a finding can be checked against the page.

#!/usr/bin/env python3
"""Audit a judge index CSV for missing, malformed and present source dates.

Usage: python3 date-audit.py [judges.csv]

Reads the CSV named on the command line (default: sample-judges.csv) and checks
rules_last_changed against ISO YYYY-MM-DD dates. An empty value is missing, an
unparseable value is malformed, everything else is present. Today's date is
never substituted for a missing value, and every report line keeps the row's
judge-page URL.

Standard library only.
"""
import csv
import datetime
import sys

COLUMNS = ("judge_name", "court_slug", "url", "rules_last_changed")


def is_iso_date(value):
    try:
        datetime.date.fromisoformat(value)
        return True
    except ValueError:
        return False


def audit(path):
    missing = []
    malformed = []
    present = []
    with open(path, newline="", encoding="utf-8") as handle:
        reader = csv.DictReader(handle)
        fields = reader.fieldnames or []
        absent = [name for name in COLUMNS if name not in fields]
        if absent:
            print("cannot audit, the input has no " + ", ".join(absent))
            return 2
        for row in reader:
            value = (row.get("rules_last_changed") or "").strip()
            record = (row.get("judge_name", ""), row.get("court_slug", ""), row.get("url", ""), value)
            if value == "":
                missing.append(record)
            elif is_iso_date(value):
                present.append(record)
            else:
                malformed.append(record)
    total = len(missing) + len(malformed) + len(present)
    print("rows read = " + str(total))
    print("present = " + str(len(present)) + ", missing = " + str(len(missing)) + ", malformed = " + str(len(malformed)))
    print("")
    for label, records in (("missing date", missing), ("malformed date", malformed), ("present date", present)):
        print(label + " (" + str(len(records)) + ")")
        for name, court, url, value in records:
            shown = value if value else "(empty)"
            print("  " + court + " | " + name + " | " + shown + " | " + url)
        print("")
    return 1 if missing or malformed else 0


if __name__ == "__main__":
    target = sys.argv[1] if len(sys.argv) > 1 else "sample-judges.csv"
    sys.exit(audit(target))

Run it

python3 date-audit.py judges.csv

Against the real snapshot the summary is one line, and the per-row blocks list every missing and malformed value.

rows read = 6
present = 3, missing = 1, malformed = 2

missing date (1)
  ex-district | Example Judge Missing Date | (empty) | https://example.invalid/courts/ex-district/example-judge-missing-date

malformed date (2)
  ex-district | Example Judge Month Name | March 2024 | https://example.invalid/courts/ex-district/example-judge-month-name
  ex-district | Example Judge Impossible Date | 2024-02-30 | https://example.invalid/courts/ex-district/example-judge-impossible-date

present date (3)
  ex-district | Example Judge, With Comma | 2024-09-01 | https://example.invalid/courts/ex-district/example-judge-with-comma
  ex-district | Example Judge Padded Date | 2024-09-01 | https://example.invalid/courts/ex-district/example-judge-padded-date
  ex-district | Example Judge Old Date | 2019-02-01 | https://example.invalid/courts/ex-district/example-judge-old-date

The output above comes from a synthetic fixture beside the script. It carries the cases that matter. A quoted name with a comma parses as one field. A padded value strips to a clean date. March 2024 and 2024-02-30 both fail the ISO check even though a human reader might accept one of them. The real file, by contrast, reports 747 present dates and 486 missing ones, and no malformed values.

What the audit cannot show

A missing date stays unknown. The script leaves the cell empty and never guesses.
A present date describes what the page displayed when the snapshot was built. Legal deadlines come from the court's current rules.
The count measures rows in one file. It says nothing about whether a court requirement applies to a case.
The audit checks the file only. The court documents behind the pages need a separate source check.

Source and license

The snapshot is published at Alison J. Nathan's source page and each row links its page. Nathan's entry traces back to the court's own criminal rules PDF, which is the kind of document the pages summarize. CC BY 4.0 covers judges.csv, judges.json and the dataset README only. Credit Court Rules and keep every row's source URL.

The script is short enough to adapt: point it at a newer snapshot, or swap the column name for any other dated field, and it reports the same three buckets.

How We Built a Federal Court Rules Database

Maya Chen — Fri, 08 May 2026 20:04:28 +0000

Parsing 94 district courts worth of PDFs. It went about as well as you'd expect.

We started with a simple problem. My co-founder is a litigator. I am an engineer. He was spending hours every week digging through PDFs on federal court websites to find judge-specific rules, local filing procedures, and deadline information. The PDFs were inconsistently formatted. Searchable text sat next to scanned images from 1995, some updated quarterly, some untouched for five years.

He asked me if I could build something to aggregate it all. I said sure. How hard could it be?

Famous last words.

The scope problem

There are 94 U.S. federal district courts. Each has local rules. Many of those local rules span hundreds of pages. Then there are the individual judge practices, chamber-specific documents that live on each judge's personal page on the court website. Not every judge publishes them, and courts organize them differently; some bury the files under four layers of navigation.

Our first attempt at scope was naive. We thought we would scrape the rules, parse the PDFs, and build a searchable index. We did not realize that "scrape the rules" meant writing 94 different scrapers, each handling a different CMS, different URL structure, different PDF format, and different update cadence.

The Southern District of New York alone has over two dozen active district judges. Each has an individual practices PDF. Some update them every few months. The URL changes when they update. The filename changes. Sometimes the PDF is replaced inline with no versioning. Tracking changes across that surface area is a full-time job.

PDF parsing is the real enemy

PDF parsing is a solved problem in computer science the same way sailing is a solved problem. The theory is straightforward. The practice involves a lot of cursing and unexpected water.

We started with Python and PyPDF2. It worked on maybe 30 percent of documents. The rest were image-based PDFs with no text layer. For those we added OCR using Tesseract. That got us to about 60 percent. But OCR on legal documents is messy. Footnotes confuse it. Tables break it. Multi-column layouts destroy it.

Then we found a whole category of PDFs that were text-based but had broken encoding. The text extracted as gibberish while the visual render was fine, because the underlying text was corrupted. These were usually documents that had been printed, scanned, OCR'd, and re-saved multiple times over a decade. Each step introduced more noise.

Our current pipeline uses a hybrid approach. Text-based PDFs go through pdfplumber, which handles tables and layout better than PyPDF2. Image-based PDFs go through Tesseract with layout analysis. When the encoding is broken, we fall back to full-page OCR of the rendered image, slower but more reliable than trusting the corrupt text layer.

Even with all of that, we still manually review a percentage of documents. Some things are just faster for a human to verify.

Normalizing judge data

Court websites do not have APIs. They have HTML. Sometimes very old HTML.

We built a judge directory covering every active federal district judge. For each judge, we track name, court, appointment date, chamber location, and links to individual practices documents. This sounds simple. It is not.

Some courts list judges on a single page with clean semantic HTML. Others use a table layout from 2003. Others require clicking through to a bio page, then finding a "chambers" tab, then downloading a PDF from a link that has no predictable structure.

We ended up with a per-court configuration system. Each court gets a scraper definition file that specifies:

The URL pattern for the judges list page
The CSS selector or XPath to extract judge names and profile links
The pattern for individual practices document URLs
The expected update frequency
A human reviewer assignment

This lets us add new courts without rewriting the entire system. It also means we have 94 configuration files, each slightly different, each requiring maintenance when the court redesigns its website.

Which happens more often than you would think.

The deadline calculator

The most technically interesting part of the project is the deadline calculator. Federal court deadlines depend on:

The triggering event (service, order entry, filing)
The rule that governs the period (Rule 12, Rule 56, Rule 59, etc.)
The type of days (calendar days, business days, court days)
Federal holidays
Local court closures
Whether the last day falls on a weekend or holiday

We built a rules engine that encodes the Federal Rules of Civil Procedure and the Federal Rules of Appellate Procedure. The engine takes a trigger date, a rule reference, and a court identifier. It returns the calculated deadline with an explanation of each step.

The tricky part is local variations. Districts modify the default federal periods through local rules, individual judges add scheduling requirements through standing orders, and courts close for local events that are not federal holidays. We maintain a per-court overrides file that layers local rules on top of the federal defaults.

For holidays, we pull the OPM federal holiday calendar. But we also track observed holidays separately from calendar holidays. When New Year's Day falls on a Saturday, the observed holiday is Friday. When it falls on Sunday, it is Monday. The calculator handles this correctly, which sounds trivial until you realize how many generic date libraries get it wrong.

Inauguration Day is its own special case. It is a federal holiday only in the Washington D.C. area. Our calculator knows that and applies it only to D.D.C. and D.C. Circuit deadlines. Everywhere else, January 20 is a normal day.

Architecture

The stack is intentionally boring. We use Node.js for the API, PostgreSQL for structured data, and Elasticsearch for full-text search across rules documents. The frontend is React. Nothing exotic.

Documents are stored in S3. Parsed text is indexed in Elasticsearch with metadata tags for court, judge, document type, and effective date. We version every document. When a judge updates their individual practices, we keep the old version and mark the new one as current. This lets us show change history and answer questions like "what did Judge Liman's practices say in 2023?"

The scrapers run on a schedule. Most courts are checked weekly. High-update courts, like SDNY, are checked daily. The scraper jobs are idempotent. If nothing changed, nothing changes. If a PDF was updated, it gets downloaded, parsed, indexed, and queued for human review if the diff is significant.

We use GitHub Actions for CI and deployment. The whole thing runs on AWS. Total monthly infrastructure cost is under $200. The biggest expense is the human review time, not the servers.

What we got wrong

Our first version tried to auto-detect document type from PDF content. That failed badly. A document titled "Individual Practices" might actually be a standing order. A "Local Rules" PDF might contain only criminal rules. We now require manual classification for new document types. It is slower. It is also correct.

We also underestimated the maintenance burden. Court websites change. Judges retire. New judges get appointed. PDFs get reorganized. We built a system that is 80 percent automated and 20 percent human curation. I thought we could get to 95 percent. I was wrong. The long tail of edge cases is endless.

Another mistake: we initially stored parsed text as plain strings. When we added full-text search, we realized we had destroyed paragraph structure, footnote references, and table data. We had to re-parse every document with layout preservation. That took three weekends.

Current numbers

The database covers all 94 federal district courts. We track approximately 680 active district judges. We have parsed and indexed over 4,200 local rules and individual practices documents. The deadline calculator handles 40+ federal rule references with district-specific overrides.

Traffic is modest but growing. About 12,000 unique visitors per month, mostly litigators, paralegals, and law students. The calculator is the most-used feature. The judge directory gets heavy use from associates who just got case assignments and need to know their judge's quirks.

We have had zero venture capital. No paid marketing. Growth is entirely organic through legal forums, Reddit, and word of mouth in litigation departments.

Why we keep doing it

The honest answer is that we use it ourselves. My co-founder relies on it for his practice. I rely on it as a sanity check when he asks me whether a deadline calculation looks right. Building tools you actually use changes your priorities. You do not add features because they sound impressive. You add them because you needed them yesterday.

The federal court system is public, the rules are public, and the judge practices are public. But they are scattered across 94 websites, in formats that resist aggregation. We are just trying to put them in one place, in a form that is actually usable.

It is not the kind of project that gets written up in TechCrunch. It will not scale to a billion users. But it solves a real problem for a specific group of people. And for a side project, that is enough.

If you are interested in the technical details or want to contribute, the project is at courtrules.app. We are not open source yet, though we have talked about it. The dataset might be useful to researchers, journalists, or other developers working in the legal space.