Policy Work Needs a Better Operating Surface

Policy work has a recurring problem: the information all exists, but it is scattered across so many systems that it is hard to use at the speed advocacy usually demands. A bill page tells you one thing. A committee roster tells you another. A district map gives you context but not a workflow. Your notes live somewhere else again, and the outreach draft happens last, under pressure, in a separate document. The facts are public. Assembling them into a next step is the slow part.

I wanted a tool that treated legislative work as a connected process instead of a scavenger hunt. This is an independent Prosocial Coding LLC project, separate from my day job. My years in the domestic violence field shaped how I think about safety, privacy, and the quiet ways software can let people down, and that shows up throughout this tool even though the subject is policy rather than crisis.

That last point is what organizes the build. Policy software rarely fails loudly. It fails quietly. It lets stale data look current. It produces AI text that sounds confident and skips the caveats. It exposes a team's strategy, or leaks a credential through a sloppy boundary between browser and server, or nudges someone into trusting generated language before a human has read it. Those are the failures I built against, because they are the ones nobody notices until they have already cost something. The question I ask before any feature is the same one I would ask of a crisis tool: could this harm someone? Here the harm is quieter, which makes it easier to miss and more important to design for.

What it does

Texas Legislature Tracker is a Vite and React single-page app running on Vercel serverless functions. It uses Supabase for authentication and its PostgreSQL data, OpenStates for legislative data, Texas Legislature RSS feeds for events, TxDOT data for district maps, and Gemini through a server-side proxy for AI-assisted analysis and drafting. The public side lets anyone browse bills, legislators, committees, organizations, session deadlines, events, and a Texas district map. Signing in adds saved workflows, the AI Intel tools, and campaign drafting.

The workflow is built to let you start anywhere, because policy work rarely begins with the facts in order. Sometimes you know the district before you know the official. Sometimes you have the bill number before you know which committee holds it. You can open the map when geography is the way in, click into a district, pull up a legislator, check their committees, move into a bill, read its summary and history, run an analysis, and save a campaign draft, all in one path. The AI Intel area covers core bill analysis, community impact, pathway prediction, stakeholder mapping, meeting and testimony prep, procedural deadlines, amendment review, messaging, opposition analysis, and evidence finding. Every one of those tools is there to assist a person, not to replace the judgment that makes advocacy work.

Who it is for

This is for the people who do policy and advocacy work without a dedicated legislative operations platform behind them: advocates, coalition staff, researchers, public affairs workers, organizers, and small teams. It earns its place for anyone who has to hold three kinds of context at once: what a bill says, who has influence over it, and what their team needs to prepare next. The tool does not make that work easy, and I would not claim it does. What it does is take the drag out of the assembly, so more of a person's time goes to strategy, judgment, and review instead of to clicking between systems.

The safety work

Because the failures here are quiet, the safety work is part of the product rather than a layer on top of it.

Provider keys never touch the browser. The Gemini, OpenStates, Supabase service-role, intake, and sentiment-ingest secrets are all treated as server-only values, so the boundary between client and server stays clean. User-owned records, including profiles, watched and tracked bills, notes, campaigns, prompt versions, and telemetry, are protected by Supabase Row Level Security, so one account cannot reach another's data. External data, internal models, AI requests, telemetry, error envelopes, and map responses are all validated with Zod at the runtime boundaries, so malformed or unexpected data does not quietly flow through. Every AI call requires a signed-in session, passes schema validation, and clears per-user rate limits, tier checks, and atomic daily quota accounting before anything reaches Gemini. AI-rendered HTML runs through DOMPurify, and a recursive redaction pass strips personal information before any audit log, telemetry record, or intake payload is written.

One control comes straight from the domestic violence field. A Quick Exit button signs the user out, clears local and session storage, removes legacy watched-bill data, and sends them to a neutral site, and it can be triggered by pressing Escape three times. Advocacy work can be sensitive, and the person doing it is not always safe in the room they are in. That feature exists because I have spent time around people for whom a fast, total exit is not a nicety.

The system is also built to fail closed when its data cannot be trusted. Health and freshness endpoints check Supabase, OpenStates, Gemini, the RSS sources, cache availability, and the age of the data, so a release can refuse to claim readiness when a key dependency is unhealthy or stale. The district map uses a circuit breaker with retries and falls back to bundled map data when the live TxDOT source fails, so the geography does not simply vanish in the middle of a task. And the release checklist is itself a gate: validation, tests, build checks, Playwright smoke checks, secret scanning, circular-dependency checks, bundle-budget checks, and a dependency audit all have to produce evidence before anyone calls a build ready.

What it does not prove

The safety work is real, and real controls are not the same as a finished product. The README and runbooks are explicit that this should not be called production-ready or demo-ready until the exact release commit shows green CI, a green deployment, dependency-audit evidence, and live health and data-freshness checks. The repo is also clear that coverage thresholds are not currently passing, and I am not going to call coverage a strength when it is not. A tool for advocacy work has no business overstating its own reliability. If the data is stale, the user should know. If the AI layer goes down, the core legislative workflow should still stand. If a path has not been verified, it should not be presented as ready.

Where it is going

The remaining work is part technical and part practical. The architecture notes point toward a possible move to a Next.js hybrid, TanStack Query, consolidated route handlers, server components, stronger loading and error states, richer observability, and wider test coverage. None of it touches the core, which was built to extend rather than to be redone.

The nearer-term priorities are clearer onboarding for institutional users, stronger release evidence, better live data-freshness checks, improved AI review controls, and a smoother handoff from bill analysis to campaign drafting.

What I want from Texas Legislature Tracker is for small policy teams to feel less buried by the mechanics of the work. I want it to help someone answer the basic questions faster: what is this bill, who is connected to it, what district or committee context matters, and what should we prepare next. It is not built to replace expertise. It is built to give expertise a better surface to work on. Good advocacy still depends on people, on judgment and timing and coalition strategy and review, and software should respect that. This is the tool I wished more advocacy teams had, and it is ready for the teams carrying that work.