Assurance: The State

Part IV is the course’s third module. It climbs the ladder from the county to the state, and it pairs two professions that have each learned, at real cost, how to tell the public that a system can be trusted: accounting and engineering. This book teaches them together as assurance. Keegan (2026) codes both as lineages of oversight: accounting contributes legible records and independent verification; engineering contributes standards, testing, and incident learning. Together they answer a question the earlier modules raised: when someone says an automated system has been checked, how would you know whether the check was real?

Pressure and value

The pressure is exemption, in a form this module calls audit-washing: verification shaped like oversight but too shallow to constrain anything. An audit scoped by the party being audited, scored against thresholds no one had to justify, and published as a one-page attestation is an exemption that looks like compliance. The value that pushes back is oversight through independent verification, testing, and incident learning: workpapers a stranger can rerun, thresholds fixed in advance by someone with authority, tests that run whenever the code changes, and incident records kept by the people a failure happened to.

Why the state

In the United States, much of the governance of automated decision systems is now written, and bought, by states. The Colorado AI Act (SB 24-205), signed in 2024 and revisited by the legislature since, places duties on developers and deployers of high-risk AI systems, and Colorado’s agencies procure systems that support consequential decisions about residents. Engineering licensure is also a state function.

Cases

National anchor: New York City’s Local Law 144, which requires published bias audits of automated employment decision tools and has become the field’s standard example of audit-washing; and a disaggregated audit of a model trained on Colorado data from the American Community Survey, built with folktables and fairlearn.
Non-US counter-cases: the EU AI Act’s conformity assessment regime; Canada’s Directive on Automated Decision-Making and its Algorithmic Impact Assessment, which moves assessment before deployment and publishes the result; and worker observatories such as Worker Info Exchange in the UK, which build counter-records of platform behavior from below (Keegan 2026, Case 2).
State case: the Colorado AI Act and its amendments, and Colorado state procurement of automated decision systems.

The portfolio piece

Piece 3: Assurance / State / Report. You submit:

a technical artifact: a disaggregated audit with manifest, thresholds, changelog, and tests that run in continuous integration;
a public text: a report section for a named Colorado state body (a legislative committee, a state agency, or a state task force), with executive summary, methods, findings, and recommendations, of about 2,000 words;
an installed-base note of about 300 words on the pressure you met, the installed-base elements your artifact built and those still missing, with provenance, license, and an AI-use disclosure; and
for INFO 5871, a graduate methods memo of 750–1,000 words that situates the piece in at least five scholarly sources and defends one methodological choice.

Course weeks

The module runs in Weeks 9, 10, and 12, straddling spring break (Week 11) on purpose: you build and test the audit before the break and write the report after it, finishing in the Week 12 studio.

Roadmap

The part follows the book’s order of pressure, lineage, value, and genre, with pressure and value carried inside the lineage chapters, because audit-washing is a failure of the professions that invented the audit.

12 Accounting and Auditing covers accounting’s public interest mandate, names audit-washing through LL144, and builds the module’s central tutorial: a disaggregated fairlearn audit of a Colorado folktables model, wrapped in a manifest, thresholds, an audit script, and a changelog.
13 Engineering puts that audit under test, introduces a bug that downgrades failures to warnings, writes a post-incident review, runs the suite in continuous integration, and introduces worker observatories as incident learning from below.
14 GovTech and Civic Tech turns to the state as a buyer: five models of digital government, Canada’s Algorithmic Impact Assessment beside Colorado’s Act, and procurement clauses that require vendors to deliver what your audit needs.
15 Reports is the genre chapter: reports that inform versus reports that mobilize, the executive summary, methods transparency, a Quarto report bound to your audit’s output, and Piece 3.

Part V then climbs to the federal level, where the pressure shifts from exemption to erosion.

Keegan, Brian C. 2026. “Public Interest Data Infrastructuring.” Under Review.

# Assurance: The State Part IV is the course's third module. It climbs the ladder from the county to the **state**, and it pairs two professions that have each learned, at real cost, how to tell the public that a system can be trusted: accounting and engineering. This book teaches them together as *assurance*. Keegan [-@keegan2026] codes both as lineages of **oversight**: accounting contributes legible records and independent verification; engineering contributes standards, testing, and incident learning. Together they answer a question the earlier modules raised: when someone says an automated system has been checked, how would you know whether the check was real? ## Pressure and value The pressure is **exemption**, in a form this module calls **audit-washing**: verification shaped like oversight but too shallow to constrain anything. An audit scoped by the party being audited, scored against thresholds no one had to justify, and published as a one-page attestation is an exemption that looks like compliance. The value that pushes back is **oversight** through independent verification, testing, and incident learning: workpapers a stranger can rerun, thresholds fixed in advance by someone with authority, tests that run whenever the code changes, and incident records kept by the people a failure happened to. ## Why the state In the United States, much of the governance of automated decision systems is now written, and bought, by states. The Colorado AI Act (SB 24-205), signed in 2024 and revisited by the legislature since, places duties on developers and deployers of high-risk AI systems, and Colorado's agencies procure systems that support consequential decisions about residents.  Engineering licensure is also a state function. ## Cases - **National anchor:** New York City's Local Law 144, which requires published bias audits of automated employment decision tools and has become the field's standard example of audit-washing; and a disaggregated audit of a model trained on Colorado data from the American Community Survey, built with `folktables` and `fairlearn`. - **Non-US counter-cases:** the EU AI Act's conformity assessment regime; Canada's Directive on Automated Decision-Making and its Algorithmic Impact Assessment, which moves assessment before deployment and publishes the result; and worker observatories such as Worker Info Exchange in the UK, which build counter-records of platform behavior from below [@keegan2026, Case 2]. - **State case:** the Colorado AI Act and its amendments, and Colorado state procurement of automated decision systems. ## The portfolio piece **Piece 3: Assurance / State / Report.** You submit: 1. a **technical artifact**: a disaggregated audit with manifest, thresholds, changelog, and tests that run in continuous integration; 2. a **public text**: a report section for a named Colorado state body (a legislative committee, a state agency, or a state task force), with executive summary, methods, findings, and recommendations, of about 2,000 words; 3. an **installed-base note** of about 300 words on the pressure you met, the installed-base elements your artifact built and those still missing, with provenance, license, and an AI-use disclosure; and 4. for INFO 5871, a **graduate methods memo** of 750–1,000 words that situates the piece in at least five scholarly sources and defends one methodological choice. ## Course weeks The module runs in Weeks 9, 10, and 12, straddling spring break (Week 11) on purpose: you build and test the audit before the break and write the report after it, finishing in the Week 12 studio. ## Roadmap The part follows the book's order of pressure, lineage, value, and genre, with pressure and value carried inside the lineage chapters, because audit-washing is a failure of the professions that invented the audit. - @sec-ch-12-accounting covers accounting's public interest mandate, names audit-washing through LL144, and builds the module's central tutorial: a disaggregated `fairlearn` audit of a Colorado `folktables` model, wrapped in a manifest, thresholds, an audit script, and a changelog. - @sec-ch-13-engineering puts that audit under test, introduces a bug that downgrades failures to warnings, writes a post-incident review, runs the suite in continuous integration, and introduces worker observatories as incident learning from below. - @sec-ch-14-govtech-civic-tech turns to the state as a buyer: five models of digital government, Canada's Algorithmic Impact Assessment beside Colorado's Act, and procurement clauses that require vendors to deliver what your audit needs. - @sec-ch-15-reports is the genre chapter: reports that inform versus reports that mobilize, the executive summary, methods transparency, a Quarto report bound to your audit's output, and Piece 3. Part V then climbs to the federal level, where the pressure shifts from exemption to erosion.