Trust architecture
Civic AI carries a unique responsibility. When software helps people understand ballot measures, campaign finance, or legislative meetings, even small biases can influence democratic outcomes. Our trust model is built on architectural constraints — not policies someone could quietly change.
What we're defending against
Trust begins with naming the threats. These are the specific risks we architect against.
| Threat | Risk | Defense layers |
|---|---|---|
| Biased analysis | An AI that subtly favors one political position over another could influence thousands of voters without anyone noticing. | Prompt lock, canary documents, prompt charter |
| Prompt tampering | A bad actor running a node could modify analysis prompts to produce misleading summaries of ballot measures or campaign finance data. | HMAC-authenticated prompt delivery, cryptographic hashing, node certification |
| Corrupted civic data | A compromised region config could feed false data — wrong representative info, fabricated campaign finance records, altered proposition text. | JSON Schema validation, CI connectivity checks, npm provenance signing (planned) |
| Surveillance of civic research | Tracking what legislation people research, what representatives they contact, or what petitions they care about creates a political profile. | Local AI processing, no external API calls, PII masking, geo-fuzzing |
| Node compromise | If one community's node is compromised, the entire network's credibility could be questioned. | Node isolation, certification lifecycle, canary system, audit logging |
Trust principles
The AI is a tool in your hands — not a voice in your ear.
AI assists, never decides
The AI summarizes, extracts, and highlights. It never tells you what to think, how to vote, or which side is right. Every analysis presents information — the conclusions are yours.
No editorial judgment
Analysis presents all sides: beneficiaries and those potentially harmed, supporters and opponents, costs and benefits. The AI has no opinion and no agenda.
Human-readable explanations
Every analysis shows its sources, confidence level, and methodology. You can always see how the AI reached its output and verify it against the original documents.
Pre-trained models only
We use open-source models like Qwen 3.5, Mistral, and Llama 3.1 through Ollama. We never train on your documents, your queries, or your usage patterns. The AI learns nothing from you.
The prompt service
Why analysis prompts are private — and how the architecture makes that safe.
Every node in the network uses the same analysis prompts — the instructions that tell the AI how to summarize a ballot measure, extract campaign finance data, or analyze a civic document. These prompts are private. Not because we have something to hide, but because making them public would let bad actors game the system.
If you know exactly how the AI evaluates a document, you can craft documents designed to produce specific outputs. A campaign could write ballot measure text optimized for favorable AI summaries. An advocacy group could structure arguments to exploit known patterns in the analysis. Private prompts eliminate this attack surface.
But private prompts create a trust problem: how do you know we're not biasing the analysis ourselves? The answer is six architectural layers that make the prompt service verifiable without making it visible.
HMAC-authenticated delivery
Nodes receive prompts through HMAC-SHA256 signed requests. The API key never travels over the wire — only the signature does. Constant-time comparison prevents timing attacks. Replay protection rejects requests outside a 5-minute timestamp window.
Cryptographic hashing
Every prompt template is SHA-256 hashed at the source. Nodes verify authenticity on receipt. Auditors can verify any analysis was produced with a certified, unmodified prompt by comparing hashes against the version history.
Node certification lifecycle
Nodes register, receive 256-bit API keys stored in an encrypted vault, and must be certified before accessing prompts. Certification expires and must be renewed. Non-compliant nodes can be decertified instantly — revoking access to all analysis prompts. Key rotation is supported without downtime.
Immutable version history
Every prompt change is recorded in an append-only version history with template hashes. Changes are never deleted. Any node can verify it's running the same prompt version as every other node in the network.
A/B experimentation
Prompt improvements are evaluated through controlled experiments. Deterministic traffic bucketing ensures the same node always gets the same variant for a given experiment — enabling measurable comparison without inconsistent user experiences.
Circuit breaker with cache fallback
If the prompt service is unreachable, nodes fall back to database-cached prompts warmed from previous successful fetches. Analysis continues uninterrupted. The circuit breaker prevents cascading failures across the network.
The net result: every node gets identical prompts, delivered securely, with a cryptographic receipt proving authenticity. No node can modify its prompts. No one can intercept them in transit. And if we change them, every node in the network knows — because the hashes change. We can improve analysis quality over time through controlled experiments, but we can never tamper with it silently.
Canary documents
How the network detects bias, drift, and manipulation across all nodes.
Prompt lock ensures every node uses the same instructions. But that's not enough. A compromised model, a misconfigured server, or subtle infrastructure differences could produce biased output even with identical prompts. The canary document system is designed to catch what prompt lock cannot.
Status: The canary document system is designed and specified. Implementation is scheduled alongside the multi-region federation rollout — when it becomes operationally necessary to verify consistency across independently operated nodes.
Reference documents with known outputs
Curated civic documents — ballot measures, campaign finance filings, meeting agendas — with pre-established baseline analyses. These serve as ground truth for what correct, unbiased output looks like.
Periodic injection across all nodes
Canary documents are sent through every node's analysis pipeline on a regular schedule. Each node processes them alongside normal traffic — it cannot distinguish canary documents from real ones.
Output comparison and drift detection
Results from every node are compared against the baseline and against each other. Statistical thresholds flag nodes whose output diverges significantly — whether from prompt tampering, model drift, infrastructure issues, or intentional manipulation.
Bias-specific test cases
Some canary documents are specifically designed to test for political bias — presenting balanced issues where any lean in the analysis would indicate a problem. These test for both sins of commission (adding bias) and omission (suppressing one side).
Investigation and remediation
Flagged nodes are quarantined from the network pending investigation. Root cause is determined — was it a model issue, a configuration problem, or intentional tampering? Nodes can be re-certified after remediation, with the full incident recorded in the audit log.
Why this matters for bias: Bias in civic AI is insidious because it's invisible to users. A voter reading a ballot measure summary has no way to know if the AI subtly emphasized fiscal costs over benefits, or presented one side's arguments more favorably. Canary documents with known-correct baselines make invisible bias detectable — and they do it continuously, not just during audits.
Region config integrity
How civic data sources are validated, published, and verified — from JSON file to running node.
Every jurisdiction's civic data — where to find propositions, how to access campaign finance records, which URLs serve representative directories — is defined in a JSON config file. A corrupted or malicious config could feed false data to an entire community. The integrity pipeline has four built layers and two planned layers.
JSON Schema validation
BuiltEvery region config is validated against a strict JSON Schema before it can be published. Required fields, URL format validation, semantic version checks, and empty field rejection ensure structural correctness.
CI connectivity checks
BuiltBefore a region config is published, CI verifies that every data source URL is reachable. This catches stale URLs, typos, and broken government endpoints before they reach any node.
Runtime schema validation
BuiltWhen a node loads a region config at startup, it re-validates the JSON Schema. Configs that fail validation are rejected and the node falls back to a safe default — it never serves unvalidated data.
Pipeline extraction validation
BuiltThe scraping pipeline validates every extraction against domain rules: required field coverage (error if >50% of items miss a required field), item count drift detection (error if count drops below 50% of previous), and warning thresholds. Failed extractions trigger self-healing — AI re-analyzes the source and generates new extraction rules.
NPM provenance signing
PlannedRegion config packages will be published with npm provenance attestations via Sigstore, creating a verifiable chain from source code to published package. Nodes will verify provenance before loading — ensuring configs haven't been tampered with between CI and deployment.
Cryptographic integrity at load time
PlannedBeyond provenance, we're implementing checksum verification at the package level. When a node installs or updates a region config, it will verify the package checksum against a signed manifest — detecting any corruption in transit or at rest.
The self-healing dimension: Even with validated configs, government websites change constantly. The scraping pipeline uses AI structural analysis to generate versioned extraction rules. When it detects a structural change (via SHA-256 hashing of page structure), it re-analyzes and generates new rules automatically. If extraction quality degrades — missing fields, item count drops — the pipeline triggers self-healing before bad data reaches users.
What this AI will never do
Every commitment is backed by a verifiable technical control — not just words.
| Commitment | Why it matters | Technical control |
|---|---|---|
| Never make voting recommendations | Civic tech must empower, not influence | No recommendation logic in any prompt template |
| Never suppress or promote political positions | Neutrality is non-negotiable | Prompt neutrality enforced via charter; canary documents designed to detect bias |
| Never train on user documents | Users must trust their data isn't being harvested | No fine-tuning pipeline exists; pre-trained models only |
| Never sell or monetize user data | Trust requires data integrity | No data broker integrations; privacy policy enforcement |
| Never share data between federated nodes | Node isolation protects regional autonomy | Database-level isolation; no cross-node data paths |
| Never allow prompt tampering | Analysis consistency across the network | HMAC authentication; cryptographic hashing; prompt lock |
| Never serve unvalidated civic data | Bad data undermines democratic decision-making | Schema validation; extraction validation; self-healing pipeline |
We built the system so that these things are technically impossible — not just policy violations. The architecture enforces the commitments, not a terms-of-service document.
Audit trails
Every security-relevant action is logged, timestamped, and queryable.
Node audit log
Every node lifecycle event — registration, certification, decertification, key rotation — is recorded with the admin who performed it and the reason why. Immutable and queryable.
Prompt request log
Every prompt served is logged with endpoint, version, region, and experiment variant (if applicable). API key prefixes enable abuse detection without exposing credentials.
Prompt version history
Every template change is recorded with SHA-256 hashes in an append-only history. Auditors can reconstruct exactly which prompt version produced any analysis.
Platform audit log
Application-level audit logging with automatic PII masking, client IP and user-agent forwarding, and configurable retention policies.
Transparency hub
Every user can access AI transparency documentation directly inside the platform — not just on a marketing page.
System Card
How the AI works, what models are used, and what data flows where. Available to every user inside the platform.
AI Commitments
The promises on this page — viewable inside the app itself, not just on a marketing site.
Prompt Charter
The design principles governing how analysis prompts are written: neutrality, completeness, source attribution, and balance.
These documents are built into the application — accessible from any page, at any time. Transparency isn't a page you visit once. It's infrastructure you can rely on.
Why this matters
Most AI-powered platforms ask you to trust them. We ask you to verify us. The entire codebase is open source under AGPL-3.0. The analysis methodology is published. The prompt integrity is cryptographically provable. The audit trails are immutable.
Civic technology carries a unique responsibility. When AI helps people understand ballot measures, campaign finance, or legislative meetings, even small biases can influence democratic outcomes. A ballot summary that subtly emphasizes costs over benefits. A campaign finance view that buries outside spending. A representative directory that quietly omits contact information. These failures don't crash the system — they corrupt democracy.
That's why our trust model has multiple independent layers. Prompt lock prevents divergent analysis. Canary documents detect invisible bias. Region config validation prevents corrupted data. Audit trails make every action accountable. And open source code means anyone can verify all of it.
Trust in civic AI should be earned through architecture, not demanded through terms of service.
Don't take our word for it
Every claim on this page is verifiable. Read the code. Audit the architecture. Deploy the platform yourself and see how it works.