How We Keep Hunting and Fishing Regulations Current

Regulations are the part of this app nobody asks us to talk about and everybody depends on. They’re also the part of the data stack that breaks most often — not because the rules themselves are complicated, but because the way agencies publish them was never designed to be read by software. A user standing on a river at first light shouldn’t have to scroll a PDF to know whether the fish in front of them is legal to keep. They shouldn’t have to remember which emergency rule was posted last Thursday, or whether the unit they hiked into has a different opener than the one next to it. Here’s how we keep that piece of the app current, and why we built the tooling we built to do it.

Why regulations are the worst data on the internet

State fishing and hunting regulations live in 200-to-500-page PDFs, written in dense legal prose, organized by region in one state and by species in the next. Tables span page breaks. Footnotes override the body text. A single river might be governed by three rules in three different sections of the same pamphlet, and the rules themselves often reference geography by landmark rather than by coordinate. There’s no schema, no API, and no version history — just a fresh PDF dropped on a static site once a year, with mid-season patches arriving as plain-text bulletins.

What WDFW, ODFW, and IDFG publish (and what they don’t)

Washington, Oregon, and Idaho each publish an annual pamphlet, a separate emergency-rule feed, and a handful of supplementary documents for marine areas and special permits. None of them share a format. WDFW leans on tables and a region-by-region split. ODFW writes in prose paragraphs grouped by zone. IDFG publishes per-unit summaries that fold seasons, weapon types, and bag limits into stacked subheaders. None of the three keys anything to a coordinate, a stream identifier, or a hunt unit boundary you can join against a map. The geography is described in English, and the work of resolving that English to a polygon falls on whoever wants to use the data.

Watching for emergency rules

The pamphlet is only half the story. Mid-season closures, in-season opener extensions, and bag-limit shifts arrive through emergency-rule announcements on agency news pages — sometimes weekly during salmon and steelhead runs, sometimes daily during a fire-driven closure. The pipeline we wrote polls those publication endpoints on a schedule, fingerprints each page against the last known version, and queues anything that’s changed since the previous check. New rules land in our review queue within minutes of going public, with the full source document attached so the reviewer can read it in context. Most days nothing changes. The days something does, we already know — and the users who have that water saved or who are physically near it get a push notification the moment the new rule clears review.

Attaching a rule to the right water

The harder problem is association. A rule that says “Snake River from the confluence with the Grande Ronde upstream to Hells Canyon Dam” has to be tied to the specific river segments a user might tap on. The parsing pipeline resolves those phrases against the river catalog and GMU boundaries already in the app, then writes the rule against the affected segments and only those segments. A statewide rule attaches to every segment in scope. A single-pool rule attaches to one. A rule that references a tributary by a name the agency uses but the catalog doesn’t gets aliased before it’s stored, so future rules referencing the same tributary resolve cleanly. Anything ambiguous — a landmark we can’t resolve, a boundary description that doesn’t match our catalog, two rules that overlap, a season that ends before it starts — never auto-publishes. It waits for a human, and the user keeps seeing the last verified rule until that human signs off.

The human review queue

Every parsed rule lands in an internal review queue before it ships. A reviewer sees the original agency text, the segments or units we matched it to, a side-by-side diff against any existing rule on the same water, and a confidence score from the automated checks. They approve, edit the association, or kick it back. Most rules clear review in under a minute because the structure is familiar and the match is clean. The ones that don’t are usually agency wording we haven’t seen before — a new way of describing a boundary, a permit type that didn’t exist last year, a footnote that inverts a table, or a region rename that breaks every joined query that touches it. Those become test cases for the next iteration of the parsing pipeline, and they make the next year’s annual pamphlet easier to absorb. Over time the queue gets shorter, not because there are fewer rules, but because more of the language is recognized on the first pass.

What goes wrong (and how we catch it)

Things break. An agency renames a river. A boundary description references a landmark that doesn’t exist in our catalog. A footnote inverts the meaning of a table row, so a section that looks open is actually closed. A pamphlet PDF gets re-uploaded with the same filename but different content, and the only signal that anything changed is the file fingerprint. The automated checks flag rules with low-confidence matches, rules that contradict an existing active rule on the same water, rules that reference geography we can’t resolve, and rules whose effective dates fall outside the season they cite. Everything flagged routes to review. Nothing flagged ships silently. When something slips through anyway — and it has, twice in the last year — the same review tooling lets us pull it back in seconds and push a corrected version to the affected users.

What’s next

River regulations across Washington, Oregon, and Idaho are live and refreshed continuously. GMU big-game seasons for the same three states are live and synced against the annual pamphlets within days of each release. Marine areas, lake-specific rules, and controlled-hunt draw details are the next tranche — and they each need their own parser because, of course, they’re each published in a different format than everything else. Marine areas use tide-window tables that change with the lunar calendar. Lakes use per-water blurbs scattered through the pamphlet, often grouped by county rather than by watershed. Controlled hunts use a separate draw document with its own taxonomy of permit types, weapons, reporting requirements, and per-unit quotas that don’t appear anywhere in the general pamphlet.

The honest version of this post is that regulations data will never be fully solved. Agencies will keep publishing PDFs. Emergency rules will keep arriving at 4pm on a Friday before opening weekend. New permit types will appear without warning, and old ones will be quietly retired. What we can do is keep the latency between “agency posts” and “user sees it on the map” as short as possible, keep the association between rule and water transparent enough that a reviewer can audit it in seconds, and keep the failure modes loud rather than quiet. We’d rather block a rule from shipping than ship one that’s wrong. The cost of a missed update is a user who has to tap through to the PDF for one more day. The cost of a wrong rule is a ticket, a citation, or a fish that shouldn’t have been kept that day. That trade-off shapes everything about how the pipeline is built — what we automate, what we don’t, and what gets a human’s eyes on it before it reaches yours.

If a regulation type isn’t covered yet — controlled hunts, marine areas, or lake-specific rules — it’s tracked in the in-app Development Queue.