The record as data
Bulk access is a promise, not a feature. The raw index — every docket, filing, decision, date and document Docket Yard holds about the Board’s proceedings, with its provenance — is downloadable as one file, and every docket, filing and decision has a JSON twin at its own address. That index — the compilation, and the fields that are the Board’s own work: numbers, captions, dates, types, summaries — is dedicated to the public domain (CC0 1.0): use it for anything, no permission or attribution needed. The words of filings and environmental comments are in the public record because their authors filed them, and are reproduced here as the Board publishes them; they are not Docket Yard’s to dedicate. The Board’s own file remains the authority for every record.
Machines are welcome, and so is training. The raw index is dedicated to the public domain, so training on it needs no permission and none is withheld: robots.txt names the AI crawlers explicitly rather than leaving them to guess at silence. There is a read-only MCP server at /mcp and a plain-language /llms.txt. One thing is asked rather than required: if you answer questions from this record, carry what a reader would have seen — coverage is not uniform, every date and caption is quoted rather than computed, and nothing here says what any party argued. An answer that drops those is worse than no source.
Held back for now: the party module — who filed for whom, resolved to entities with their other names and successions — the citator (citation edges and their readings), and the machine-read text of the record's documents, shown page by page beside each record. The party module (entity resolution, aliases, successions), the citator (citation edges, their readings, resolutions and judgements) and the machine-read text of the record's documents (every reading, its payload and its index) are derived work whose licence awaits review; they are withheld until then, not dedicated by default. It stays readable on every sheet, and an assistant may read the page text through the MCP server to answer a user's question — not to collect it or train on it. What an assistant makes of the text is outside this site's control; the document itself is the thing to review.
Bulk snapshot
One SQLite file, cut nightly. It is the live store minus every table that could name a reader — alert_event, alert, subscription_token, subscription, email_suppression, reviewer_token, reviewer — which never leave the machine, ciphertext included; the copy is built where it is not served and checked against an allowlist of public tables before it is offered. Numbers below are measured from the file itself.
| File | Size | SHA-256 |
|---|---|---|
| docketyard-latest.sqlite.gz built 2026-10-10T04:19:34+00:00 | 96.2 MB | 44e8d5f6648a42c0… |
| docketyard-2026-10-01.sqlite.gz archive | 94.9 MB | ecb88dc025a2d171… |
| docketyard-2026-09-01.sqlite.gz archive | 53.3 MB | 554c6883f57d52e7… |
| docketyard-2026-08-26.sqlite.gz archive | 6.8 MB | a65b604b07509784… |
| schema.sql the snapshot’s own tables, as created (schema version 34) | ||
| index.json this manifest, with full hashes | ||
| LICENSE.txt CC0-1.0 |
Holds 32,640 dockets, 53,704 filings, 19,880 decisions and 146,246 ledger events; withheld tables: page_fts, filing_party_link, filing_party_span, party_relationship, relationship_vocab, party_name, party, review_action, review_decision_vocab, review_queue_vocab, review_target_vocab, citation_reading_retirement, citation_treatment, citation_judgement, citation_resolution, citation_reading, text_ref_vocab, retirement_reason_vocab, decision_decided_date, document_text, page_route, route_class_vocab, text_payload, citation, citation_key, extraction_run, assertion_method, class_measurement, class_vocab, measured_target_vocab, judgement_value_vocab, judgement_vocab, treatment_vocab, outcome_vocab, date_kind_vocab, reading_vocab, target_kind_vocab, decision_work, document_text_display, citation_reading_residue. The first snapshot of each month is kept as a dated archive. The Board’s PDF files themselves (104,756 held, by content hash) are not in the snapshot; each record lists the Board’s own URL for its files.
Open it with sqlite3 docketyard-latest.sqlite after gunzip. The event ledger (event, capture) is the source of truth; filing, decision_record and docket are projections of it. Every derived row names the capture it came from.
JSON
Append .json to a docket, sub-docket, filing or decision address and the same record comes back as data — since shape 2, each address answers for what its own page covers, and a sub-docket names the series it sits under — with the same permanent address and a Cache-Control of thirty minutes. Feeds are at /feed; the licence, what is stable and what is asked of a client are on the API page. There are no keys, no accounts and no rate limits; please be reasonable, identify your client in its User-Agent, and prefer the snapshot for anything that walks the whole record.
| Address | Returns |
|---|---|
| /d/FD-36873.json | That address’s sheet: caption, sub-dockets, and — where the number holds records of its own — every filing and decision with the Board’s dates as printed, attachments with content hashes. A series number holds none, so it answers with its index. (The Parties block is held with the enriched layer.) |
| /filing/<id>.json | One filing, with its docket. |
| /decision/<id>.json | One decision, with its docket. |
| /health | The store’s freshness, as the heartbeat reads it. |
Every response carries source, licence and generated_at. Field names follow the snapshot’s schema; a field the Board left blank is null, never guessed. Every response carries shape_version; it is raised, and announced here, when a field changes name or meaning. Shape 3 (2026-09-16): a sheet's last_checked is now when the watch last asked the Board about every record table, and the new last_new_entry is the latest capture that brought the docket an entry — what last_checked meant until shape 3.