Civic Tech Chat

Ryan Koch

Civic Tech Chat is a podcast about the civic technology movement. We seek to harness the power technology has to improve the delivery of public services to people everywhere.

  1. 2d ago

    Six Weeks to Launch: How Nava built Document AI in response to H.R. 1

    Summary When H.R. 1 put new pressure on states to cut SNAP payment error rates, Nava PBC had six weeks to help Pennsylvania stand up a way to catch bad document uploads before they reached a caseworker. That rapid-response build became Document AI, an open-source service that checks whether an uploaded document is legible and the right type, then extracts key fields for review. Product manager Sophia Philip and senior software engineer Laurence Goolsby of Nava Labs join Ryan to talk about the project, which has since been adapted for a Maryland pilot that's set to scale statewide by December. They cover: - Why the tool is deliberately kept out of eligibility decisions, with no policy coded into it- How applicants can opt in, opt out, or proceed anyway when a document is flagged- How it handles gig-work and handwritten invoices, plus Spanish-language documents- Why a confidence score is not the same as accuracy- How they're approaching AWS dependence and data security- How other agencies can fork the repo and adapt it to their own needs This episode is sponsored by Nava PBC. Keywords Document AI, intelligent document processing, Nava PBC, Nava Labs, open source, SNAP, H.R. 1, payment error rates, Maryland, Pennsylvania, benefits delivery, administrative burden, human-in-the-loop, consent, Amazon Bedrock, government technology, civic tech Key Topics - How AI-assisted prototyping ("demos over memos") is changing collaboration between product and engineering- Document processing as a shared problem across benefits, licensing, permits, and more- Building a six-week rapid response to H.R. 1 in Pennsylvania, then adapting it for Maryland- Why open source: avoiding vendor lock-in while keeping PII inside each agency's environment- The three users: applicants, caseworkers, and the people who administer the service- Consent that is plain-language, just-in-time, and reversible- Supporting nonstandard documents like handwritten invoices from gig and informal work- Guarding against caseworker over-reliance: confidence scores, and no determinations made by the tool- Under the hood: Amazon Bedrock and Bedrock Data Automation, plain-language document schemas, and Textract- Meeting states on the infrastructure they already use, and the path to being cloud-agnostic- Security by default: data that never leaves the agency, and extracted values that aren't returned unless requested- How to contribute, deploy, or request demo access Sound Bites - "Confidence does not mean accuracy."- "Fundamentals are the building blocks of fun."- "Document AI isn't making any decisions about whether the document should be uploaded. That lives with the person who's uploading it."- "It's not the person who uploads it's fault that we haven't defined it."- "You are not in a vacuum." Chapters 00:00 Intro  00:21 Meet Sophia Philip and Laurence Goolsby of Nava Labs  00:49 Their personal "why"  02:16 What's changed, and what hasn't, in product management and engineering  05:59 How AI prototyping changes collaboration across practices  08:33 Why document processing is a problem worth solving  12:38 Designing around burdens imposed by policy, and building reversible consent  15:15 What is Document AI?  16:26 Origin story: a six-week rapid response to H.R. 1 in Pennsylvania  20:10 Did it move payment error rates?  21:21 What "open source" means here, and why it matters  24:25 The three user personas  26:23 The applicant experience and opt-out fallback  28:41 The caseworker experience, gig-work invoices, and multilingual documents  33:26 Avoiding rubber-stamping: human-in-the-loop and no automated determinations  37:36 Shaping the product vision, from Postman demos to a management layer  41:32 Handling surprises: agile delivery and the Maryland pilot timeline  46:04 Under the hood: how Document AI uses AI  50:12 Why confidence isn't accuracy  51:13 Unsupported languages and undefined document types  54:07 AWS dependence and the path to cloud-agnostic  58:39 Security, privacy, and keeping data inside the agency  1:01:37 Governing Document AI after adoption  1:02:26 How to contribute  1:04:10 Final takeaways Links - Document AI open-source GitHub repository- Nava demo day

    Six Weeks to Launch: How Nava built Document AI in response to H.R. 1
  2. Sep 10

    Proudly Serving: Writing a Book in the Open

    Rebecca Woodbury and Luke Fretwell discuss their collaborative process in writing 'Proudly Serving,' a book aimed at making civic tech and government more accessible, responsive, and effective. They share insights on open source principles, the importance of plain language, and fostering a culture of transparency and public service. The Book: https://proudlyservingbook.com Key Topics The origin story of civic tech and government responsivenessThe collaborative process of writing 'Proudly Serving' with over thirty contributorsThe importance of working in the open and transparency in government projectsThe role of plain language in improving government communicationThe concept of everyone being a public servant and fostering collective responsibilityThe challenges and lessons learned in remote, asynchronous collaborationThe significance of guiding principles and shared values in public organizationsStrategies for balancing innovation with accountability in civic techChapters  00:00 Introduction to Civic Tech and Public Service00:22 Rebecca's Origin Story in Civic Tech04:04 Luke's Path to Civic Tech and Digital Government07:06 Personal Why: Making Government Better08:03 The Inspiration Behind 'Proudly Serving'12:29 Target Audience for the Book16:05 Writing the Book Like an Open Source Project19:23 Collaborative Process and Contributor Engagement23:40 Design and Accessibility in the Book26:45 Working Remotely and Asynchronously33:57 Chapter Review and Quality Gates40:12 Reflections on Personal Challenges and Growth42:14 Plain Language and Clear Communication47:31 Everyone as a Public Servant55:36 Living Up to the 'Why' in Civic Tech01:00:37 Key Message: Default to Open and Say Yes01:02:51 How to Access the Book and Final Thoughts

    Proudly Serving: Writing a Book in the Open
  3. Aug 13

    AI Governance: Who's Accountable When the Machine Decides?

    AI tools have quietly moved out of isolated dev environments and into the middle of how real work gets done. That shift is genuinely exciting, and it brings a fresh set of risks worth sitting with. In this solo episode, Ryan works through what it takes to govern AI well, all of it anchored on one idea he keeps coming back to: a human has to stay accountable for the decisions that matter. He gets into why AI strains the governance habits IT already leans on, how to weigh centralized, decentralized, and hybrid approaches against your own risk tolerance, what ISO 42001 and the NIST AI RMF actually ask of you, and where the law is heading. He closes with a practical playbook for pulling shadow AI into the open while keeping the room for creativity that made folks reach for these tools in the first place. In this episode Why AI puts pressure on the governance habits IT already has, from non-determinism to data drift and concept drift, and the blind spots those quietly createSplitting your governance model (who holds the decision rights) from your operating model (how the work actually gets run)The three big archetypes: the fortress-style centralized model, the fast and messy decentralized model, and the hybrid in between, plus how to match one to your risk tolerance and threat modelA few examples from Ryan's own teams — engineers getting their bearings in old repos in about twenty minutes instead of a full day, designers prototyping fast enough to have a richer discovery conversationWhat ISO 42001 and the NIST AI Risk Management Framework actually require, including named human owners and a real kill switchThe principle the whole episode hangs on: an AI tool can't be the one held accountable, since a machine isn't a legal or moral agentWhere regulation is going, including EU GDPR Article 22, California's coming CCPA automated-decision rules, EU NIS2, and a White House executive order on AI and national securityThe frontier-developer laws worth knowing about even if they never regulate you directlyWhy these efforts stall out, and a grounded playbook: sanctioned tools folks will actually use, a living AI inventory, cross-functional discovery, and metrics anchored in real valueKey takeaways Lower the barrier to secure tools so people stop quietly routing around youKeep a human clearly accountable on every RACI chartGet real value to real people fast, then learn from how they actually use the toolsTreat the AI in your stack as something to govern, not just something you installedResources and shoutouts ISO/IEC 42001, the AI management system standardNIST AI Risk Management FrameworkEU GDPR, Article 22 (solely automated decisions)California's CCPA automated decision-making technology (ADMT) rules, enforced by the CPPA, in effect Jan 1, 2027EU NIS2 DirectiveCalifornia's frontier-model transparency law, plus the state's AI content-transparency and watermarking rulesThe June 2026 White House executive order on AI and national securityRelated episodes: SpecOps → https://civictech.chat/episodes/the-specops-method AI Readiness with Brian Chidester of Adobe → https://civictech.chat/episodes/what-is-ai-readinessLegacy Lockpicks with David D'Silva of Nava, the one that ran just ahead of this → https://civictech.chat/episodes/legacy-lockpicksMusic credit: Tumbleweeds by Monkey Warhol

    AI Governance: Who's Accountable When the Machine Decides?
5
out of 5
18 Ratings

About

Civic Tech Chat is a podcast about the civic technology movement. We seek to harness the power technology has to improve the delivery of public services to people everywhere.

You Might Also Like