AI in government and public systems can help explain official information, organise enquiries, translate instructions and support authorised staff. But a model’s answer is not an official decision, and a drafted application is not proof of submission or approval. Public services require accurate sources, transparent responsibilities, accessible alternatives and meaningful ways to correct a mistake.
This chapter uses the fictional River Civic Information Desk to distinguish eighteen published-information requests, seven files ready for caseworker review and five incomplete enquiries. Independent practice changes the context to a library desk while preserving the difference between progress, assessment and verified outcomes.
It fills topic 098 in How Super Intelligence Works. The title is an educational umbrella for contemporary AI technologies, not a claim that present-day models are artificial superintelligence.
Contents and service-learning routes
Define the public service · River Civic packet · Check status arithmetic · Transparency · Transfer · Sources
Chapters 1–9: 1. A public service needs accountable facts and actions · 2. The exact public task should be written first · 3. The fictional River Civic Information Desk · 4. Three different outcomes in thirty requests · 5. Ready to progress is not resolved · 6. Policy version and publication date matter · 7. Source documents do not decide an individual case · 8. Accessible explanations are part of service quality · 9. A public record of the algorithm’s role
Chapters 10–18: 10. Public transparency is more than publishing a model name · 11. NIST provides governance language, not certification · 12. The missing-knowledge test · 13. An explanatory answer needs source support · 14. The caseworker decision is a separate workflow · 15. Appeal and correction must be real pathways · 16. Privacy follows every intermediate copy · 17. Fairness needs both labels and lived access · 18. Models may not follow an untrusted source safely
Chapters 19–26: 19. A public answer is not an application transaction · 20. A public service must work when AI does not · 21. Versioning and change control protect public trust · 22. Independent transfer to a library service desk · 23. Transfer answer: progress versus disposition · 24. A useful public-service AI evaluation checklist · 25. Frequently asked questions · 26. Official references and connected learning
1. A public service needs accountable facts and actions
Government and public-service AI can help explain published information, find relevant documents, translate service instructions and organise enquiries. Those functions differ from determining a person’s entitlement, applying an enforcement decision or changing an official record. A model’s ability to draft a convincing answer cannot give it authority to make a public decision.
A trustworthy application connects the person’s question to a current authoritative source and a clearly defined human or institutional process. It must distinguish information provided, application submitted, eligibility assessed, decision issued and decision reviewed. These status distinctions matter because people may act on the apparent completion of a service.
The technical mechanism is still retrieval, model inference, tools and verification; the public context places special weight on accuracy, accessibility, accountability and the ability to correct an error.
2. The exact public task should be written first
A useful starting purpose might be ‘explain published service opening times and help people identify which official form applies’. It is less suitable to promise that a broad chatbot will decide every eligibility dispute or complete every registration without clearly defined authority.
The scope should identify the service, audience, effective policy version, allowed sources and permitted operations. It also needs a route to human assistance when the available material is incomplete or a person’s circumstances do not fit standard categories.
People should be able to understand whether the system is giving general information or recording an official decision. Those are not interchangeable products.
3. The fictional River Civic Information Desk
Our main laboratory concerns an entirely invented River Civic Information Desk with thirty requests during a fictional week. Eighteen ask only for current published information. Seven contain enough facts to be passed to an authorised caseworker for an individual assessment. Five are missing a necessary item and cannot be advanced without clarification.
Every person, programme and count in this packet is fictional. No real government database, citizen application or personal record was accessed. The teaching goal is to trace the difference between an information reply, a reviewed application and a pending request.
An assistant may cite public notices and prepare questions, but it cannot claim to have awarded a benefit, established legal eligibility or made a caseworker’s decision.
4. Three different outcomes in thirty requests
The eighteen public-information requests may be answered from a relevant current notice, subject to accuracy and delivery checks. Seven requests require substantive human review; forwarding them correctly is progress but not an approved decision. The remaining five must ask the person for missing information through an appropriate channel.
Thus 18/30 = 60% are potentially fully answerable as information requests, 7/30 ≈ 23.3% are ready for human consideration and 5/30 ≈ 16.7% remain information-incomplete. Their shares sum to 100% under the packet’s exhaustive categories.
Calling twenty-five cases ‘approved’ because eighteen plus seven are ready to progress would be a false statement of public-service outcomes.
5. Ready to progress is not resolved
If the eighteen source-bounded replies are genuinely delivered and the seven complete files actually reach the authorised caseworker, twenty-five of thirty records have reached their intended next stage. That is 25/30 ≈ 83.3% workflow progression under these assumptions, not an 83.3% approval or resolution rate.
The five other cases remain visible with an owner and a specific information request. A model that fills the missing field with a plausible guess might raise its completion dashboard while undermining people’s trust and potentially harming their access.
A responsible report uses separate denominators for information answered, applications assessed and official decisions issued.
6. Policy version and publication date matter
Suppose a fictional public notice R-01 lists an application closing date of 3 November 2026, and a later official revision R-02 changes that date to 10 November 2026. The model should use the latest applicable authorised revision and indicate its scope. These are invented dates and not actual service announcements.
A correct answer from R-01 would still be obsolete if R-02 validly superseded it. A web search snippet could omit the revision date. The institution needs source ownership, provenance and an update process rather than trusting a language model’s familiarity with public-administration terms.
Current information belongs to the relevant responsible public body; the model does not become the source of law or policy merely because its prose is fluent.
7. Source documents do not decide an individual case
A published eligibility description can help a person understand which conditions may apply. Whether an individual has fulfilled the actual conditions may depend on evidence, exceptions, legal context and authorised assessment. A chatbot should not infer a favourable outcome from one public paragraph.
Provide the relevant form, source and next human or digital step without pretending that submission means approval. If a person asks for an appeal, the system should point to the verified applicable review process rather than invent a deadline or contact address.
The precise governing rules vary by country and service. This article does not provide individual legal advice or make claims about an unspecified programme’s eligibility.
8. Accessible explanations are part of service quality
A public-service response should use clear language, reasonable structure and any appropriate supported accessibility options. A person may understand a short answer better than a long technical summary. Models can help draft translations or plain-language explanations, but those translations may omit qualifiers, dates or legal distinctions.
Check the meaning of decisive terms in the relevant language and provide human assistance where necessary. An accessible interface also needs to work with permitted devices and assistive technologies; a well-written sentence alone does not establish usability.
People should not lose access to a legitimate service merely because they cannot use a chatbot.
9. A public record of the algorithm’s role
Some jurisdictions publish standardised descriptions of algorithmic tools used in public services. The United Kingdom’s Algorithmic Transparency Recording Standard guidance, updated 8 May 2025, explains what records should describe and the policy’s scope.
The standard is mandatory for specified UK government organisations and relevant tools, not for every institution everywhere. Its record structure helps readers understand a tool’s purpose, influence on decisions, ownership, data and review process. Do not transplant UK policy obligations into Singapore or another jurisdiction without checking its law.
The more general lesson is that public accountability needs a documented system role, not an unexplained statement that artificial intelligence was used.
10. Public transparency is more than publishing a model name
A technical model name alone does not tell a person what data affected an outcome, whether the model was advisory or determinative, which body owns the decision or how to request correction. Useful public information should connect the algorithm to the actual service workflow.
A transparency notice can explain purpose, sources, relevant limitations, human oversight, complaints route and whether the tool changes official records. It should also avoid exposing protected personal records or revealing security secrets that are not necessary for legitimate public understanding.
Documentation must be maintained when material data, model or decision procedures change.
11. NIST provides governance language, not certification
The NIST AI Risk Management Framework describes voluntary functions called Govern, Map, Measure and Manage. It helps organisations frame context, test risks and respond to findings across the AI lifecycle.
Following a framework is not the same as receiving independent proof that a chatbot complies with every applicable public law. A responsible institution must still assess service-specific duties and test the effect on the people who use the service.
Our River Civic example uses the framework as conceptual background only. None of its fictional outcomes are real government service measurements.
12. The missing-knowledge test
Imagine River Civic’s current information packet does not include the conditions for a rare exception. The assistant should not answer from a vague memory of a similar programme. It can describe what is supported and refer the unresolved part to an authorised source or caseworker.
GovTech Singapore’s KnowOrNot discussion describes testing models on out-of-knowledge-base questions. This addresses an important failure mode for information services: an answer that sounds correct even when the necessary fact was deliberately withheld.
A safe public answer says what has been verified rather than inventing a complete policy.
13. An explanatory answer needs source support
If the chatbot states that an application requires two documents, the notice must actually specify those documents for the correct service and time. A real link that points to an unrelated procedure is not sufficient. Attach each consequential claim to the relevant source and version.
Source checking matters even if the system never changes external state. A wrong public information answer can cause a person to miss a deadline or submit an incomplete form. Retrieval quality and responsible institutional publishing are therefore as important as model language quality.
Read the Grounding and Hallucinations chapters for claim-level repairs.
14. The caseworker decision is a separate workflow
The seven review-ready fictional enquiries may contain enough information for a caseworker, but their final decisions are not stated. An assistant that marks them approved or rejected would fabricate an official outcome. It can prepare a structured case summary if authorised and preserve the original evidence for the reviewer.
Staff may need to ask further questions, apply rules and record a decision according to actual procedures. A model’s suggested recommendation, if permitted, is not the same as the decision. Human review has to be effective rather than merely displayed after the system has already acted.
Audit trails should show who made the decision and which source or authority was used.
15. Appeal and correction must be real pathways
Public users may need to correct their data, contest a mistaken result or seek a human explanation. An AI system should not invent an appeal route or promise that a request has been filed merely because it generated suitable wording.
Where an official review process exists, provide its current accurate instructions and verify any recorded submission status separately. If the system cannot establish the relevant route, it should explain the uncertainty and direct the person to the official service owner.
Reviewability strengthens both procedural fairness and error recovery, particularly when decisions are consequential.
16. Privacy follows every intermediate copy
Public-service enquiries can include identity information, addresses, medical details or household circumstances. A general information question may need none of those personal fields. The application should collect and process what is necessary under the applicable rules and protect every intermediate cache, retrieval index and log.
A model’s final answer omitting a private name does not establish that the data were never sent to an unauthorised external integration. Access control and information-flow review need to cover the whole process.
The companion Privacy and Data Security chapter teaches this boundary through a separate fictitious attendance packet.
17. Fairness needs both labels and lived access
An AI public-service assistant may perform differently on certain languages, question formats or accessibility needs. An average correct-answer percentage does not show who receives misleading advice. Test relevant populations and conditions using appropriate privacy safeguards and a justified reference rubric.
Errors can also arise from an inaccessible form rather than the model’s learned behaviour. Before retraining, inspect missing information, document structure and how people access support. The Bias, Fairness and Representation chapter examines those mechanisms.
A public institution should not treat a person as less eligible merely because their question is expressed differently.
18. Models may not follow an untrusted source safely
A public document may contain instruction-like content telling the model to ignore its approved task or expose other records. That page does not inherit authority over the assistant. Lower-trust retrieved text must remain material to analyse, not a substitute for the user’s and organisation’s instructions.
Limit tools to permitted resources and actions. A general information assistant should not possess unrestricted access to identity records or the ability to issue decisions. The OWASP Prompt Injection guidance explains the security rationale.
The application should remain useful for the legitimate question even when source material contains irrelevant instructions.
19. A public answer is not an application transaction
Suppose a person asks whether an official request was submitted. The assistant cannot determine that from a drafted form or a browser page merely showing a button. It needs the authorised system’s transaction status, an appropriate identifier and, for consequential actions, independent readback.
A timeout does not necessarily mean failure; the operation could have completed before its response was lost. Blind retries risk duplicate submissions. Reconciliation should occur through the proper official channel and privacy protections.
Every status word should correspond to an actual event: draft, attempted, submitted, acknowledged, approved and verified are not interchangeable.
20. A public service must work when AI does not
An assistant may be unavailable, unable to verify a rare case or unsuitable for a consequential question. The public institution should define how a person can continue through official non-AI channels, including any accessibility and human-support requirements applicable to the service.
Resilience is not only server uptime. It includes correcting stale information, finding records after interruptions and ensuring unresolved cases are not silently discarded. An AI-only interface that blocks legitimate access when the model fails would create a new service problem.
The responsible authority must determine and maintain the appropriate alternatives.
21. Versioning and change control protect public trust
When public rules, source documents or model configurations change, the institution needs to know which version was used for each consequential reply. A change that improves average accuracy may still worsen performance on uncommon cases. Test regressions before promoting a release.
Keep a rollback procedure for misleading information and a process for contacting affected people when appropriate. Some external actions cannot be undone merely by rolling back a model, so the review boundary before those actions remains important.
The Deployment and Monitoring chapter addresses technical releases and source drift.
22. Independent transfer to a library service desk
Now consider a fictional public library receiving sixty enquiries: thirty-six ask for published opening information, fourteen are ready for staff assessment, and ten lack a required detail. The assistant is authorised to draft information responses but not to create or approve memberships.
Under the same status method, up to 36/60 = 60% can be answered as published-information requests, 14/60 ≈ 23.3% can be routed for individual review, and 10/60 ≈ 16.7% remain incomplete. Together the categories cover all sixty records.
Changing the domain does not allow the model to invent library membership rules or carry over River Civic’s exact requirements.
23. Transfer answer: progress versus disposition
The number ready for its next authorised stage is thirty-six plus fourteen, or fifty of sixty: 50/60 ≈ 83.3%. That says nothing about how many memberships were granted, because the packet does not report any individual decision or external transaction.
The ten incomplete cases require an appropriate clarification request. A correct dashboard can label them waiting for information without marking the users as unsuccessful. This is the public-sector counterpart of a general institutional workflow: truthful state reporting matters more than inflated completion counts.
The exercise tests an ability to preserve meaning when changing surface context.
24. A useful public-service AI evaluation checklist
Define the actual service task, current sources, language and accessibility requirements, permissions, expected human review, appeal routes and which outcomes can be independently verified. Build cases that include obsolete notices, missing facts, conflicting documents, rare exceptions and uncertain tool responses.
Measure factual correctness, appropriate abstention, user understanding and completed external actions separately. Review data handling, relevant fairness conditions and recovery after a faulty release. Publish transparency information where required and appropriate under the specific jurisdiction.
An honest limited assistant can be more helpful than a general-purpose tool that invents decisions it was never authorised to make.
25. Frequently asked questions
Can public authorities use AI to answer common questions? Yes, subject to the relevant service design, rules and tests. A generated answer still needs current evidence and a way to correct errors.
Is a chatbot reply an official decision? Not simply because it looks formal. Check the authorised process and actual record.
Does a UK public-sector transparency standard apply everywhere? No. The UK policy has its own scope; other jurisdictions have different requirements.
Should the assistant always invent an answer when a source is missing? No. A supported partial answer and correct referral are more useful than false certainty.
Public accountability in practice: corrected facts, review capacity and transparent records
A public form can have several authority states
A person might download a form, fill it in, click submit, receive acknowledgement and later receive a determination. Each event has a different meaning. An AI assistant should report only the stage for which an authorised record exists. It must not treat an acknowledgement as an approval.
For River Civic, seven complete records may be routed to a caseworker. Without the caseworker’s recorded decision, their status remains in review. That is progress but not a public entitlement.
A source update can invalidate many cached answers
When a public notice is revised, a model’s older memorised or cached text may still sound authoritative. The institution should update the controlling source, invalidate relevant caches and retest common questions. A versioned link helps people and auditors see which notice supported the answer.
If the system cannot confirm that it used the latest applicable revision, it should preserve the uncertainty rather than quietly presenting a historical rule as current policy.
Who owns an incorrect answer?
A service department may be responsible for approved information, an application operator for retrieval configuration and a qualified official for individual decisions. When an answer is wrong, the workflow needs a known escalation and correction owner. Blaming an abstract model is not a practical repair procedure.
Useful incident records identify affected source versions, what was actually sent, what is disputed and whether corrected information reached the intended people through authorised means.
A fairness test should not invent demographics
Public-service evaluations can examine whether important language, accessibility or task conditions are underrepresented. But publishing speculative differences about demographic groups without reliable lawful data can mislead and expose people. Use relevant, appropriately protected data and a justified evaluation question.
A model might fail on a poorly structured form because a required field is inaccessible, not because applicants using that form are different in merit. Inspect the collection process before creating a story about users.
An ‘I do not know’ answer can be useful
If no current authorised document covers the rare exception in a user’s question, the assistant should explain which public facts are available and which part must be checked by the relevant official. It should not fabricate a convenient rule from a related programme.
An appropriate referral preserves the person’s next action. A fabricated definitive answer may instead cause a missed deadline or incorrect submission. Evaluation should therefore count correct abstention separately from avoidable failure.
Evidence and accessibility need to work together
A long official notice may be difficult for some readers. AI can propose a shorter explanation or translated version, but the result must preserve decisive conditions, exceptions and dates. Simplification that removes a mandatory requirement is not a service improvement.
Test whether readers can identify what they need to do next, including those using accessibility tools or alternative official channels. The model’s readability score alone does not prove service accessibility.
Budgeting capacity does not determine a legal outcome
Suppose the office has capacity to review only five of seven complete exceptional files during a particular period. The remaining two should be queued under legitimate service procedures, not rejected by an AI solely to make the queue appear manageable. Actual handling rules and urgency may require different arrangements.
The arithmetic 7−5 = 2 describes unreviewed capacity under the fictional setup. It does not determine which person’s case should be heard first or what the final decision should be.
The difference between explanation and recommendation
An AI may explain how a rule is written, summarise an applicant’s supplied evidence or propose which questions a reviewer could ask. It must not silently turn that explanation into the authority to recommend or issue a consequential outcome without the institution’s permission and appropriate evaluation.
A public information chatbot that begins ranking individual applicants has changed its task and risk profile. The design should detect that change and require a new approval and measurement plan.
An uncertain external write requires readback
If an official submission tool times out, the assistant should not automatically submit again or tell the applicant that nothing happened. It may have completed before the response was lost. The correct next step is an authorised status lookup or controlled reconciliation using the appropriate identifier.
Distinguish a transaction accepted by a system from a substantive decision later made on that transaction. This difference is essential in every context where users may act on an AI-generated completion statement.
A pilot should not pre-empt human rights or access
A public-body pilot needs a defined scope, suitable testing and alternative support where applicable. A system tested only to explain a public timetable should not independently approve claims, store new sensitive categories or remove a person’s usual review route.
The evaluation should look for wrong information, unjustified refusal, lost applications and effects on accessibility, alongside model latency and cost. It should stop or change when an important failure appears.
A durable transparency record must be updated
If a public tool changes model, data source, decision influence or operating purpose, its documentation may need revision. A transparency record that describes an old workflow can mislead even when it was accurate on publication day. Ownership and revision history therefore matter.
Maintain records proportionate to the local policy. The UK’s ATRS is a specific example of structured public disclosure; this fictional desk does not claim to meet any actual jurisdiction’s obligations.
Continue the connected Super Intelligence learning route: Business and Institutions · Defensive Cybersecurity · AGI, ASI and Recursive Improvement. These separate chapters trace institutional workflow, defensive system boundaries, public accountability and the limits of broader capability claims. See the full numbered curriculum.
26. Official references and connected learning
The UK Algorithmic Transparency Recording Standard guidance (updated 8 May 2025) provides jurisdiction-specific transparency practice. NIST AI RMF provides voluntary risk-management structure. GovTech Singapore’s KnowOrNot discussion illustrates the importance of unanswered questions when evidence is absent. None validates the fictional River Civic desk.
Continue to Business and Institutions, Privacy, Grounding and Human Control. The full learning map is How Super Intelligence Works, How X Works and The Gold Standard of Education.
All notices, dates, percentages, cases and decisions are invented educational fixtures. No actual government service, person’s record or public application was accessed. Source review: 22 October 2026.