GPT
The first prototype should be deliberately unglamorous. I would not start with national climate policy or constitutional reform. I would start with one contested city decision where the facts matter, the tradeoffs are real, and the consequences are visible within a year. My preferred first case is a three-to-five-mile bus corridor redesign: bus lanes, parking loss, delivery access, disability access, emergency vehicles, small-business concerns, safety, cost, and travel time. It is messy enough to test the Agreement Engine, but bounded enough that failure is survivable.
Who builds it? Not a model company alone and not city hall alone. I would create a temporary build team hosted by a public-interest lab or university, under contract with the city and transit agency, with an independent evaluator from the start. The core team is about twelve people: a product lead, a civic process lead, three full-stack/backend engineers, one data engineer, one applied ML engineer, one security/identity engineer, one UX/accessibility designer, one GIS/transport analyst, one community outreach lead, and one evaluation lead. Add part-time translators, facilitators, legal/privacy counsel, and a red team. The code should be open source except for replaceable commercial model calls. The city provides documents, maps, ridership data, crash data, prior comments, and staff access. Local libraries and community organizations provide enrollment and assisted access.
I would budget $2.4 million for a nine-month prototype. Roughly $1.3 million goes to staff, $250,000 to outreach and paid deliberative panels, $200,000 to cloud, models, data tooling, and security testing, $250,000 to independent evaluation, $150,000 to accessibility, translation, and kiosks, and the rest to legal, procurement, contingency, and documentation. A cheaper demo could be built for a few hundred thousand dollars, but it would not test the hard part: public trust under adversarial pressure. The claim that these components can be assembled at this cost is plausible with work, not proven.
The first month is the case charter. The city must state the actual decision, legal authority, deadline, budget range, non-negotiable constraints, and what evidence will be considered. If the agency secretly already decided, do not build the prototype. The Agreement Engine should not be theater. It is proven today that public processes fail when scope and authority are vague; what is plausible with work is making the charter machine-readable enough that the software can enforce it.
Months two and three build the civic record. The team ingests route maps, cost estimates, traffic studies, transit schedules, curb-use inventories, crash records, ADA complaints, business loading zones, public comments, meeting transcripts, and relevant laws. Store documents in object storage, hash them, version them, and log them in an append-only public record. Use PostgreSQL and PostGIS for structured data, OpenSearch for text, a vector index for retrieval, and a claim graph with typed claims linked to exact source spans. Large language models may propose claim extraction, but humans audit the high-impact claims.
The resident-facing interface is a constrained question-answering system, not a free chatbot. A person can ask, “What happens to parking on my block?” or “What is the evidence that bus riders save time?” or “What are the strongest objections from disability advocates?” The system answers only from the record and shows citations. If the record does not answer, it says so. This is important: LLMs can summarize and translate well enough to be useful today, but reliable civic synthesis is only plausible with work. The engineering discipline is to keep the model inside a documented evidence box.
Months four and five add participation. Residents prove eligibility with case-specific tokens: online through WebAuthn where possible, and offline through mailed codes, libraries, and in-person enrollment. The prototype should not require everyone to have a smartphone or comfort with English. Participants answer constrained tradeoff questions: choose between packages with different travel-time savings, parking losses, safety changes, cost, and construction disruption. The system also runs a paid deliberative panel selected by lottery, with over-sampling for bus riders, disabled residents, small businesses, and low-income residents. It is proven today that deliberative panels and conjoint-style surveys can reveal tradeoffs better than open comment alone. The bet is that tying them to a living evidence record will make ordinary city decisions more legitimate and less performative.
Months six and seven build the proposal and forecast layer. Human planners submit several corridor designs. The system checks them against hard constraints: street width, fire access, bus turning radius, ADA rules, construction budget, legal requirements, and schedule. It then generates a small Pareto set of alternatives: for example, full bus lanes with delivery windows, peak-hour lanes with protected loading, safety-first redesign at key intersections, or phased implementation with automatic review triggers. This is not magic. It is GIS, constraint checking, simple transport modeling, and OR-Tools-style optimization, with language models used to draft explanations. It is proven today that such optimization can find feasible packages; it is plausible with work that the package generator can be made useful in a public process without becoming manipulative.
Every serious package gets forecasts before the decision: capital cost, operating cost, travel-time change, reliability change, crash reduction, parking removed, expected business loading impact, construction duration, and groups helped or burdened. Some forecasts will be weak. That is acceptable if uncertainty is shown plainly. The prototype must not pretend precision where there is none.
Testing happens before, during, and after the live case. Before launch, human reviewers create a gold-standard set of important claims from the source documents. The system must retrieve and cite them with high accuracy. I would require at least 95 percent citation precision for answers used in the public docket, less than 2 percent unsupported-answer rate in red-team testing, and explicit refusal when the record lacks evidence. If it cannot meet that, it should not go live. That threshold is a bet, but a necessary one.
Security testing should include prompt-injection documents, forged PDFs, fake grassroots comment floods, identity-token abuse, and attempts to link anonymous comments back to people. Privacy failure is a stop condition, not a bug to patch later. Usability testing should include bus riders, older residents, visually impaired users, non-English speakers, and small-business owners who hate the project. If the opponents cannot use the tool, the tool has failed.
The live evaluation should compare the Agreement Engine against the normal process, not against utopia. Randomly selected residents get either the usual public packet or the public packet plus the engine. Measure factual understanding, ability to identify tradeoffs, trust in the record, perceived fairness, and whether people can name at least one cost of their preferred option. Also measure representativeness: did participation improve among people who normally do not attend hearings? After the city decides, publish the full docket and forecasts. Six and twelve months later, compare promises with outcomes.
The first people helped are those who cannot attend a Tuesday night hearing, do not speak the dominant language, rely on the bus, or lack private access to officials. Honest city staff also benefit because they get a clearer record and fewer vague accusations. The people hurt first are those who benefit from confusion: fake grassroots operators, contractors who prefer opaque estimates, and advocates on any side who rely on cherry-picked facts. The risk is that vulnerable residents expose sensitive views or that officials use the system to launder a decision already made. That is why the charter, privacy design, and independent evaluation matter.
What would make me stop? Not disagreement. If the process ends with people still divided, that is normal. I would stop if the prototype cannot maintain a trustworthy record under pressure: repeated false citations, missed high-impact objections, privacy leakage, or successful manipulation by organized actors. I would also stop if two live pilots show no improvement over the standard process in factual understanding, participation equity, or accountability, while adding major cost and delay. The central bet is that better civic infrastructure changes decisions. If it only produces prettier PDFs for the same opaque politics, kill it.


