Display Kept in this browser only
Docket Yard

How the record is kept

This page is the accuracy contract: what Docket Yard takes from the Board unchanged, the few things it derives, and the rules every derived thing is produced under. It is written from the same source the code is built from, and it changes when the code does.

Taken from the Board unchanged

  • Docket numbers, captions, filing types, filers as filed, deciding bodies, decision summaries, and dates. Each is the cell the Board printed, kept verbatim in the store. Captions and summaries appear in the Board's own capitals.
  • Dates are quoted, never computed. A sheet shows the date the Board printed, in a different format (25 Aug 2026 for 8/25/2026); the printed form is kept alongside it. No date is inferred from context, a document, or another date.
  • Files. Every attachment the Board lists is fetched once and kept by the SHA-256 of its bytes. If the Board later serves different bytes at the same address, the record keeps both and notes the replacement; subscribers are told.
  • Every response from the Board's search is kept raw, so the record can be rebuilt from what was actually received, and so a dispute about what the Board printed on a given day can be settled.

Derived, and how

  • The short type label in a sheet's second column (Motion, Reply, Notice, Comments, Decision…) is a fixed mapping from the Board's filing-type string. It looks only at that string — never at who filed, never at the document. A type the mapping does not know shows its first word.
  • Folding a docket family. A record the Board enters in both a docket and one of its sub-dockets is shown once, on the copy nearest the parent, with a note of where else it was entered. The sub-docket relationship comes from the docket number itself (FD 36873 (Sub-No. 1) belongs to FD 36873).
  • A repeated filer. When the Board's "filed for" cell is nothing but one party's name repeated, the sheet shows the name once; a cell that repeats a name after other names is shown as printed. The cell itself is untouched and appears in full on the entry's own page.
  • Order within a day. Entries sharing a date are shown decisions first, then by the Board's record id, descending. That is a stable order for reading, not a claim about the order things happened.
  • Parties on record. The Board's "Filed For" cell is cut into names by fixed rules (a comma before a corporate suffix is part of a name; a comma or "and" between two whole names is a list; "on behalf of" names a relationship, not a second filer), and each name is matched to a party on record only when its normalised form matches exactly. A cell the rules cannot cut safely is left whole and never becomes a party; a name that could belong to two parties is linked to neither. Two spellings become one party only by an explicit judgement — a hand-entered alias, or a later method — that carries its own provenance and can be withdrawn; no earlier judgement is ever rewritten. Each party has a permanent page at /p/<id>: the number is the record's own id, never reused or renumbered; when two records are held to be one entity, the folded id redirects to the other, permanently, and the page shows the join and its source. A party page is never a claim about what a party argued.
  • Document text. What a machine read from inside a file, shown page by page at each record's text address and labelled with who read it. An environmental comment's attached file is read and shown the same way, at a text address beside the comment's own page. A file with a text layer is read once by the publisher's own text layer (the tool and its version are named on the page); a scanned file is read by an OCR engine chosen per page by a layout router, and the page names the engine, its version, the render and the class the page was routed as. Where a second engine has read the page, the page shows the distance between the two readings, with the rule and version that computed it — never a threshold or a confidence word. Nothing is derived from the text: no date, party, citation or position is asserted from it. It is searched, and a page found that way is shown with who read it, the band's operand or its absence, and the scan (see the search entry below). Text pages are marked not to be indexed by search engines, and email addresses and telephone numbers are omitted from the text shown and indexed, a marker left where each stood, by a pattern rule that applies to everyone alike; postal addresses are not omitted, because no rule finds them reliably. The reading as stored and the Board's file are unchanged. Accuracy, measured on 90 scanned pages checked against a transcription (the benchmark): on clean typescript the routed engine misreads about 2.6% of characters; on degraded copies, fax and skew, about 12.7%; on maps and exhibits it finds under half the labels but invents no text; tables are not yet read, and a scanned page with no text layer that the router found a table on is marked as containing a table we have not read, and is not counted as read. Two caveats travel with those figures: the transcription was checked at reading speed, so they rank engines and tiers rather than state an absolute accuracy, and nothing has yet been measured on the pages this record reads at scale. The text layer's own accuracy is not measured; it is the publisher's.
  • Alerts are built only from the record's own ledger of new entries, only for entries observed after a subscription was confirmed, and only from the watch — never from history being back-filled. See the delivery promise on the coverage page.

Never inferred

  • A party's position. Nothing here says what anyone argued or supports. If that is ever derived, it will come from the document's own words, carry the method and version that produced it and a link to the passage, and a procedural filing will take no position regardless of who filed it.
  • Significance. Entries are not ranked or weighted.
  • Outcomes and deadlines. Not computed from anything.

Provenance

Every entry points at the capture it was observed in, and every capture at the raw response. Where a derived claim is ever published, it carries the source document, the location in it, the method and its version, when it was produced, and a confidence — and a later method does not overwrite an earlier claim; it supersedes it, and the earlier one stays on record.

Registers

A register is one page over every entry of a type the Board itself printed — decisions typed Notice Of Court Action, filings whose type names a protective order — grouped by docket, newest first. It reads the Board's type string and nothing else: not the document, not the outcome. A case that reached court without a notice of that type, or an order granted without a motion so typed, is not on the register, and the page says so. A register is rebuilt from the record as it moves; it is never edited by hand.

Documents

Every file the Board serves is fetched, hashed and kept; the hash is the file's identity. A file the Board's host refuses — it answers that the file is not there, or will not be served — is recorded as refused and asked for again a week later. A PDF or image is shown on its record's own page, and the bytes of every file have a permanent address, /document/<sha256>.pdf (or .jpg, .zip, .xlsx, .docx — the suffix says what the bytes are), which answers with exactly the bytes that hash to that name, forever. A file the Board replaces is a new hash with the old one chained to it; the Board's own link stays beside every file. Replacements are looked for, not waited for: every pass fetches 40 held files again, the longest-unchecked first and none sooner than 30 days after its last check, so every file up to 64 MB is checked about every 55 days; the few larger ones are re-fetched by hand.

One box. A docket number in any spelling opens its sheet without a search. Anything else is matched, word by word, against three things: docket captions as the Board prints them (a sub-docket with a caption of its own is a result at its own address, which opens the family sheet); every name a party is currently on record under; and the Board's own printed decision summaries. Documents are searched too, by their own index and shown in their own section under the record results: a page hit names the record, the page, who read it (the tool or engine and its version, and the class the page was routed as), the distance from a second reading where one exists or why there is none, and the scan one click away. The text is a finding aid and the scan is the record; nothing a search finds in machine-read text is asserted by this site. The index is rebuilt from the record whenever the record has changed; it holds no reader's query, and the server keeps none.

Feeds and webhooks

Every alert channel renders the same record events — new or updated filings and decisions, and a file the Board replaced — observed by the forward poll. Entries added by a backfill wave never appear in any of them.

  • Atom feeds at /feed (agency-wide), /d/<docket>/feed and /d/<docket>/sub/<n>/feed (a proceeding — for most prefixes a sub-docket is a phase of its parent and its feed is the family’s, reached by a permanent redirect; for AB, where a Sub-No. is each line a carrier abandons, the sub-docket has a feed of its own) and /p/<id>/feed (filings for one party; the older /feed/party/<id> redirects there, permanently): the latest hundred entries, cached thirty minutes, nothing stored about the reader.
  • Webhooks: a signed JSON POST of the same entries to an https URL you control, as they happen or once a day. Confirmation is a ping to the URL carrying a confirmation link and a signing secret; nothing is delivered until the link is confirmed. Each delivery carries X-DocketYard-Signature: sha256=<HMAC-SHA256(secret, body)> over the exact bytes sent and X-DocketYard-Delivery with the alert id. It also carries X-DocketYard-Timestamp (Unix seconds) and X-DocketYard-Signature-Timestamped: sha256=<HMAC-SHA256(secret, "<timestamp>." + body)>: verify that one and refuse a timestamp more than five minutes from your clock, and a captured delivery cannot be replayed. The first signature is unchanged, so a receiver built against it keeps working. The body carries shape_version, raised when a field changes name or meaning; the body lists events (kind, docket, record id, the Board's date as printed, the record's permanent address here, the Board's files, and late: true when the entry was posted while this record was not being kept) and an unsubscribe_url. A delivery that is refused or unreachable is retried on later passes, three attempts in all. Only public https hosts are contacted, without following redirects.

Known failure modes

  • The Board's search returns a full unfiltered result set, with a success code, when a filter is passed the wrong way; and an identical "no results" envelope for a real empty result, an expired session token, and a page past the end. The pipeline positively checks that every response matches what it asked for, and refuses to ingest what it cannot prove. A refused page is kept raw and reported to the operator; it is never silently treated as empty.
  • The search shows at most 10,000 rows per query. No single docket prefix reaches it today; the watch window is a week, far below it.
  • A filing the Board back-dates into a day already watched is caught by the overlap between passes, and alerted as new when the record first sees it.
  • What the pipeline cannot see, it cannot record: entries the Board's search itself does not list are not here.