The data in this repository relate to risk-limiting audits. Initially it includes data from the statewide ballot-level comparison RLAs in Colorado, starting in 2017, as described at The Colorado Risk-Limiting Audit Project (CORLA) and related work
The initial scope includes data published in Colorado's Audit Center, based on the data exported from the ColoradoRLA software. That software was originally developed by Free & Fair under contract with the Colorado Department of State. The format of the data for 2017 is described at ColoradoRLA/26_export_manual.md.
The format has changed somewhat over time, as generated by subsequent versions of the software, which have been shared at democracyworks/ColoradoRLA and cdos-rla/colorado-rla.
Independent observers are working with the Department of State to post public, independently-verifiable timestamps of the audit data before each audit's random seed is generated, so that observers can confirm the data was locked in place before the dice roll. See evidence-timestamping.md for why this matters and how it's done, and 2026/primary/observerfiles/2026-primary-details.md for the specific commitments made for the 2026 primary.
Note: the pages this mirror was originally scraped from for elections prior to the 2026 primary (2017 through 2025) now return 404 on the live Secretary of State site — as of 2026-07-13, only the current election's Audit Center pages are live. The files here for those earlier years aren't so much stale as orphaned: the original source is simply gone, and they can no longer be checked against a live copy.
Known gap: point-in-time snapshots, not continuous versioning. This mirror is built by periodically scraping what the Secretary of State's Audit Center (and, for some files, individual counties directly) had published at the time of each scrape — it is not a continuous capture of every version of every file. Some files, ballot manifests in particular, can be revised more than once during an active audit cycle as errors are found and corrected; if a file changed between scrapes, this mirror may hold only one snapshot of it, and that snapshot isn't guaranteed to be the first version, the last version, or the corrected one.
This isn't just a sampling-interval limitation — the scraper's own default behavior
compounds it. By default it leaves a file alone once a local copy already exists,
rather than re-fetching and diffing it on every run (-a recheck=1 forces a real
re-fetch of everything, at the cost of a much slower run). That default made the
common case fast and matched the tool's historical behavior, but it also means a
source file that changed at the Secretary of State's end after our first scrape can
sit unnoticed in this mirror indefinitely, showing its original content long after
the live version was corrected, unless something specifically prompts a recheck=1
run for that file.
We're working to close that gap.