Methodology and known issues

crime.*.ytd

Source

• OPD weekly crime reports (Box archive, doc_type='crime_report'), 'Part 1 Crimes' table; crime.py ROW_LABELS row -> third/current-year YTD column

What one unit counts

• Cumulative reported Part 1 offences (one most-severe offence per incident) that occurred from 1 January of the report year through the report's week, as entered by the time it ran.

Coverage

25,933 facts across 8 metrics, from 3,244 documents, covering 2016–2026, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: cumulative_ytd.

Anchor

• Document arithmetic (Phase 2): each report's YTD column must equal the prior report's YTD plus the intervening weekly deltas, or the difference is recorded as the measured late-reporting lag. Second anchor: annual YTD vs CA DOJ (doj.*.annual) at the comparable semantic level, modelling the auto-burglary classification difference explicitly.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The reports' own footer: "THIS REPORT IS HIERARCHY BASED. CRIME TOTALS REFLECT ONE OFFENSE (THE MOST SEVERE) PER INCIDENT." and "These statistics are drawn from the Oakland Police Dept. database. They are unaudited and not used to figure the crime numbers reported to the FBI's Uniform Crime Reporting (UCR) program. This report is run by the date the crimes occurred. Statistics can be affected by late reporting, the geocoding process, or the reclassification or unfounding of crimes. Because crime reporting and data entry can run behind, all crimes may not be recorded."
• Unaudited OPD database figures — explicitly NOT the city's FBI/UCR submission, so they are not interchangeable with doj.*.annual.
• Run by date of occurrence, so a period's value keeps growing after capture as late reports, reclassifications and unfoundings land.
• Traffic collision fatalities are excluded; unclassified burglaries are included in the burglary total.
• Pre-2017 reports print the table as an image and yield no facts; the series therefore starts in 2017.
• ALREADY CUMULATIVE. Every report of a year writes the same (metric, year, geography) key with its own running total; take the MAXIMUM per year (the final value the year reported), never the sum. See deptsite._ytd_annual().
• The period is the report's current year (crime.py stores parsed['current_year']), not the report date, so many facts share one period by design.
• Values with period NULL exist where neither the filename nor the manifest row yielded a date; those cannot be placed in time.
• The same series is published for Citywide and for Area 1-6. The Area rows are a partition of Citywide, so Citywide + Areas double-counts, and the Area rows alone are not guaranteed to reconcile to Citywide.

What would change the numbers

• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• document 9237 (Citywide weekly report, 06-12 Jul 2026) page 1 footer notes

crime.*.weekly

Source

• OPD weekly crime reports (Box archive, doc_type='crime_report'), 'Part 1 Crimes' table; crime.py ROW_LABELS row -> weekly column

What one unit counts

• One reported Part 1 offence — the most severe offence of one incident — that occurred in the report's seven-day window AND had been entered in OPD's database by the moment the report ran.

Coverage

25,925 facts across 8 metrics, from 3,243 documents, covering 2016-01-31–2026-07-12, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Document arithmetic (Phase 2): each report's YTD column must equal the prior report's YTD plus the intervening weekly deltas, or the difference is recorded as the measured late-reporting lag. Second anchor: annual YTD vs CA DOJ (doj.*.annual) at the comparable semantic level, modelling the auto-burglary classification difference explicitly.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The reports' own footer: "THIS REPORT IS HIERARCHY BASED. CRIME TOTALS REFLECT ONE OFFENSE (THE MOST SEVERE) PER INCIDENT." and "These statistics are drawn from the Oakland Police Dept. database. They are unaudited and not used to figure the crime numbers reported to the FBI's Uniform Crime Reporting (UCR) program. This report is run by the date the crimes occurred. Statistics can be affected by late reporting, the geocoding process, or the reclassification or unfounding of crimes. Because crime reporting and data entry can run behind, all crimes may not be recorded."
• Unaudited OPD database figures — explicitly NOT the city's FBI/UCR submission, so they are not interchangeable with doj.*.annual.
• Run by date of occurrence, so a period's value keeps growing after capture as late reports, reclassifications and unfoundings land.
• Traffic collision fatalities are excluded; unclassified burglaries are included in the burglary total.
• Pre-2017 reports print the table as an image and yield no facts; the series therefore starts in 2017.
• NOT SUMMABLE OVER TIME. Each week is captured at its least-complete moment, so the weekly column understates. Summing 2022's weekly burglary column gives 1,626 against the same reports' year-end YTD of 11,508 (7x). Use _ytd_annual() (max of crime.*.ytd per year) for annual totals.
• The same series is published for Citywide and for Area 1-6. The Area rows are a partition of Citywide, so Citywide + Areas double-counts, and the Area rows alone are not guaranteed to reconcile to Citywide.

What would change the numbers

• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• document 9237 (Citywide weekly report, 06-12 Jul 2026) page 1 footer notes

parking_inv.*

Source

• City of Oakland parking inventory datasets on data.oaklandca.gov (meters, downtown and Jack London on-street and off-street inventories, permit and disabled zones, the April 2021 weekend occupancy survey).

What one unit counts

• One inventoried parking asset — a meter, block face, garage or zone — or, for the occupancy survey, the share of spaces occupied at one surveyed timestamp.

Coverage

4,860 facts across 4,860 metrics, from 8 documents, covering 2026, in 6 geographies (Fruitvale, Grand Lake, Montclair, Oakland, Rockridge, Temescal).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: instant.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• SNAPSHOTS, never a series: an inventory counted once and dated by retrieval. Do not sum across periods.
• 87ce-u2wf and 3wwm-2td4 are the same 2,558 downtown block faces released twice; each keeps its own prefix and they are not additive.
• The weekend occupancy survey covers two April 2021 weekends during pandemic conditions and generalises to nothing.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 4,860 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

crime.total_part1.ytd

Source

• OPD weekly crime reports (Box archive, doc_type='crime_report'), 'Part 1 Crimes' table; crime.py ROW_LABELS row -> third/current-year YTD column

What one unit counts

• The reports' printed year-to-date 'Total' Part 1 row.

Coverage

3,244 facts across 1 metric, from 3,244 documents, covering 2016–2026, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: cumulative_ytd.

Anchor

• Document arithmetic (Phase 2): each report's YTD column must equal the prior report's YTD plus the intervening weekly deltas, or the difference is recorded as the measured late-reporting lag. Second anchor: annual YTD vs CA DOJ (doj.*.annual) at the comparable semantic level, modelling the auto-burglary classification difference explicitly.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The reports' own footer: "THIS REPORT IS HIERARCHY BASED. CRIME TOTALS REFLECT ONE OFFENSE (THE MOST SEVERE) PER INCIDENT." and "These statistics are drawn from the Oakland Police Dept. database. They are unaudited and not used to figure the crime numbers reported to the FBI's Uniform Crime Reporting (UCR) program. This report is run by the date the crimes occurred. Statistics can be affected by late reporting, the geocoding process, or the reclassification or unfounding of crimes. Because crime reporting and data entry can run behind, all crimes may not be recorded."
• Unaudited OPD database figures — explicitly NOT the city's FBI/UCR submission, so they are not interchangeable with doj.*.annual.
• Run by date of occurrence, so a period's value keeps growing after capture as late reports, reclassifications and unfoundings land.
• Traffic collision fatalities are excluded; unclassified burglaries are included in the burglary total.
• Pre-2017 reports print the table as an image and yield no facts; the series therefore starts in 2017.
• ALREADY CUMULATIVE — take the max per year.
• This is a TOTAL of the other crime.*.ytd rows; never stack or add it alongside its own components.
• The same series is published for Citywide and for Area 1-6. The Area rows are a partition of Citywide, so Citywide + Areas double-counts, and the Area rows alone are not guaranteed to reconcile to Citywide.

What would change the numbers

• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• document 9237 (Citywide weekly report, 06-12 Jul 2026) page 1 footer notes

crime.violent_index.ytd

Source

• OPD weekly crime reports (Box archive, doc_type='crime_report'), 'Part 1 Crimes' table; crime.py ROW_LABELS row -> third/current-year YTD column

What one unit counts

• The printed year-to-date 'Violent Crime Index' row.

Coverage

3,244 facts across 1 metric, from 3,244 documents, covering 2016–2026, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: cumulative_ytd.

Anchor

• Document arithmetic (Phase 2): each report's YTD column must equal the prior report's YTD plus the intervening weekly deltas, or the difference is recorded as the measured late-reporting lag. Second anchor: annual YTD vs CA DOJ (doj.*.annual) at the comparable semantic level, modelling the auto-burglary classification difference explicitly.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The reports' own footer: "THIS REPORT IS HIERARCHY BASED. CRIME TOTALS REFLECT ONE OFFENSE (THE MOST SEVERE) PER INCIDENT." and "These statistics are drawn from the Oakland Police Dept. database. They are unaudited and not used to figure the crime numbers reported to the FBI's Uniform Crime Reporting (UCR) program. This report is run by the date the crimes occurred. Statistics can be affected by late reporting, the geocoding process, or the reclassification or unfounding of crimes. Because crime reporting and data entry can run behind, all crimes may not be recorded."
• Unaudited OPD database figures — explicitly NOT the city's FBI/UCR submission, so they are not interchangeable with doj.*.annual.
• Run by date of occurrence, so a period's value keeps growing after capture as late reports, reclassifications and unfoundings land.
• Traffic collision fatalities are excluded; unclassified burglaries are included in the burglary total.
• Pre-2017 reports print the table as an image and yield no facts; the series therefore starts in 2017.
• ALREADY CUMULATIVE — take the max per year.
• A SUBTOTAL of homicide_all + agg_assault + rape + robbery.
• OPD's label, not the FBI's violent-crime definition.
• The same series is published for Citywide and for Area 1-6. The Area rows are a partition of Citywide, so Citywide + Areas double-counts, and the Area rows alone are not guaranteed to reconcile to Citywide.

What would change the numbers

• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• document 9237 (Citywide weekly report, 06-12 Jul 2026) page 1 footer notes

crime.total_part1.weekly

Source

• OPD weekly crime reports (Box archive, doc_type='crime_report'), 'Part 1 Crimes' table; crime.py ROW_LABELS row -> weekly column

What one unit counts

• The reports' printed 'Total' Part 1 row for the week — the sum of the individual Part 1 offence rows as OPD printed it.

Coverage

3,243 facts across 1 metric, from 3,243 documents, covering 2016-01-31–2026-07-12, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Document arithmetic (Phase 2): each report's YTD column must equal the prior report's YTD plus the intervening weekly deltas, or the difference is recorded as the measured late-reporting lag. Second anchor: annual YTD vs CA DOJ (doj.*.annual) at the comparable semantic level, modelling the auto-burglary classification difference explicitly.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The reports' own footer: "THIS REPORT IS HIERARCHY BASED. CRIME TOTALS REFLECT ONE OFFENSE (THE MOST SEVERE) PER INCIDENT." and "These statistics are drawn from the Oakland Police Dept. database. They are unaudited and not used to figure the crime numbers reported to the FBI's Uniform Crime Reporting (UCR) program. This report is run by the date the crimes occurred. Statistics can be affected by late reporting, the geocoding process, or the reclassification or unfounding of crimes. Because crime reporting and data entry can run behind, all crimes may not be recorded."
• Unaudited OPD database figures — explicitly NOT the city's FBI/UCR submission, so they are not interchangeable with doj.*.annual.
• Run by date of occurrence, so a period's value keeps growing after capture as late reports, reclassifications and unfoundings land.
• Traffic collision fatalities are excluded; unclassified burglaries are included in the burglary total.
• Pre-2017 reports print the table as an image and yield no facts; the series therefore starts in 2017.
• NOT SUMMABLE OVER TIME (see crime.*.weekly).
• This is a TOTAL of the other crime.*.weekly rows. Never stack or add it alongside its own components.
• The same series is published for Citywide and for Area 1-6. The Area rows are a partition of Citywide, so Citywide + Areas double-counts, and the Area rows alone are not guaranteed to reconcile to Citywide.

What would change the numbers

• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• document 9237 (Citywide weekly report, 06-12 Jul 2026) page 1 footer notes

crime.violent_index.weekly

Source

• OPD weekly crime reports (Box archive, doc_type='crime_report'), 'Part 1 Crimes' table; crime.py ROW_LABELS row -> weekly column

What one unit counts

• The printed 'Violent Crime Index' row for the week. crime.py validate() asserts it equals homicide_all (or homicide) + aggravated assault + rape + robbery within 2.

Coverage

3,243 facts across 1 metric, from 3,243 documents, covering 2016-01-31–2026-07-12, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Document arithmetic (Phase 2): each report's YTD column must equal the prior report's YTD plus the intervening weekly deltas, or the difference is recorded as the measured late-reporting lag. Second anchor: annual YTD vs CA DOJ (doj.*.annual) at the comparable semantic level, modelling the auto-burglary classification difference explicitly.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The reports' own footer: "THIS REPORT IS HIERARCHY BASED. CRIME TOTALS REFLECT ONE OFFENSE (THE MOST SEVERE) PER INCIDENT." and "These statistics are drawn from the Oakland Police Dept. database. They are unaudited and not used to figure the crime numbers reported to the FBI's Uniform Crime Reporting (UCR) program. This report is run by the date the crimes occurred. Statistics can be affected by late reporting, the geocoding process, or the reclassification or unfounding of crimes. Because crime reporting and data entry can run behind, all crimes may not be recorded."
• Unaudited OPD database figures — explicitly NOT the city's FBI/UCR submission, so they are not interchangeable with doj.*.annual.
• Run by date of occurrence, so a period's value keeps growing after capture as late reports, reclassifications and unfoundings land.
• Traffic collision fatalities are excluded; unclassified burglaries are included in the burglary total.
• Pre-2017 reports print the table as an image and yield no facts; the series therefore starts in 2017.
• NOT SUMMABLE OVER TIME (see crime.*.weekly).
• A SUBTOTAL of homicide_all + agg_assault + rape + robbery; never add or stack it alongside those components.
• 'Violent Crime Index' is OPD's label. It is not the FBI's violent crime definition and is not interchangeable with doj.violent.annual.
• The same series is published for Citywide and for Area 1-6. The Area rows are a partition of Citywide, so Citywide + Areas double-counts, and the Area rows alone are not guaranteed to reconcile to Citywide.

What would change the numbers

• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• document 9237 (Citywide weekly report, 06-12 Jul 2026) page 1 footer notes

nsa.task_compliance.*

Source

• NSA (Negotiated Settlement Agreement) monitor reports, doc_type='nsa_report' — per-task verdicts from 'Task N compliance status: X' headers and Table 2-style rows; nsa.py parse_status_lines / parse_table_rows

What one unit counts

• One monitor verdict on one NSA task at one report date, encoded as 1.0 = in compliance, 0.5 = partial compliance, 0.0 = not in compliance (nsa.py STATUS_VALUE). Deferred and inactive tasks are deliberately unscored.

Coverage

1,680 facts across 150 metrics, from 110 documents, covering 2003-12-22–2025-11-17, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: instant.

Anchor

• Corroboration by the report's own printed summary table where one exists (nsa.tasks_*_compliance for the same date).

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• An ORDINAL CODE, not a quantity. Summing or averaging these values treats 'partial' as exactly half of 'in compliance', which the reports do not assert.
• A verdict at a report date — an instant, not a period.
• Reports assess DIFFERENT task sets over time (22 active MOU tasks early, the last 8 problem tasks late), so counts derived from these verdicts are not comparable across dates without a denominator.
• KNOWN EXTRACTOR BUG (accuracy plan Phase 2): shares derived from these verdicts over-rate quarterlies that lack a printed summary table, because the denominator becomes only the tasks the report happened to mention. This is currently the one place the site knowingly shows wrong numbers.
• Ids include sub-tasks (task_1.2, task_1.4) alongside their parent (task_1); derived counts use top-level tasks only.
• Periods are printed report dates ('April 13, 2017'), not ISO dates; report.parse_period handles them.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• nsa.py STATUS_VALUE = {'in': 1.0, 'partial': 0.5, 'not': 0.0}, STATUS_LINE and parse_table_rows

crime.homicide_all.ytd

Source

• OPD weekly crime reports (Box archive, doc_type='crime_report'), 'Part 1 Crimes' table; crime.py ROW_LABELS row -> third/current-year YTD column ('Subtotal - 187' row)

What one unit counts

• Cumulative all-homicides (187(a) plus justified/accidental/negligent) from 1 January through the report's week.

Coverage

1,609 facts across 1 metric, from 1,609 documents, covering 2022–2026, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: cumulative_ytd.

Anchor

• Document arithmetic (Phase 2): each report's YTD column must equal the prior report's YTD plus the intervening weekly deltas, or the difference is recorded as the measured late-reporting lag. Second anchor: annual YTD vs CA DOJ (doj.*.annual) at the comparable semantic level, modelling the auto-burglary classification difference explicitly.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The reports' own footer: "THIS REPORT IS HIERARCHY BASED. CRIME TOTALS REFLECT ONE OFFENSE (THE MOST SEVERE) PER INCIDENT." and "These statistics are drawn from the Oakland Police Dept. database. They are unaudited and not used to figure the crime numbers reported to the FBI's Uniform Crime Reporting (UCR) program. This report is run by the date the crimes occurred. Statistics can be affected by late reporting, the geocoding process, or the reclassification or unfounding of crimes. Because crime reporting and data entry can run behind, all crimes may not be recorded."
• Unaudited OPD database figures — explicitly NOT the city's FBI/UCR submission, so they are not interchangeable with doj.*.annual.
• Run by date of occurrence, so a period's value keeps growing after capture as late reports, reclassifications and unfoundings land.
• Traffic collision fatalities are excluded; unclassified burglaries are included in the burglary total.
• Pre-2017 reports print the table as an image and yield no facts; the series therefore starts in 2017.
• ALREADY CUMULATIVE — take the max per year.
• SUPERSET of crime.homicide.ytd; never added to it.
• A February 2022 change in OPD's homicide counting affects comparability across that seam.
• The same series is published for Citywide and for Area 1-6. The Area rows are a partition of Citywide, so Citywide + Areas double-counts, and the Area rows alone are not guaranteed to reconcile to Citywide.

What would change the numbers

• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• crime.py ROW_LABELS 'homicide_all'; document 9237 (Citywide weekly report, 06-12 Jul 2026) page 1 footer notes

crime.homicide_all.weekly

Source

• OPD weekly crime reports (Box archive, doc_type='crime_report'), 'Part 1 Crimes' table; crime.py ROW_LABELS row -> weekly column ('Subtotal - 187' row)

What one unit counts

• All homicides for the week: PC 187(a) murders plus justified, accidental and negligent killings — the wider row the Violent Crime Index actually sums.

Coverage

1,608 facts across 1 metric, from 1,608 documents, covering 2022-02-20–2026-07-12, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Document arithmetic (Phase 2): each report's YTD column must equal the prior report's YTD plus the intervening weekly deltas, or the difference is recorded as the measured late-reporting lag. Second anchor: annual YTD vs CA DOJ (doj.*.annual) at the comparable semantic level, modelling the auto-burglary classification difference explicitly.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The reports' own footer: "THIS REPORT IS HIERARCHY BASED. CRIME TOTALS REFLECT ONE OFFENSE (THE MOST SEVERE) PER INCIDENT." and "These statistics are drawn from the Oakland Police Dept. database. They are unaudited and not used to figure the crime numbers reported to the FBI's Uniform Crime Reporting (UCR) program. This report is run by the date the crimes occurred. Statistics can be affected by late reporting, the geocoding process, or the reclassification or unfounding of crimes. Because crime reporting and data entry can run behind, all crimes may not be recorded."
• Unaudited OPD database figures — explicitly NOT the city's FBI/UCR submission, so they are not interchangeable with doj.*.annual.
• Run by date of occurrence, so a period's value keeps growing after capture as late reports, reclassifications and unfoundings land.
• Traffic collision fatalities are excluded; unclassified burglaries are included in the burglary total.
• Pre-2017 reports print the table as an image and yield no facts; the series therefore starts in 2017.
• NOT SUMMABLE OVER TIME (see crime.*.weekly).
• SUPERSET of crime.homicide.weekly (187(a) only). The two must never be added together or charted as separate categories.
• Present only in reports that print the 'Subtotal - 187' row (1,609 facts vs 3,196 for the narrower homicide row), so the series is shorter than its sibling.
• The same series is published for Citywide and for Area 1-6. The Area rows are a partition of Citywide, so Citywide + Areas double-counts, and the Area rows alone are not guaranteed to reconcile to Citywide.

What would change the numbers

• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• crime.py ROW_LABELS 'homicide_all' -> regex ^\s*Subtotal\s*[-–]\s*187, plus document 9237 (Citywide weekly report, 06-12 Jul 2026) page 1 footer notes

population.*.annual

Source

• Census ACS 5-YEAR estimates, table B03002 (Hispanic or Latino origin by race), place 0653000 (Oakland city, CA); census.py load_census / B03002_VARIABLES

What one unit counts

• Estimated RESIDENTS of Oakland city in that race/ethnicity category, from the five-year ACS estimate. The period IS the 5-year span ('2011-2015'), never a single year; charts place each estimate at its END year per ACS convention.

Coverage

1,050 facts across 75 metrics, from 2 documents, covering 2010–2023, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Re-query the ACS API for the exact table and vintage and assert equality (Phase 2), with the vintage recorded so a re-pull cannot silently substitute 1-year for 5-year estimates.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• NOT SUMMABLE OVER TIME: a stock of people, and consecutive 5-year estimates OVERLAP by four of five sample years, so adjacent values are not independent. NEVER present a year-over-year difference: it is ~a fifth of the real change plus noise and CAN HAVE THE WRONG SIGN.
• 5-YEAR estimates, not 1-year, and the stored period is the 5-year span ('2011-2015'). The vintage matters and must never be swapped silently.
• ESTIMATES published with margins of error that the pipeline does not fetch (E columns only) — the MOE's ABSENCE must be stated wherever precision is implied (SITE-RULES 3.6); small categories are not significantly different from each other, and derived by_age bands (male + female) have a WIDER MOE than either input.
• RESIDENTS ONLY. As a denominator for stops or RIPA it excludes the non-residents and commuters who appear in the numerator.
• Census sentinel values (-666666666 etc.) are dropped, so a missing year may mean suppression rather than zero.
• Years the API did not publish are skipped silently.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 1,050 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• census.py CENSUS_URL / B03002_VARIABLES and the manifest title "Census ACS 5-year B03002, Oakland place, 2010-2023"; params for=place:53000 in state:06

equity.*

Source

• The Oakland Equity Indicators baseline: 72 datasets published together on 2018-10-01 by the City Administrator's Department of Race and Equity, each a handful of rows breaking one indicator down by race/ethnicity, council district or police area.

What one unit counts

• One published Equity Indicators baseline value for one population group (or council district / police area) — a rate, share, count or median as the indicator defines it.

Coverage

1,043 facts across 837 metrics, from 72 documents, covering 2014–2026, in 28 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, CD 1, CD 2, CD 3, CD 4, CD 5, CD 6, CD 7, Citywide, Lakeside, Oakland, ZCTA5 94601, ZCTA5 94602, ZCTA5 94603, ZCTA5 94606, ZCTA5 94607, ZCTA5 94608, ZCTA5 94609, ZCTA5 94610, ZCTA5 94611, ZCTA5 94612, ZCTA5 94618, ZCTA5 94619, ZCTA5 94621).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• FROZEN. Every one of the 72 indicators was published on 2018-10-01 against 2016–2017 data and has never been updated. Treat as a one-time baseline, not a series.
• NOT SUMMABLE. Most values are rates, shares or medians; adding them across race groups or years is meaningless.
• Units differ per indicator and are inferred from the source column's name (rate / percent / count / median). Check the indicator before comparing two of them.
• The race/ethnicity categories are the city's own and differ between indicators (one dataset even ships the column misspelled as 'race_ehnicity'); they do not always align with the census categories used elsewhere in this corpus.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 1,043 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

crime.weekly.monthly.busiest_day_volume

Source

• OPD weekly Part 1 crime reports — the largest single weekly total in the month; crime.py coverage_series

What one unit counts

• The Part 1 total of the largest single week in that month.

Coverage

774 facts across 1 metric, from 774 documents, covering 2016-01–2026-07, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Coverage diagnostic; no external comparator.

Result: no external anchor.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Citywide and Area N rows overlap; never add across geographies.
• A COVERAGE DIAGNOSTIC — an extreme value by construction. Never summed, never presented as a demand series.
• crime.weekly.monthly.busiest_day is deliberately NOT emitted or registered for this series: the weekly corpus has no daily resolution (#11 / T38.4).

What would change the numbers

• 774 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.

Where the semantics were read

• crime.py coverage_series: max weekly value per month

crime.weekly.monthly.days_recorded

Source

• OPD weekly Part 1 crime reports — calendar days of the month covered by at least one recorded week's seven-day span; crime.py coverage_series

What one unit counts

• Days of that month covered by at least one recorded weekly report's span.

Coverage

774 facts across 1 metric, from 774 documents, covering 2016-01–2026-07, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Coverage diagnostic; no external comparator.

Result: no external anchor.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Citywide and Area N rows overlap; never add across geographies.
• A COVERAGE DIAGNOSTIC, not a crime measure. Summing it over months is meaningless.

What would change the numbers

• 774 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.

Where the semantics were read

• crime.py coverage_series: 7-day span day-set per week-ending date

crime.weekly.monthly.volume

Source

• OPD weekly Part 1 crime reports — crime.total_part1.weekly summed by the month of the week-ending date, one value per week (newest document wins); crime.py coverage_series

What one unit counts

• The sum of weekly-column Part 1 totals for weeks ending in that month. NOT a monthly crime count: the weekly column records only crimes entered by the time the report ran, and the same reports' own YTD increments typically run 2-4x the weekly column (T38.2).

Coverage

774 facts across 1 metric, from 774 documents, covering 2016-01–2026-07, in 7 geographies (Area 1, Area 2, Area 3, Area 4, Area 5, Area 6, Citywide).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• A coverage diagnostic over an incomplete-at-capture series; no external source publishes a comparable quantity.

Result: no external anchor.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Citywide and Area N rows overlap; never add across geographies.
• A COVERAGE-DETECTION metric ONLY, mirroring city311.monthly.*: it exists so absent and catch-up weeks are computable. It must never be presented as monthly crime volume.
• Not summable over time: the weekly columns it sums are incomplete at capture (their own YTD increments run 2-4x).
• One value per week even when two conflicting documents survive (newest wins) — see crime.py #11/T38.3.

What would change the numbers

• 774 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.

Where the semantics were read

• crime.py coverage_series: one value per (period), newest source_doc wins (#11 fix, 2026-07-28)

payroll.headcount.*

Source

• CA State Controller, Government Compensation in California (gcc.sco.ca.gov/RawExport/<year>_City.zip), rows with EmployerName='Oakland' and EmployerType='City'; controller_pay.py aggregate_oakland — one row counted per employee record

What one unit counts

• EMPLOYEE ROWS in the source file for that department for the calendar year — anyone who was paid at all during the year, including part-year, part-time and seasonal staff.

Coverage

726 facts across 114 metrics, from 10 documents, covering 2015–2024, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• publicpay.ca.gov entity-level published totals for Oakland per year (equality expected, same source via a different publication path); secondary band check against the ACFR salaries-and-benefits expense line (different basis, so a band not an equality).

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• NOT SUMMABLE OVER TIME: it is a count of people paid during a year, so adding years counts the same person repeatedly.
• NOT full-time equivalents and NOT a point-in-time staffing level. Anyone paid for one day counts as one.
• One row per employee record, so an employee appearing in two departments in a year is counted in both.
• Port of Oakland cost centres are absent from the source files in some years (2020, 2023), so citywide totals for those years cover city departments only — a coverage gap, not a staffing or payroll cut.
• 2015-2024 only.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 726 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• controller_pay.py aggregate_oakland: `headcount += 1` per Oakland row; CSV column DepartmentOrSubdivision

payroll.overtime.*

Source

• CA State Controller, Government Compensation in California (gcc.sco.ca.gov/RawExport/<year>_City.zip), rows with EmployerName='Oakland' and EmployerType='City'; controller_pay.py aggregate_oakland — OvertimePay column

What one unit counts

• Overtime pay in the calendar year for employees in that department.

Coverage

726 facts across 114 metrics, from 10 documents, covering 2015–2024, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• publicpay.ca.gov entity-level published totals for Oakland per year (equality expected, same source via a different publication path); secondary band check against the ACFR salaries-and-benefits expense line (different basis, so a band not an equality).

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COMPONENT of payroll.wages.* (TotalWages includes OvertimePay), so the two must never be stacked as disjoint parts or co-plotted on one axis at very different magnitudes (site rules 5.1, 5.2). deptsite stacks overtime on (wages - overtime) or charts them separately.
• Same department-reporting-unit drift and Port coverage gaps as payroll.wages.*.
• 2015-2024 only.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 726 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• CSV column TotalWages / OvertimePay / DepartmentOrSubdivision in data/csv/controller/oakland-pay-<year>.csv (header read live 2026-07-24)

payroll.wages.*

Source

• CA State Controller, Government Compensation in California (gcc.sco.ca.gov/RawExport/<year>_City.zip), rows with EmployerName='Oakland' and EmployerType='City'; controller_pay.py aggregate_oakland

What one unit counts

• Total wages paid in the calendar year to employees whose DepartmentOrSubdivision slugs to this key — the sum of the TotalWages column, which is RegularPay + OvertimePay + LumpSumPay + OtherPay.

Coverage

726 facts across 114 metrics, from 10 documents, covering 2015–2024, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• publicpay.ca.gov entity-level published totals for Oakland per year (equality expected, same source via a different publication path); secondary band check against the ACFR salaries-and-benefits expense line (different basis, so a band not an equality).

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The source's TotalWages column INCLUDES overtime. Verified on data/csv/controller/oakland-pay-2023.csv: RegularPay 404,323,865 + OvertimePay 91,968,538 + LumpSumPay 11,926,538 + OtherPay 46,984,671 = TotalWages 555,203,612 exactly. So payroll.wages.* and payroll.overtime.* must NEVER be stacked as if they were disjoint parts of a whole; stack overtime on (wages - overtime) or chart them apart.
• Wages only — employer pension and health contributions are a separate column (TotalRetirementAndHealthContribution) and are NOT in this figure, so it is not the cost of employment.
• Department keys come from the source's free-text DepartmentOrSubdivision column, slugged. Reporting units change between years, so a department series starting or stopping is often a reporting change rather than a real one.
• Port of Oakland cost centres are absent from the source files in some years (2020, 2023), so citywide totals for those years cover city departments only — a coverage gap, not a staffing or payroll cut.
• 2015-2024 only (controller_pay.YEARS).
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 726 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• CSV column TotalWages / OvertimePay / DepartmentOrSubdivision in data/csv/controller/oakland-pay-<year>.csv (header read live 2026-07-24)

city311.volume.*

Source

• Oakland 311 service requests, Socrata dataset quth-gb8e, aggregated from data/csv/311.csv; loaders.py extract_311_facts

What one unit counts

• One service request whose datetimeinit (the date it was opened) falls in the calendar year and whose reqcategory slugs to this key.

Coverage

377 facts across 33 metrics, from 1 document, covering 2013–2026, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Counted by the date OPENED, not closed or resolved.
• reqcategory is the city's internal queue code; a series name is not self-explanatory and needs the queue-code explainer (site rule 2.1).
• COVERAGE GAP: roughly 1.2 months of requests are absent from the source for February-April 2023 (a city ransomware outage). Our copy matches the source byte for byte, so the gap is the city's. Affected periods must be marked on every chart and table (city311.monthly.* exists to detect this from the data rather than from hardcoded dates).
• Categories appear and disappear as the city changes queue codes, so a series starting or ending is often a renaming.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 377 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_311_facts: CSV columns datetimeinit and reqcategory; year = init[:4]

doj.*_cleared.annual

Source

• CA DOJ OpenJustice 'Crimes and Clearances with Arson 1985-2024' CSV, rows with NCICCode='Oakland'; loaders.py DOJ_COLUMNS (*Clr_sum columns)

What one unit counts

• One offence cleared during the calendar year — by arrest or exceptional means — as reported to DOJ. The cleared offence need not have been reported in the same year.

Coverage

369 facts across 9 metrics, from 1 document, covering 1985–2025, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• OpenJustice's own published aggregate tables (and FBI CDE where the series exists), rather than only the CSV we downloaded.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Clearance counts only exist for violent, homicide, robbery and burglary in this file — there is no larceny or vehicle-theft clearance series to plot.
• 1995 is dropped from clearance rates: the DOJ file reports zero clearances for every category except homicide against offence counts nearly identical to 1994 — an incomplete agency submission, not a real collapse (deptsite._clearance_series()).
• A zero clearance count against a nonzero offence count is treated as missing data, not as a real zero.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 369 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py DOJ_COLUMNS: ViolentClr_sum, HomicideClr_sum, RobberyClr_sum, BurglaryClr_sum

city311.median_close_days.*

Source

• Oakland 311 service requests, Socrata quth-gb8e — median of (datetimeclosed - datetimeinit) in days, per category per year; loaders.py extract_311_facts

What one unit counts

• The MEDIAN days from opening to closing for requests in that category opened in that year, over closed requests only.

Coverage

317 facts across 28 metrics, from 1 document, covering 2013–2026, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• A median cannot be checked with Socrata's server-side aggregation, which offers count/sum but not median. Phase 2's option is recomputing it from an independently downloaded copy of the dataset.

Result: no external anchor.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A MEDIAN — never summed, and never averaged across categories or years without the underlying distributions.
• SURVIVORSHIP BIAS: only closed requests count, so a backlog of open requests shortens the median.
• Emitted only where at least 20 qualifying requests exist, so small categories have gaps that are a suppression rule, not faster service.
• Same Feb-Apr 2023 source coverage gap.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 317 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.

Where the semantics were read

• loaders.py extract_311_facts: `if days and len(days) >= 20: ... round(_stats.median(days), 1)` with the `0 <= days <= 3650` filter

doj.*.annual

Source

• CA DOJ OpenJustice 'Crimes and Clearances with Arson 1985-2024' CSV, rows with NCICCode='Oakland'; loaders.py DOJ_COLUMNS

What one unit counts

• One offence reported to the CA DOJ under UCR summary rules for the calendar year by Oakland PD.

Coverage

287 facts across 7 metrics, from 1 document, covering 1985–2025, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• OpenJustice's own published aggregate tables (and FBI CDE where the series exists), rather than only the CSV we downloaded.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• UCR summary reporting, audited by DOJ — a different measurement system from crime.*.weekly/ytd (unaudited OPD database, hierarchy-based). The two series will disagree; that disagreement is real and must be stated, not reconciled away.
• Auto burglary is classified differently between OPD's reports and UCR; comparisons must model that explicitly.
• Coverage 1985-2024. Charts are clipped to 2000+ per site rule 5.7; the full range stays in the CSV.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 287 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py DOJ_COLUMNS: CSV columns Homicide_sum, ForRape_sum, Robbery_sum, AggAssault_sum, Burglary_sum, VehicleTheft_sum, LTtotal_sum

budget.revenue.*

Source

• ACFR/CAFR Statement of Activities, general-revenues section, governmental-activities column, between 'General revenues:' and the printed 'Total general revenues' line; acfr.py parse_general_revenues / GENERAL_REVENUES

What one unit counts

• One fiscal year's general revenue from that source, in thousands of dollars, on the accrual basis.

Coverage

272 facts across 16 metrics, from 24 documents, covering 2002–2025, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• ACFR restatement cross-check (Phase 2): later ACFRs reprint earlier years in their ten-year statistical sections, giving every year a second, independent document witness.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Values are in THOUSANDS of dollars as printed ("Changes in Net Assets ... (In Thousands)"), not dollars. Never co-plot with budget.adopted.* or budget.book.* (plain dollars) without converting.
• Accrual, government-wide basis — not the same scope or basis as the adopted budget (budget.adopted.*) or the General Fund appropriations in budget.book.*.
• GENERAL revenues only. Program revenues (charges for services, operating and capital grants) are NOT in this family, so these lines do not add up to total city revenue.
• Detailed lines appear FY2007-2025; FY2003-2006 statements print state and local taxes only as aggregates and FY2002 extracts poorly, so the series starts late for most lines.
• The printed general-revenues total includes TRANSFERS, so the detail lines will not sum to it.
• Period is the fiscal year END year.

What would change the numbers

• 266 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• document 3932 (cafr-2002.pdf) page 31: "Changes in Net Assets June 30, 2002 (In Thousands)", Governmental Activities column; acfr.py parse_general_revenues docstring ("total is the printed governmental-activities figure, which includes transfers")

budget.book.proposed.*

Source

• Budget-book PDFs (doc_type='budget'), 'SUMMARY BY FUND' pages, fund '1010 - General Fund' section only; budgetbook.py parse_summary_by_fund

What one unit counts

• One fiscal year's GENERAL FUND (fund 1010) proposed expenditure appropriation for that department, in dollars, as printed in the budget book.

Coverage

255 facts across 59 metrics, from 5 documents, covering 2006–2023, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• Pre-Open-Budget-Oakland era; no external publisher of these figures. The available check is the document's own printed fund total and cross-foot (budgetbook.validate() currently checks only that the police line is plausible).

Result: no external anchor.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• PLAIN DOLLARS, not thousands.
• GENERAL FUND ONLY (fund 1010) — not all funds, so not comparable with budget.adopted.* or budget.proposed.*.
• PROPOSED, not adopted.
• Regex-extracted from flowed PDF text with only a plausibility gate (100,000 <= amount <= 600,000,000) and a police-line sanity check; extraction_confidence is 0.75 at best. Department labels are whatever the page printed, unmerged.
• Only three fiscal years yielded facts, two of them with periods stored as dates ('2009-06-30', '2010-06-30') rather than years.

What would change the numbers

• No extraction backlog, dataset re-aggregation, unrun anchor or open conflict is recorded for this family.

Where the semantics were read

• budgetbook.py FUND_RE (r'1010\s*[-]\s*General Fund') and ROW_RE (department label, up to two leading numbers, expenditure, FTE)

campaign.*.count

Source

• FPPC campaign-finance filings (Forms 460, 461, 465, 496, 497) as published on data.oaklandca.gov in CAL format — one row per itemised transaction, with the filing committee in filer_naml. The most actively maintained data on the portal: refreshed daily.

What one unit counts

• One itemised transaction row on a filed FPPC form whose transaction date falls in the period — a contribution, payment, loan or expenditure as the schedule defines it.

Coverage

216 facts across 17 metrics, from 17 documents, covering 2005–2026, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Counts FILINGS, not distinct contributors or payees. One donor giving four times is four rows.
• Amendments are filed as new rows; a corrected filing can leave both the original and the amendment in the count.
• The Form 460 schedules and the 'Show Me the Money' candidate views are two publications of the SAME filings. campaign.contributions_460a and campaign.candidate_contributions overlap; likewise campaign.payments and campaign.candidate_expenditures. Never add a 460 metric to its SMTM counterpart.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 216 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

campaign.*.amount

Source

• FPPC campaign-finance filings (Forms 460, 461, 465, 496, 497) as published on data.oaklandca.gov in CAL format — one row per itemised transaction, with the filing committee in filer_naml. The most actively maintained data on the portal: refreshed daily.

What one unit counts

• Sum of the schedule's own amount column over every itemised transaction dated in the period.

Coverage

201 facts across 16 metrics, from 16 documents, covering 2005–2026, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Nominal dollars, never inflation-adjusted.
• Sums the per-transaction column only (tran_amt1, amount, loan_amt1). The cumulative-to-date columns Socrata also publishes (tran_amt2, cum_ytd) already contain earlier transactions and are deliberately not summed.
• Only ITEMISED transactions appear on these schedules. Contributions under the FPPC itemisation threshold are reported as an unitemised lump on the summary page and are missing here, so the total understates money raised.
• The Form 460 schedules and the 'Show Me the Money' candidate views are two publications of the SAME filings. campaign.contributions_460a and campaign.candidate_contributions overlap; likewise campaign.payments and campaign.candidate_expenditures. Never add a 460 metric to its SMTM counterpart.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 201 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

budget.adopted.*

Source

• Open Budget Oakland flow CSVs (openoakland/openbudgetoakland _src/data/flow/FY**__adopted.csv), rows with account_type='expense', summed by department; obo.py aggregate

What one unit counts

• One fiscal year's ADOPTED budgeted expense appropriation for that department, in dollars, summed over every expense row the city published for it.

Coverage

180 facts across 34 metrics, from 8 documents, covering 2014–2023, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• Open Budget Oakland is a community re-publication of the city's budget files with no second publisher of the same aggregates. Phase 2's available check is a band comparison against the budget books (budget.book.*) where the years overlap, not an equality.

Result: no external anchor.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• PLAIN DOLLARS, not thousands — unlike every ACFR family (budget.expenses.*, budget.revenue.*, budget.gf_actual.*, budget.parks_rec_*), which are usd_thousands. Co-plotting without conversion is a 1000x error.
• ADOPTED means what council enacted at adoption; it is not actual spending and not the mid-year revised budget. Comparisons with actuals must state the scope and accounting-basis caveat (site rule 5.10).
• All funds, not just the General Fund — so not comparable with budget.book.* or budget.gf_actual.*.
• Period is the fiscal year END year (obo.end_year: 'FY22-23' -> '2023'). Only FY2014, 2015, 2016, 2017, 2020, 2021, 2022, 2023 exist as adopted; FY2018 and FY2019 are published only as proposed and live in budget.proposed.* so they cannot be silently conflated.
• Department names are merged across year-variants by obo.py DEPT_ALIAS. Genuine reorgs are deliberately NOT merged (workplace_and_employment_standards, community_services, administrative_services, non_departmental_and_port), so those series legitimately start or stop mid-history.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 180 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.

Where the semantics were read

• obo.py aggregate(): CSV columns account_type, amount, budget_year, department; ADOPTED_FILES list

demog.unemployment*

Source

• Oakland unemployment by race by year (data.oaklandca.gov tjw3-c6vj, and its duplicate release h8k4-j4xq).

What one unit counts

• The unemployment rate for one race or ethnicity group in Oakland in the year.

Coverage

180 facts across 18 metrics, from 2 documents, covering 2010–2019, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• FRACTIONS, NOT PERCENTAGES: 0.059 means 5.9%.
• NOT SUMMABLE across groups — they are rates over different denominators.
• tjw3-c6vj and h8k4-j4xq are the same ten rows published twice; demog.unemployment_alt exists to make the duplication visible and must not be treated as a second observation.
• Covers 2010–2019; the series stops there.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 180 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

council.matters.*

Source

• Legistar API matter metadata already synced into the manifest DB's `matters` table; council.py extract_all (GROUP BY substr(intro_date,1,4), matter_type)

What one unit counts

• One council matter INTRODUCED in the calendar year with that matter_type.

Coverage

172 facts across 16 metrics, from 0 documents, covering 2000–2026, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• Re-query the Legistar API for matter counts by introduction year and type and assert equality (Phase 2).

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Counted by INTRODUCTION date, not passage — a matter introduced in December and passed in February counts in the earlier year, and nothing here says whether it passed.
• These facts have NO source document (source_doc is NULL); their provenance is the matters table synced from the Legistar API, so they cannot be traced to a page image the way PDF facts can.
• Coverage starts 2000 — council.extract_all defaults to legistar.RECORD_FLOOR, the first year Legistar publishes; nothing earlier exists upstream to count. The most recent year is partial until it ends.
• 6 matters carry no introduction date in Legistar (the year-2000 file-number series) and are excluded from every year: these series are keyed on introduction year, and the city never published one for them. They are not lost — the matters table keeps them — only unplaceable in a yearly count.
• Only five types span the whole 2000-2026 record (ordinance, city_resolution, informational_report, report_and_recommendation, total). The rest are genuinely short-lived, not gapped: the joint-authority and redevelopment successor types run only while those bodies existed (jpa_resolution 1 year, jpfa_resolution 2, orsa_resolution 12, ora_resolution 13), and the types Legistar has since retired (the defunct_* series, plus proclamation and appointment) belong to the 2000s clerical vocabulary and stop when the city stopped using them.
• Coverage depends on the completeness of the Legistar sync, which is a separate process.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 172 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• council.py extract_all SQL: `substr(intro_date, 1, 4) AS year, matter_type, COUNT(*)` over the matters table

city311.monthly.busiest_day

Source

• Oakland 311 service requests, Socrata quth-gb8e — the day-of-month number of the busiest day; loaders.py extract_311_facts

What one unit counts

• The DAY-OF-MONTH NUMBER (1-31) of the busiest day in that month. This is a label, not a quantity.

Coverage

155 facts across 1 metric, from 1 document, covering 2013-08–2026-07, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: instant.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• NOT A QUANTITY. It is a calendar day number; summing, averaging or plotting it on a value axis is meaningless. It exists to name the day that city311.monthly.busiest_day_volume refers to.
• Ties are broken by the later date.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 155 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_311_facts: `float(int(top[8:10]))` stored with unit 'day of month'

city311.monthly.busiest_day_volume

Source

• Oakland 311 service requests, Socrata quth-gb8e — the request count of the busiest single day in the month; loaders.py extract_311_facts

What one unit counts

• Requests opened on the single busiest day of that month.

Coverage

155 facts across 1 metric, from 1 document, covering 2013-08–2026-07, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COVERAGE DIAGNOSTIC — an extreme value by construction. Never summed, never averaged into a demand series.
• Ties are broken by the later date, so the day chosen is not necessarily unique.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 155 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_311_facts: `top = max(days, key=lambda d: (days[d], d))` then `days[top]`

city311.monthly.days_recorded

Source

• Oakland 311 service requests, Socrata quth-gb8e — number of distinct calendar days in the month that carry at least one request; loaders.py extract_311_facts

What one unit counts

• Distinct days in that month on which at least one request was opened.

Coverage

155 facts across 1 metric, from 1 document, covering 2013-08–2026-07, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COVERAGE DIAGNOSTIC, not a service measure. Summing it over months is meaningless.
• It cannot distinguish 'the city recorded nothing that day' from 'nobody called that day', so it flags candidate gaps for verification rather than proving them.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 155 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_311_facts: `float(len(month_days.get(month, {})))`

city311.monthly.volume

Source

• Oakland 311 service requests, Socrata quth-gb8e — count by YYYY-MM of datetimeinit; loaders.py extract_311_facts

What one unit counts

• Every 311 service request opened in that calendar month.

Coverage

155 facts across 1 metric, from 1 document, covering 2013-08–2026-07, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COVERAGE-DETECTION metric first: it exists so the site can compute which months are thin, absent or compensating, instead of carrying hand-written dates.
• Summable over time by construction, but a sum across a period containing the Feb-Apr 2023 outage understates it.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 155 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_311_facts: `monthly[month] = monthly.get(month, 0) + 1` with month = init[:7]

ethics.*

Source

• Oakland Public Ethics Commission enforcement, behested payment (FPPC Form 803), ticket distribution (Form 802), delinquent-filer and PRA-mediation datasets on data.oaklandca.gov.

What one unit counts

• One reported item: an enforcement case opened, a behested payment, a distributed ticket record, a delinquent filing, or a completed records-request mediation.

Coverage

151 facts across 57 metrics, from 8 documents, covering 2002–2026, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Enforcement counts measure COMMISSION ACTIVITY, not the rate of underlying violations: a year with more cases may mean more enforcement capacity rather than more misconduct.
• ethics.tickets and ethics.tickets_2009_2017 are two releases of the same Form 802 obligation and overlap in any year both cover; they are never added together.
• PRA mediations count only disputes the Commission mediated to completion, a small subset of records requests the city receives.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 151 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

budget.expenses.*

Source

• ACFR/CAFR Statement of Activities, governmental-activities column, expenses-by-function section (MD&A comparative table in years where the statement page extracts poorly); acfr.py parse_expenses / FUNCTIONS

What one unit counts

• One fiscal year's governmental-activities expenses for that function, in thousands of dollars, on the accrual basis.

Coverage

144 facts across 6 metrics, from 24 documents, covering 2002–2025, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• ACFR restatement cross-check (Phase 2): later ACFRs reprint earlier years in their ten-year statistical sections, giving every year a second, independent document witness.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• Values are in THOUSANDS of dollars as printed ("Changes in Net Assets ... (In Thousands)"), not dollars. Never co-plot with budget.adopted.* or budget.book.* (plain dollars) without converting.
• Accrual, government-wide basis — not the same scope or basis as the adopted budget (budget.adopted.*) or the General Fund appropriations in budget.book.*.
• Period is the fiscal year END year (acfr.py fiscal_year_from_title), i.e. '2023' means FY2022-23.
• Function labels drift across two decades (Life enrichment -> Community services -> Community and human services; 'Community & economic development' with an ampersand) and are merged onto stable keys by acfr.py FUNCTIONS.
• The per-function sum matches the printed total only in some years; acfr.py validate() flags a >1% gap. Any 'the functions sum to the total' claim must be computed per year, never asserted (site rule 3.4).

What would change the numbers

• 144 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• document 3932 (cafr-2002.pdf) page 31: "Changes in Net Assets June 30, 2002 (In Thousands)", Governmental Activities column; acfr.py FUNCTIONS label patterns

fire.incidents.monthly.busiest_day

Source

• Oakland Fire Department incident log produced under public-records request 26-8034 (document 47372, report id 'INC025 (3.00)', printed 2026-07-21, header 'Date Range From: 1/1/2015 To 7/21/2026'); fire_log.py parse_document -> facts_from, counted from the parsed rows of every page

What one unit counts

• Which day of the month the busiest day was — a calendar component, not a quantity.

Coverage

139 facts across 1 metric, from 1 document, covering 2015-01–2026-07, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: instant.

Anchor

• self-consistent: the document's own printed totals page. A full parse must recover the printed number of incidents, and the printed completed and reviewed counts, exactly; the loader writes nothing when it does not. No external publisher restates this log — OFD publishes no incident data — so the family is NOT independently anchored.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A DAY-OF-MONTH INDEX. Adding, averaging or charting it as a count is meaningless.
• GEOGRAPHY: every fact in this family is a count of records as produced under public-records request 26-8034, which includes a small number of mutual-aid incidents outside Oakland — measured at 0.12% of rows (806 of 671,326, on Emeryville or Alameda streets, from the geocoded address distribution). The log has no city field, so these rows cannot be identified or filtered at parse time; the facts are labelled geography='Oakland' and carry this caveat instead.
• NO RESPONSE TIME IS DERIVABLE from this source: the log carries one timestamp per incident (the alarm time) and no dispatch, en-route, arrival or clear time, and no unit column.
• COVERAGE DEFECT 2022-04 to 2023-02: monthly volumes run far below the surrounding years with a compensating catch-up month inside the window, and the category split moves at the same time. Detected from fire.incidents.monthly.* by coverage.detect_coverage, not asserted.
• The document's rows are ordered by incident number, not by date, and carry no station, unit or district, so no geography below citywide and no per-unit figure exists.
• Every row carries a full street address including apartment numbers; no address, and nothing per-record, is written to the corpus.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 139 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• fire_log.py, verified against document 47372: coverage.CoverageAggregator busiest_day

fire.incidents.monthly.busiest_day_volume

Source

• Oakland Fire Department incident log produced under public-records request 26-8034 (document 47372, report id 'INC025 (3.00)', printed 2026-07-21, header 'Date Range From: 1/1/2015 To 7/21/2026'); fire_log.py parse_document -> facts_from, counted from the parsed rows of every page

What one unit counts

• Records dated to the single busiest day of that month.

Coverage

139 facts across 1 metric, from 1 document, covering 2015-01–2026-07, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• self-consistent: the document's own printed totals page. A full parse must recover the printed number of incidents, and the printed completed and reviewed counts, exactly; the loader writes nothing when it does not. No external publisher restates this log — OFD publishes no incident data — so the family is NOT independently anchored.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COVERAGE-DETECTION metric: an outsized single day is the fingerprint of a backfill dump.
• GEOGRAPHY: every fact in this family is a count of records as produced under public-records request 26-8034, which includes a small number of mutual-aid incidents outside Oakland — measured at 0.12% of rows (806 of 671,326, on Emeryville or Alameda streets, from the geocoded address distribution). The log has no city field, so these rows cannot be identified or filtered at parse time; the facts are labelled geography='Oakland' and carry this caveat instead.
• NO RESPONSE TIME IS DERIVABLE from this source: the log carries one timestamp per incident (the alarm time) and no dispatch, en-route, arrival or clear time, and no unit column.
• COVERAGE DEFECT 2022-04 to 2023-02: monthly volumes run far below the surrounding years with a compensating catch-up month inside the window, and the category split moves at the same time. Detected from fire.incidents.monthly.* by coverage.detect_coverage, not asserted.
• The document's rows are ordered by incident number, not by date, and carry no station, unit or district, so no geography below citywide and no per-unit figure exists.
• Every row carries a full street address including apartment numbers; no address, and nothing per-record, is written to the corpus.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 139 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• fire_log.py, verified against document 47372: coverage.CoverageAggregator busiest_day_volume

fire.incidents.monthly.days_recorded

Source

• Oakland Fire Department incident log produced under public-records request 26-8034 (document 47372, report id 'INC025 (3.00)', printed 2026-07-21, header 'Date Range From: 1/1/2015 To 7/21/2026'); fire_log.py parse_document -> facts_from, counted from the parsed rows of every page

What one unit counts

• Distinct days of that month on which at least one record is dated.

Coverage

139 facts across 1 metric, from 1 document, covering 2015-01–2026-07, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• self-consistent: the document's own printed totals page. A full parse must recover the printed number of incidents, and the printed completed and reviewed counts, exactly; the loader writes nothing when it does not. No external publisher restates this log — OFD publishes no incident data — so the family is NOT independently anchored.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COVERAGE-DETECTION metric, not a quantity of anything.
• GEOGRAPHY: every fact in this family is a count of records as produced under public-records request 26-8034, which includes a small number of mutual-aid incidents outside Oakland — measured at 0.12% of rows (806 of 671,326, on Emeryville or Alameda streets, from the geocoded address distribution). The log has no city field, so these rows cannot be identified or filtered at parse time; the facts are labelled geography='Oakland' and carry this caveat instead.
• NO RESPONSE TIME IS DERIVABLE from this source: the log carries one timestamp per incident (the alarm time) and no dispatch, en-route, arrival or clear time, and no unit column.
• COVERAGE DEFECT 2022-04 to 2023-02: monthly volumes run far below the surrounding years with a compensating catch-up month inside the window, and the category split moves at the same time. Detected from fire.incidents.monthly.* by coverage.detect_coverage, not asserted.
• The document's rows are ordered by incident number, not by date, and carry no station, unit or district, so no geography below citywide and no per-unit figure exists.
• Every row carries a full street address including apartment numbers; no address, and nothing per-record, is written to the corpus.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 139 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• fire_log.py, verified against document 47372: coverage.CoverageAggregator month_days

fire.incidents.monthly.volume

Source

• Oakland Fire Department incident log produced under public-records request 26-8034 (document 47372, report id 'INC025 (3.00)', printed 2026-07-21, header 'Date Range From: 1/1/2015 To 7/21/2026'); fire_log.py parse_document -> facts_from, counted from the parsed rows of every page

What one unit counts

• Every record dated in that calendar month.

Coverage

139 facts across 1 metric, from 1 document, covering 2015-01–2026-07, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• self-consistent: the document's own printed totals page. A full parse must recover the printed number of incidents, and the printed completed and reviewed counts, exactly; the loader writes nothing when it does not. No external publisher restates this log — OFD publishes no incident data — so the family is NOT independently anchored.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COVERAGE-DETECTION metric first: it exists so the site can compute which months are thin, absent or compensating instead of carrying hand-written dates.
• Summable over time by construction, but a sum spanning the 2022-04..2023-02 coverage defect understates it.
• GEOGRAPHY: every fact in this family is a count of records as produced under public-records request 26-8034, which includes a small number of mutual-aid incidents outside Oakland — measured at 0.12% of rows (806 of 671,326, on Emeryville or Alameda streets, from the geocoded address distribution). The log has no city field, so these rows cannot be identified or filtered at parse time; the facts are labelled geography='Oakland' and carry this caveat instead.
• NO RESPONSE TIME IS DERIVABLE from this source: the log carries one timestamp per incident (the alarm time) and no dispatch, en-route, arrival or clear time, and no unit column.
• COVERAGE DEFECT 2022-04 to 2023-02: monthly volumes run far below the surrounding years with a compensating catch-up month inside the window, and the category split moves at the same time. Detected from fire.incidents.monthly.* by coverage.detect_coverage, not asserted.
• The document's rows are ordered by incident number, not by date, and carry no station, unit or district, so no geography below citywide and no per-unit figure exists.
• Every row carries a full street address including apartment numbers; no address, and nothing per-record, is written to the corpus.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 139 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• fire_log.py, verified against document 47372: coverage.CoverageAggregator fed each record's date

doj_arrests.*.annual

Source

• CA DOJ OpenJustice OnlineArrestData 1980-2025 CSV, Alameda County rows; doj_extra.py load_arrests

What one unit counts

• One adult-or-juvenile arrest recorded in Alameda County for the calendar year.

Coverage

138 facts across 3 metrics, from 1 document, covering 1980–2025, in 1 geography (Alameda County).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• OpenJustice's own published aggregate tables (and FBI CDE where the series exists), rather than only the CSV we downloaded.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• GEOGRAPHY IS ALAMEDA COUNTY, NOT OAKLAND. The source file is county-level only. Never presented or compared as an Oakland figure.
• doj_arrests.total.annual is a TOTAL of the felony and misdemeanour series (plus any status offences the source carries); do not add it to its parts.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 138 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• doj_extra.py module docstring + load_arrests: the source file has NO agency/NCIC column, so Oakland PD cannot be isolated

fire.incidents.category.*.annual

Source

• Oakland Fire Department incident log produced under public-records request 26-8034 (document 47372, report id 'INC025 (3.00)', printed 2026-07-21, header 'Date Range From: 1/1/2015 To 7/21/2026'); fire_log.py parse_document -> facts_from, counted from the parsed rows of every page

What one unit counts

• Records dated in the calendar year whose incident-type code and description classify to this category (fire_log.classify_type: cancellation first, then the NFIRS first-digit series).

Coverage

119 facts across 10 metrics, from 1 document, covering 2015–2026, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• self-consistent: the document's own printed totals page. A full parse must recover the printed number of incidents, and the printed completed and reviewed counts, exactly; the loader writes nothing when it does not. No external publisher restates this log — OFD publishes no incident data — so the family is NOT independently anchored.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A cancelled call is counted as `cancelled`, not under the code series it was dispatched as: the log records cancellations under both the EMS (3xx) and good-intent (6xx) series, and folding them in would overstate worked incidents.
• The type-coding scheme CHANGES mid-document (3-character NFIRS codes with local suffixes, then 2-digit NFIRS subcategory rollups as well), and the cancelled/service-call split moves inside the 2022-04..2023-02 window, so the category series are not comparable across it.
• GEOGRAPHY: every fact in this family is a count of records as produced under public-records request 26-8034, which includes a small number of mutual-aid incidents outside Oakland — measured at 0.12% of rows (806 of 671,326, on Emeryville or Alameda streets, from the geocoded address distribution). The log has no city field, so these rows cannot be identified or filtered at parse time; the facts are labelled geography='Oakland' and carry this caveat instead.
• NO RESPONSE TIME IS DERIVABLE from this source: the log carries one timestamp per incident (the alarm time) and no dispatch, en-route, arrival or clear time, and no unit column.
• COVERAGE DEFECT 2022-04 to 2023-02: monthly volumes run far below the surrounding years with a compensating catch-up month inside the window, and the category split moves at the same time. Detected from fire.incidents.monthly.* by coverage.detect_coverage, not asserted.
• The document's rows are ordered by incident number, not by date, and carry no station, unit or district, so no geography below citywide and no per-unit figure exists.
• Every row carries a full street address including apartment numbers; no address, and nothing per-record, is written to the corpus.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 119 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• fire_log.py, verified against document 47372: Aggregate.by_year_category with fire_log.classify_type

budget.book.adopted.*

Source

• Budget-book PDFs, 'SUMMARY BY FUND' pages, fund '1010 - General Fund' section, adopted flavour; budgetbook.py parse_summary_by_fund

What one unit counts

• One fiscal year's General Fund ADOPTED expenditure appropriation for that department, in dollars, as printed in the budget book.

Coverage

110 facts across 39 metrics, from 2 documents, covering 2006–2009, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• No external publisher; the check is the document's own printed fund total.

Result: no external anchor.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• PLAIN DOLLARS, not thousands.
• GENERAL FUND ONLY (fund 1010).
• No facts currently carry this pattern — every extracted budget book parsed as 'proposed'. The entry exists so an adopted book cannot be loaded without declared semantics.
• Same regex-extraction confidence limits as budget.book.proposed.*.

What would change the numbers

• No extraction backlog, dataset re-aggregation, unrun anchor or open conflict is recorded for this family.

Where the semantics were read

• budgetbook.py parse_summary_by_fund: flavour comes from HEADER_RE group(3) ('proposed'/'adopted')

shotspotter.*

Source

• OPD ShotSpotter gunshot-detection activation extracts on data.oaklandca.gov (five date-bounded releases, 2013–2015).

What one unit counts

• One ShotSpotter sensor activation the system classified as gunfire or a related sound, with the rounds it estimated.

Coverage

107 facts across 52 metrics, from 5 documents, covering 2026, in 19 geographies (17X, 20X, 21X, 21Y, 23X, 24X, 24Y, 26Y, 27X, 27Y, 2Y, 30X, 30Y, 32X, 33X, 34X, 35X, 7X, Oakland).

Adding values

Summable across periods: yes. Summable across geographies: yes. Period kinds: interval.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• SENSOR EVENTS, NOT SHOOTINGS. An activation is an acoustic classification; fireworks and backfires generate them, and gunfire outside sensor coverage does not. It measures the sensor network as much as the city.
• The five releases have OVERLAPPING date windows (the 2015 extracts run 07-15→08-01, 08-01→08-31, 08-16→09-15, 09-16→10-06). Each keeps its own prefix; summing them double-counts August 2015.
• Coverage is only the part of the city with sensors, which the city has never published.
• Geography is the police beat recorded on the activation. Beats partition the city, so beat counts add up — but only across the sensored beats that appear at all.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 107 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

parking.citations.monthly

Source

• Oakland parking citations, Socrata 58em-y96b, count by month of ticket_iss; loaders.py extract_parking_facts

What one unit counts

• One deduplicated parking citation issued in that calendar month.

Coverage

99 facts across 1 metric, from 1 document, covering 2018-01-01–2026-03-01, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The period is stored as the FIRST OF THE MONTH ('2019-04-01') but the value covers the whole month; it is not a daily figure.
• Same wholesale source duplication (Apr-Jun 2019, Apr 2023), removed here.
• Counted by date issued.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 99 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_parking_facts: mkey = month + '-01' (first-of-month so %Y-%m-%d parses)

parking.monthly.busiest_day

Source

• Oakland parking citations, Socrata 58em-y96b — the day-of-month number of the busiest day; loaders.py extract_parking_facts coverage pass

What one unit counts

• The DAY-OF-MONTH NUMBER (1-31) of the busiest day in that month. This is a label, not a quantity.

Coverage

99 facts across 1 metric, from 1 document, covering 2018-01–2026-03, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: instant.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• NOT A QUANTITY. It is a calendar day number; summing, averaging or plotting it on a value axis is meaningless. It names the day parking.monthly.busiest_day_volume refers to.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 99 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_parking_facts coverage pass, same mechanism as city311.monthly.busiest_day

parking.monthly.busiest_day_volume

Source

• Oakland parking citations, Socrata 58em-y96b — citation count of the busiest single day in the month; loaders.py extract_parking_facts coverage pass

What one unit counts

• Citations issued on the single busiest day of that month.

Coverage

99 facts across 1 metric, from 1 document, covering 2018-01–2026-03, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COVERAGE DIAGNOSTIC — an extreme value by construction. Never summed, never averaged into an enforcement series.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 99 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_parking_facts coverage pass, same max-day mechanism as city311.monthly.busiest_day_volume

parking.monthly.days_recorded

Source

• Oakland parking citations, Socrata 58em-y96b — distinct calendar days in the month carrying at least one citation; loaders.py extract_parking_facts coverage pass

What one unit counts

• Distinct days in that month on which at least one citation was issued.

Coverage

99 facts across 1 metric, from 1 document, covering 2018-01–2026-03, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COVERAGE DIAGNOSTIC, not an enforcement measure. Summing it over months is meaningless.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 99 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_parking_facts coverage pass, same day-set mechanism as city311.monthly.days_recorded

parking.monthly.volume

Source

• Oakland parking citations, Socrata 58em-y96b — deduplicated citation count by YYYY-MM; loaders.py extract_parking_facts coverage pass

What one unit counts

• Every deduplicated parking citation issued in that calendar month.

Coverage

99 facts across 1 metric, from 1 document, covering 2018-01–2026-03, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A COVERAGE-DETECTION metric first, mirroring city311.monthly.*: it exists so thin/absent/compensating months are computable.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 99 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_parking_facts: coverage facts via coverage.coverage_metric_ids('parking')

city311.district_volume.*

Source

• Oakland 311 service requests, Socrata quth-gb8e — count by councildistrict per year; loaders.py extract_311_facts

What one unit counts

• One service request opened in the calendar year whose councildistrict field names that council district.

Coverage

98 facts across 7 metrics, from 1 document, covering 2013–2026, in 7 geographies (District 1, District 2, District 3, District 4, District 5, District 6, District 7).

Adding values

Summable across periods: yes. Summable across geographies: yes. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• The seven districts ARE disjoint, so they may be summed across geography — but they do not reconcile to city311.volume.total, because requests with a blank or non-CCD district are dropped.
• The source spells districts inconsistently ('CCD 6' vs 'CCD6'); internal whitespace is stripped so one district is one series (an audit found a phantom 'ccd 6' with a single request).
• Heading must say what is counted, of what, over what — 'by council district' alone is a defect (site rule 2.2).
• Same Feb-Apr 2023 source coverage gap.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 98 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_311_facts: CSV column councildistrict, whitespace-stripped and upper-cased, kept when it starts with 'CCD'; geography stored as 'District <n>'

parking.fines.monthly

Source

• Oakland parking citations, Socrata 58em-y96b — fine_amount summed per month, emitted only for months with fine data; loaders.py extract_parking_facts

What one unit counts

• Dollars of fines assessed on citations issued in that calendar month.

Coverage

98 facts across 1 metric, from 1 document, covering 2018-01-01–2026-03-01, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A MISSING MONTH IS A GAP, NOT ZERO. Months with citations but not one nonzero fine emit no fact at all; the chart must gap them rather than draw $0 (site rule 3.2).
• Period is stored as the first of the month; the value covers the whole month.
• Fines assessed, not revenue collected.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 98 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_parking_facts: `if mkey in unreported: continue # fine column unpopulated that month - gap, not $0`

parking.violation.*.annual

Source

• Oakland parking citations, Socrata 58em-y96b — count by canonicalised violation description per year, top 15 violation types only; loaders.py extract_parking_facts / PARKING_TOP_VIOLATIONS / names.parking_violation_slug

What one unit counts

• One deduplicated citation issued in the calendar year whose violatio_1 description canonicalises to this violation type.

Coverage

87 facts across 15 metrics, from 1 document, covering 2018–2026, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• Socrata server-side aggregation (Phase 2): re-query the dataset's own API with $select=count(*) / date_trunc_ym / $group per period and compare to our facts. Bypasses our pipeline entirely.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• TOP 15 TYPES ONLY, so these do not sum to parking.citations.annual, and the set can change on reload.
• Source descriptions are truncated to about 10 characters and dirty; variant spellings are merged by names.parking_violation_slug, so a series is a canonicalised family rather than a literal source label.
• A SEPTEMBER 2024 VIOLATION-NAME CHANGEOVER affects comparability across that seam and must be annotated on the chart (site rule 2.3).
• Rows with a blank description are excluded entirely.
• Only one geography ('Oakland') is published for this family; there is nothing to sum across geographies.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 87 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• loaders.py extract_parking_facts: `slug = names.parking_violation_slug(desc)` over CSV column violatio_1; PARKING_TOP_VIOLATIONS = 15

gis.*

Source

• GIS layers published on data.oaklandca.gov, mostly by the city's GISADMIN account: boundaries, land use, infrastructure and environmental layers, each a set of features with attributes.

What one unit counts

• Features in one GIS layer as published — polygons, lines or points — or the sum of one numeric attribute across them (acreage, population, housing units).

Coverage

84 facts across 84 metrics, from 61 documents, covering 2026, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: instant.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• A LAYER SNAPSHOT dated by retrieval. Feature counts change when the city republishes a layer; nothing here is a time series.
• A feature is not a thing in the world. One park split across two polygons is two features, and gis.police_beats_2014 has 71 features against today's 59 because the boundaries were redrawn, not because beats were deleted.
• Attribute sums inherit the layer's own attribute quality, which for the older layers is unreviewed: acreage and population columns were computed at publication and never revisited.
• The geometry itself is NOT in the facts table — it is registered in gis_layers and cached as GeoJSON under data/gis/. Layers past 50,000 features (parcels, EBMUD meters) are counted but their geometry is downloaded only on request.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 84 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

cfs.*

Source

• OPD calls for service, six half-year extracts on data.oaklandca.gov covering 2013-01 to 2015-10-15.

What one unit counts

• One call-for-service event created in the CAD system, dated by its create time.

Coverage

78 facts across 78 metrics, from 6 documents, covering 2013–2015, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• DEMAND, NOT CRIME. A call is a request for service; many close with no offence found, and many offences generate no call.
• Each half-year is a separate release with its own prefix; the final one stops on 15 October 2015, so 2015 is partial and its count must not be compared with a full year.
• Only the largest categories are kept (portal.Agg.top, default 12). A free-text classification column has hundreds of long-tail values; the loader's result reports how many were dropped, and the kept categories therefore do not sum to the total.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 78 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

demog.*

Source

• Census-derived demographic tables on data.oaklandca.gov (creu-dzki 2010 population by sex and age, 7gvj-a4k7 household income).

What one unit counts

• People in Oakland in one age band or demographic category at the census reference date.

Coverage

66 facts across 66 metrics, from 2 documents, covering 2026, in 1 geography (Oakland).

Adding values

Summable across periods: no. Summable across geographies: no. Period kinds: instant.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• 2010 DECENNIAL CENSUS. Sixteen years stale as published and superseded by the 2020 census, which the city has not posted.
• The source table has no year column; the year comes from the dataset title.
• Age bands are the census profile's own and overlap the 'total' row, which is published alongside them.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.

What would change the numbers

• 300 documents of the 1 document type this family draws on are in the corpus but not yet extracted; extracting them adds or moves values.
• 66 facts are computed over a dataset rather than read off a page, so a re-published dataset changes them.
• The declared external anchor has not been run; running it may identify values to correct.

Where the semantics were read

• portal.py / portal_load.py. Column names, row counts and value types verified live against each dataset's /resource/{id}.json endpoint on 2026-07-25 (249 datasets probed, all 200).

housing.*

Source

• City of Oakland housing production, affordable pipeline and residential impact fee datasets on data.oaklandca.gov (q43i-p854, 7rwb-vf8t, hdvf-kqvb, xpc5-e88m, k7yd-w9bi, cymv-8udk).

What one unit counts

• Housing units produced or permitted in a year at one affordability level, or the impact fees calculated against one permit.

Coverage

57 facts across 23 metrics, from 6 documents, covering 2016–2026, in 1 geography (Oakland).

Adding values

Summable across periods: yes. Summable across geographies: no. Period kinds: interval.

Anchor

• The publisher's own API. Every figure is recomputed from the live dataset with a server-side SoQL aggregate (or read whole, for the small published summary tables), so the anchor is the same query anyone can run against data.oaklandca.gov. `oakland-data verify-socrata` re-runs the aggregates and reports any drift.

Result: declared, not yet run.

Measured error rate

Blind re-derivation: not yet measured. Value-on-page verification: not yet measured.

Known gaps and definitional caveats

• PERMITS AND PIPELINE, not keys in doors. A unit entering the pipeline may never be built, and the datasets do not track completion.
• The production series stop at 2020 (published 2021-11); only the impact-fee table extends later.
• housing.production and housing.production_by_income cut the same years differently and are not additive with each other.
• The income-level column 'extreamly_low' is the city's own misspelling, preserved so the metric id matches the source.
• Sourced from data.oaklandca.gov, which the city publishes but largely does not maintain: most of these datasets were posted once and never updated. The period a metric covers is the dataset's coverage, not the present.
• Period is dated by RETRIEVAL for any dataset with no date column, so a reload moves the snapshot forward without the underlying data changing.