Measure DINS-to-FRAP incident join coverage, each join key a judgment call

[ChelseaKR]

What

The two datasets describe the same fires from different sides, and neither says how well they meet. This adds a third measurement page, join.html: for each DINS incident, whether a FRAP perimeter record exists for it, and for each FRAP record in the DINS era, whether any inspection records exist. The join is attempted on three keys in turn, each published separately and never merged: IRWIN ID where both carry one; CAL FIRE incident number with year and unit; normalized fire name with year. Counts are published per key: matched, unmatched, and ambiguous (one DINS incident matching several perimeters), with the DINS records and acres each bucket represents.

Why it matters

"Which burned structures have a mapped perimeter" is coverage in the project's own sense, and the answer depends on a join key nobody has audited, so the key is treated the way markers are: three readings, each counted, each with its evidence and cost in docs/MARKERS.md. Name joins are the weakest and the most tempting, and publishing them beside identifier joins shows what they are worth. No record is corrected, no fire is renamed, no rate is drawn per agency. The sibling wildfire-service-territory-overlap met the same naming problem joining a county's records (ADR 0018) and refused rather than guessed; this makes the refusal quantitative.

Scope

• src/perimeter/join.py: per-key match tables; ambiguity counted, never resolved; the DINS era boundary stated from the earliest incident start date in the file.
• Artifact site/data/join-coverage.json with is_fixture, per-key {matched, unmatched, ambiguous} in both directions, and a key_basis per key in the style of marker_basis.
• Page with the three-state key, WCAG gates, and prose-number tracing; a docs/MARKERS.md section for the join keys.
• Fixtures extended with a shared IRWIN id, a shared incident number, and a name-only near miss.

Out of scope

• Spatial joins (the sibling's lane) and any "best" key.
• Damage or loss totals per perimeter.

Done when

• Fixtures yield the hand-computed match counts per key, with the near miss unmatched under exact name and ambiguous under normalized name.
• A DINS incident with no start date is counted in its own cohort, not dropped.
• Zero matches on a key prints "none matched" in words and 0 in the artifact with its denominator.

Pointers

• src/perimeter/perimeters.py (duplicate-signal keys irwin_id, year_unit_incident_number, year_name_acres), dins.py, schema.py (INCIDENTNUM, INCIDENTNAME, INCIDENTSTARTDATE)
• docs/MARKERS.md, docs/adr/0003-published-versus-inferred-marker-basis.md

Proposed with AI assistance.

[ChelseaKR]

Triage against origin/main @ d4f533f (2026-09-06). Not built: no src/perimeter/join.py, no join-coverage.json, no join.html.

This is the one in this queue I would not hand to automation, and the issue explains why in its own words: "the answer depends on a join key nobody has audited, so the key is treated the way markers are: three readings, each counted, each with its evidence and cost in docs/MARKERS.md." docs/MARKERS.md is this project's judgment record; docs/adr/0003-published-versus-inferred-marker-basis.md distinguishes what a publisher declared from what this project inferred. Writing a key_basis for a normalized-name join is writing a judgment, and it is a judgment about whether two records describe the same fire.

What is mechanical and could be split out: the per-key match/unmatched/ambiguous counts themselves, over the existing duplicate-signal keys in perimeters.py (irwin_id, year_unit_incident_number, year_name_acres), with fixtures extended to carry a shared IRWIN id, a shared incident number, and a name-only near miss. Counting is not deciding, and the issue is right that publishing the name join beside the identifier joins is what shows the name join is worth less.

What must not be automated: the key_basis prose, and any collapse of the three keys into a "best" one. The sibling project met the same naming problem (its ADR 0018) and refused rather than guessed; this issue's whole value is making that refusal quantitative, which it stops doing the moment a machine writes the basis.

Leaving open. Needs: the owner's reading of each join key, or an explicit instruction that a drafted basis marked unreviewed is acceptable.

Triaged with AI assistance.

[ChelseaKR]

Triage, 2026-09-07. Unbuilt, and unblocked: both pinned files are on the owner's machine, so unlike #62's FRAP half this needs no new acquisition. The keys it names are present in both registries (IRWINID on the FRAP side, INCIDENTNUM, INCIDENTNAME and INCIDENTSTARTDATE on the DINS side).

Two facts from the pinned retrieval that bear on the design:

• FRAP IRWINID is empty in 19,701 of 23,334 records. The identifier join, which is the strongest of the three keys, is available for about 16% of the perimeter side. So "matched, unmatched, ambiguous" is not the whole story: a pair that could not be attempted under a key is a fourth state, and folding it into "unmatched" would publish an absence as a negative result, which is the defect this project is organised against. The issue's three buckets probably need a fourth, or an explicit denominator of records carrying the key at all.
• The DINS side holds 398 distinct incident names and 445 distinct incident numbers, so the name join has real collision surface to measure rather than a hypothetical one.

Not started this session. It is a new module, a new artifact, a new page and an ADR, and the page half carries the full render and WCAG pipeline.

Prepared with AI assistance; reviewed before submission.