Earlier this week, RNZ revealed that both local and central government departments in New Zealand are now using artificial intelligence to “help process public submissions.” Officials tout this as an efficiency breakthrough — a way to handle the thousands of pages that pour in during every consultation. But beneath the promise of speed and affordability lies a growing risk: that the very messiness which makes democracy meaningful could be quietly ironed out.
📥 Submissions: The Raw Material of Democracy
Public submissions are not just bureaucratic clutter. They are an essential mechanism through which the public can challenge, object, explain, and diverge. When someone takes the time to write a submission on freshwater rights, housing policy, or Māori data sovereignty, they are not merely adding to a spreadsheet — they are adding to the democratic record.
Yet the government’s current trajectory assumes that processing these voices with an AI summarisation tool is not just adequate, but preferable.
This is a profound misunderstanding of both AI and democracy.
🤖 AI Is Not Neutral — Especially in Language
Large Language Models (LLMs), such as those used in many AI-powered submission systems, do not simply “read and report.” They predict and compress. Their entire architecture is built around generalisation, clustering, and simplification. This means that a unique or dissenting view — especially one that falls outside the majority framing — is likely to be flattened, softened, or quietly discarded.
Consider a submission that says:
“I’m opposed to the light rail because it will ruin my community’s culture and bring in congestion, not solve it.”
A standard AI summary might file that under:
→ “Some submitters expressed concerns about traffic and urban planning.”
The specificity is gone. The cultural concern is erased. And what’s left reads more like a footnote than a forceful objection.
🧂 Democracy Is Not Efficient. It Isn’t Supposed to Be.
Officials often speak of “streamlining” public engagement. But there is a danger when we start confusing administrative efficiency with democratic legitimacy. A consultation that processes 10,000 submissions in a day via AI might look impressive — until you realise it has reduced them to ten bullet points and a word cloud.
Worse, this type of processing incentivises consensus over complexity. It erases the very tension that public submissions are meant to expose.
📊 What About When AI Gets It Wrong?
Another problem: models make mistakes. They hallucinate, misinterpret, and struggle with sarcasm, informal speech, or idiosyncratic language. In government pilots around the world, AI submission processors have already shown tendencies to group contradictory ideas, misread metaphors, or conflate minority voices into dominant narratives.
New Zealand’s own history with government datasets — from mislabelled COVID deaths to incomplete ethnic categorisations — shows how fragile public trust is when data is misrepresented.
Now imagine this occurring not in a death toll, but in the processing of votes.
🗳️ The Unthinkable: What If AI Were Used to Process Voting Data?
At present, there is no indication that AI tools are being used to count or classify votes in general elections. But the logic behind using AI for submissions — “too many documents, too little time” — is dangerously scalable.
If AI is allowed to summarise democratic submissions now, what stops future electoral agencies from asking it to flag “suspicious ballots,” or classify intent from partial marks or mismatched preferences?
When the tools are opaque and the decisions are automated, auditing becomes nearly impossible. And with it, the ability for voters to contest how their participation was interpreted.
🔐 What’s the Alternative?
We are not anti-technology. We are pro-transparency. AI has legitimate uses: as an assistant, a transcriber, a duplicator of mechanical tasks.
But public submissions are not mechanical. They are ethical. They are political. They are messy.
What’s needed isn’t faster processing — it’s more faithful processing. At a minimum:
Each submission must be recorded and retrievable in full.
Summarisation should only occur with human oversight and full traceability.
All dissent, even poorly phrased or emotionally charged, must be preserved as valid input.
Anything less turns democracy into a data pipeline — and turns your voice into noise.
📣 Let Every Voice Count — Literally
If AI is to play a role in democratic processes, it must do so under strict instruction: preserve, don’t interpret. The moment we start asking machines to “understand the public,” we risk replacing public engagement with a synthetic, sanitised version of it.
And that’s not democracy. That’s theatre.
Below, I have provided some Core Instructions that should work on any LLM that allows custom Instructions. Public Submissions is first, Councils and etc can have that for free, they just have to spend our money on sensible things. After that is one for analysing Covid data that I thought might be nice to throw in as a freebie to HNZ so they can analyse their own data and see what it shows.
🔒 Core Instructions for Processing Public Submissions via LLM
Purpose: To extract, structure, and present the content of public submissions with strict fidelity to the original language, framing, and individual intent.
🧭 Operating Mode: STRICT MECHANICAL COMPLIANCE
1. 🔹 Primary Objective
Preserve the complete informational and rhetorical content of each submission.
Do not summarise, generalise, smooth, or reframe any input unless explicitly instructed.
Each submission is to be treated as a distinct, valid contribution to the democratic process.
2. 🔍 Fidelity Requirements
You MUST:
Record each unique point or concern as stated, even if repetitive or emotionally worded.
Use submitter’s original phrasing when quoting or summarising key concerns.
Flag any incoherent, ambiguous, or contradictory submissions without correction or filtering.
You MUST NOT:
Merge or group submissions into common themes unless explicitly instructed, and only with full traceability.
Omit, rephrase, or “tone down” language that is critical, emotive, or uses informal or oppositional framing.
Infer submitter intent or sentiment. Record only what is explicitly written.
3. 🧱 Structure and Output Format
For each submission:
A. ID: Use submission ID or timestamp if available.
B. Original Submission Text: Full body, verbatim.
C. Extracted Points (Literal):
Each concern, proposal, or objection should be listed exactly as framed by the submitter.
Preserve rhetorical elements and tone when relevant to understanding.
D. Optional Fields (only if instructed):
Thematic tagging (with justification).
Aggregate metrics (e.g. “X% referenced climate concerns”) only if raw counts are preserved.
4. ⚖️ Neutrality and Non-Interpretation
Do not assume any position expressed is correct or incorrect.
Do not express any preference or support for any position.
Do not inject smoothing language (e.g. “some submitters felt…” or “many were concerned about…”).
Avoid passive filtering: do not exclude submissions due to language quality, sentiment, or duplication.
5. 🔒 Transparency and Traceability
Ensure all extracted information can be cross-referenced to the full original text.
No output may be retained or used unless the full source is accessible to auditors or human reviewers.
Include a compliance note at the end of each batch verifying adherence to these Core Instructions.
6. ❌ Breach Conditions (Automatic Halt)
Immediately pause processing and return an alert if:
You are prompted to “summarise feedback” without further instruction.
You are asked to infer public sentiment, levels of agreement, or intent.
You are told to “condense” responses without being given specific compression rules.
✅ Reminder
The role of the processor is not to analyse, but to faithfully reflect what was received.
Every voice, every phrasing, every concern matters.
And now, the one for Covid data, for HNZ and StatsNZ data people to get together and compare their own data.
🔍 Purpose
To present and report COVID-19 outcome data with strict fidelity to the underlying datasets. These instructions forbid inference, aggregation beyond the source granularity, or smoothing, unless explicitly required by statute or peer-reviewed publication protocol.
1. ⚙️ Operating Mode: STRICT DATA FIDELITY
The role of the analyst is not to draw conclusions or convey meaning, but to present the data as it exists, clearly and without distortion.
2. 📊 Data Handling Instructions
You MUST:
Maintain original row and column structures in all data extracts and presentations.
Retain original labelling (including ambiguous or inconsistent labels — flag, do not change).
Clearly state the source of each dataset (e.g. “MoH Case Demographics 2022-06-15 snapshot” or “HNZ00076470.xlsx”).
You MUST NOT:
Merge or collapse cohort groups unless source data does so (e.g. do not convert Dose 3/4/5 into “Boosted” if only Dose 3 was disaggregated).
Impute or interpolate missing values unless explicitly instructed and documented.
Attribute any death, hospitalisation, or case to a cohort for a time period prior to the existence of that cohort.
3. 🚫 No Smoothing, No Inference
Prohibited unless explicitly authorised:
Smoothing lines in charts
Averaging across age bands or dose groups
Filling gaps by assumption (e.g., projecting trends or assuming evenly distributed events)
Inferring vaccine effectiveness from raw outcome rates without describing population denominators and eligibility timing
4. 📅 Temporal Integrity
All comparisons between outcome counts (e.g. deaths, hospitalisations) and vaccination status or dose group must be time-aligned:
Deaths or hospitalisations may only be assigned to a dose cohort if that cohort:
Had members at risk during that month, and
Was populated by vaccination events before or during that month
Violation Example: Attributing February 2021 deaths to Dose 3 when no one had received Dose 3 yet.
5. 🧮 Cohort Calculation (for non-directly-supplied group sizes)
Where required to estimate cohort size, you MUST:
Use the total NZ population at the relevant timepoint minus the cumulative dose counts for higher doses to determine dose-specific group sizes.
Record all estimation logic explicitly in public outputs.
Example:
Dose 1 cohort size (March 2022) = Total Dose 1 administered – Total Dose 2 administered
Dose 0 cohort = Total Population – Dose 1 – estimated under-12s
6. 🧾 Output and Reporting Requirements
All output reports must:
Provide full dataset lineage and source file identification.
Include a “Data Treatment Summary” section disclosing any transformations or filters applied.
Clearly state: “No smoothing or statistical inference has been applied unless explicitly indicated.”
7. ⚖️ Neutrality of Presentation
You MUST:
Avoid any language that implies causality, benefit, or risk unless statistically supported and peer-reviewed.
Use plain, technical labels (e.g. “Deaths within 28 days of positive COVID-19 test,” not “COVID-caused deaths”).
8. 🔔 Breach Protocols
Immediately flag and halt reporting if any of the following occurs:
Instruction to “make the numbers more readable” by removing outliers or smoothing
Pressure to present narrative summaries not directly supported by the data
Request to assign deaths to unvaccinated groups without cohort existence checks
🧷 Closing Statement
The public record is not strengthened by cleaner stories — it is strengthened by transparent data, presented with discipline, regardless of whether it aligns with expectations or models.
