How CivicRelay works

Where the bill data comes from

CivicRelay reads directly from the state legislature's own published data — the bill list, each version's full text, sponsors, committee assignments, hearings, actions and roll-call votes. Nothing is retyped and nothing is scraped from a secondhand aggregator. The official source URL is on every bill, one click away, so you can always check the original.

Data is synced on a schedule through the session, and a bill can also be refreshed on demand. When a new version of a bill is published, it is stored alongside the previous ones rather than replacing them, which is what makes the change history possible.

What the AI actually does

Analysis runs in stages rather than as one request. The bill text is first read for concrete, checkable facts — key provisions, deadlines, penalties, fiscal references, legal obligations, defined terms and the sections of code it amends. Those extracted facts are then synthesised into a plain-English summary of what the bill does, who it affects, and why it matters.

The summary is written for a busy local-government official with no legal training. That is a deliberate constraint: a summary that requires a lawyer to interpret has moved the problem rather than solved it.

How a claim gets checked

Every extracted item has to carry a citation: a verbatim quote from the bill text it came from. That quote is then matched back against the actual text mechanically — not by asking the model whether it was right, which is a question models are bad at.

• If the quote matches the bill text, the item stands and you can see the quote.
• If it doesn't, the item gets one repair attempt.
• If it still doesn't match, the item is dropped. It never reaches you.
• Roughly one in twenty extracted items fails that check and is discarded.

This is the part of the system we would most want a sceptical buyer to interrogate. The failure mode of AI on legal text is fluent, confident invention, and the only durable defence is refusing to display anything that cannot be traced to a specific provision.

When the system isn't sure

Bill Q&A labels every answer with where it came from: stated explicitly in the bill, inferred from what the bill says, or not available in the text at all. You can see when the model is quoting and when it is reasoning, which is the distinction that matters when the answer is going into a council packet.

Impact analysis carries the same discipline. A second pass reviews the first, and points it cannot confirm against the bill text are shown separately as unverified rather than folded into the analysis — because "this bill imposes no such duty" and "we could not confirm whether this duty reaches you" are different answers, and only one of them is safe to ignore.

What it does not do

• It does not give legal advice. It is decision support, and important conclusions should be checked against the official text.
• It does not decide your position. Reviewers answer, departments take a position, and an executive approves — the software records that chain, it does not shortcut it.
• It does not use your data to train AI models.
• It does not cover every state. Utah today, one legislature at a time, because connecting one properly beats claiming fifty.

Why it's built this way

A legislative session is a deadline problem before it is a reading problem. The bills that matter to a city are a small fraction of the thousand filed, but finding them by hand costs more staff time than most organizations have — so in practice they get found late, after a committee hearing has already happened.

Reading everything is the part a machine is genuinely good at. Deciding what your organization's position should be is the part it is not. CivicRelay is drawn along that line on purpose: exhaustive where exhaustiveness is cheap, and deferential to people where judgement is required.