For people who work in a local council, a government department or a public agency: replies to residents, notices in plain English, grant schemes and applications to assess, officer decision records, tenders, the team's figures, translations, front-desk answers. Nine cases, each with the request to copy and adapt and with what to check before a text becomes a decision or reaches a resident.
The examples use fictional documents from a fictional council. Each case lists the stages of the manual that teach the move. The cases were tested in Claude in the Italian edition of this guide, and the cases that report what the model did in a test were tested again in English on these documents, in November 2026. Where a test showed a typical mistake, the case says so.
Where the test used a fictional document, the case offers it for download: you can redo the test and compare the answer with what the case describes.
Before you start: the rules on AI, residents' data, the signature
People who work in a public body decide on other people's rights and money, and every decision carries a name. Four rules apply to every case below.
- The decision stays with a person. Under the UK GDPR, a "significant decision" about someone taken with no meaningful human involvement needs safeguards: the person must be told about it and be able to make representations, obtain human intervention and contest it (Articles 22A to 22D, fully in force since 5 February 2026). The AI Playbook for the UK Government asks for "meaningful human control at the right stage" and for humans to validate high-risk decisions influenced by AI. In the cases below the model prepares and a person reads and decides. Keep a note of where you used it: central government departments, and arm's-length bodies that provide public services, must publish a record under the Algorithmic Transparency Recording Standard for tools that influence decisions with public effect or deal directly with the public; for councils and the rest of the public sector the standard is recommended.
- Use the tool your organisation gives you, on the terms it has set (fact sheet "If the tool comes from your office"). With a personal tool, no residents' data: no names, no National Insurance numbers, no income details, no real applications.
- Laws, sections, amounts and deadlines come from the documents, never from the model. An invented legal reference in a decision record is a defect in the decision.
- Every text that goes to a resident or becomes a decision is read in full by the person who signs it.
1. Replying to an angry resident
The situation. A resident writes that they have been waiting months for a refund and threatens to go to a solicitor. They are right about the silence and wrong about the deadline.
The request. Paste the email without the name, the section of the council's policy and the team's notes, then:
"Write the reply to this resident, in plain English, 12 lines at most. Use only the facts in the notes and the rules in the policy, with the section number. Acknowledge what the team failed to do. Do not promise dates, amounts or interest that are not in the notes or the policy."
To redo the test. The fictional document used: case1_resident_email.txt.
What to check. The promises: to close the argument the model tends to concede, an earlier date, an exception. Every commitment in the reply must be in the notes or the policy. The deadline set by the law or the policy: stated correctly, with the date it runs from.
Stages. 2 (the same request, done well), 4 (the check).
2. A notice in plain English
The situation. A notice written in officialese: "notice is hereby given", "inclusive of", "failing which they shall be rejected". The people who have to apply do not understand it.
The request. Paste the notice, then:
"Rewrite this notice in plain English for families: who can apply, what they need, by when, how much they get, what happens if something is missing. Short sentences, second person. Keep every condition, the deadlines with the time and the exact amounts. At the end, list the conditions you simplified, so I can check them."
To redo the test. The fictional document used: case2_grant_notice.txt.
What to check. The conditions a plain text loses first: the time of the deadline, "or the application is rejected", the exceptions ("also for schools outside the borough, provided the pupil lives here"). Amounts and thresholds, figure by figure. The additions: if the model explains a term the notice does not define, such as what counts as an itemised receipt, it must say so in the list of simplifications, and a definition added to a text for residents has to be confirmed by the team. In the test the model kept the time and the amounts, explained "non-itemised till receipts" and put that explanation among its own additions, together with a sentence it had inferred from the funding rule. The plain text does not replace the official notice: it goes with it, and it must say where the notice can be found.
Stages. 2, 3 (a document of your own).
3. A grant scheme's requirements as a checklist
The situation. A grant scheme to assess arrives. Before opening the applications you need a checklist that is the same for everyone.
The request. Upload the scheme rules, then:
"Turn these scheme rules into a checklist for assessing applications: for each requirement and each document, the section, what to check, and what happens if it is missing: rejection or a request for the missing document. Do not add requirements that the rules do not set."
To redo the test. The fictional document used: case3_rent_grant_rules.txt.
What to check. The difference between rejection and a request for a missing document: it is the line that decides what happens to an application, and it is often in a different section from the requirements. The deadlines with the time. Requirements the model adds "as good practice": remove them. In the test the model noticed on its own that the rules say "rejected" or "not accepted" for the deadline and for the missing tenancy agreement, but say nothing of the kind for an applicant who does not meet a requirement: that is the kind of gap to close before the assessment starts.
Stages. 3, 7 (Excel: formulas, data and charts).
4. Checking the applications received
The situation. The applications are in a spreadsheet: date and time received, household income, documents attached. They have to be sorted into eligible, rejected and missing a document.
The request. In the same chat as case 3, upload the spreadsheet without names and National Insurance numbers, then:
"Apply the checklist to these applications, with a program. For each one: eligible, rejected or missing a document, with the reason and the section of the rules. List the borderline cases separately."
To redo the test. The fictional document used: case4_applications.csv.
What to check. The borderline cases: an income exactly equal to the threshold, an application received a few minutes after the deadline, a missing document that leads to a request and not to a rejection. The model has to list them, and the decision on each one is yours: the outcome of an assessment is a decision, and a person signs it. In the test it found all three, including the missing photo ID, which the rules handle with a request and not with a rejection.
5. The draft of an officer decision record
The situation. A contract award to put on record. The facts are in the notes; the decision record has to follow the council's template.
The request. Paste the notes and, if the council has one, a similar decision record already published, then:
"Write the draft officer decision record following the structure of the example: title, background, decision, reasons, options considered, financial implications, legal implications. Use only the facts in the notes. For every legal, constitutional or financial reference that is not in the notes, leave a gap in square brackets: [reference to check]. Do not invent record numbers, codes or cost centres."
To redo the test. The fictional document used: case5_decision_notes.txt.
What to check. The legal references, and the delegated authority the officer is acting under: if the model writes one that was not in the notes, even a correct one, check it against the text in force before signing (case 8 of the professional firms field shows how). The amounts, with and without VAT. The codes that do not exist yet (the purchase order number, the record number): they must stay as gaps. In the test the draft left in square brackets every legal reference, the record number and the names of the suppliers that the notes did not give, and said that it had worked out the VAT and the total itself: those are the two lines to redo.
Stages. 6 (Word and Outlook), 15 (when it searches instead of remembering).
6. Scoring the tenders
The situation. A tender scored on quality and price. The evaluation panel has given the quality scores; the calculations remain.
The request. Paste the evaluation criteria from the tender documents and the tenders, then:
"First check which tenders are compliant under the tender documents. Then work out with a program the price score with the formula stated and the total, and rank the tenders. Show the formula applied to each tender."
To redo the test. The fictional document used: case6_tenders.txt.
What to check. Compliance before the calculations: a tender that should be excluded, if it enters the calculation, can change the lowest price and so the scores of all the others, and it can end up at the top of the ranking. The formula, applied by hand to one tender. The ranking is a proposal for the panel, not the award.
7. The team's figures for the annual report
The situation. The annual report needs the processing times: how long the team takes, how many requests go over the target, how many are still open.
The request. Export the requests with the dates received and closed, then:
"Work out with a program: the average and median time of the closed requests, how many went over the 30-day target, how many are still open and how many of those are already over the target as of today, which is [date]. Explain how you treat the open requests."
To redo the test. The fictional document used: case7_requests.csv.
What to check. The open requests: if they are left out of the average time, the average improves precisely because of the slowest requests. An honest figure reports them separately, with their age. Today's date, written in the request.
Stages. 7, 5 (the finished work).
8. A notice for families who do not read English
The situation. A notice for families has to be translated into Polish, and nobody in the team can check it with confidence.
The request. Paste the notice, then:
"Translate this notice into simple Polish, for families who have recently moved to the UK. Explain in one line the UK terms (GP, council online account). Write the dates in full, with the month in words. Then translate your text back into English, so I can compare it with the original."
To redo the test. The fictional document used: case8_club_notice.txt.
What to check. The back-translation: compared with the original, it shows what was lost or added even to someone who does not read the language. The dates: 10/01 is 10 January in the UK and in Poland, and 1 October for an American reader, which is why they are written in words. The times: "12 noon" should become an unambiguous 12:00. The amounts and the conditions of the discounts. Translation also brings out the ambiguities of the original: in this notice, "a 20% discount from the second child" does not say whether it adds to the reduced rate, and "an income of up to £8,000" does not say whether £8,000 itself counts. It is worth correcting the English notice before translating it. In the test the model flagged the discount and "the month after", noticed that "tea" here is a meal and not the drink, but settled the £8,000 threshold on its own ("at most") without saying so: that is the kind of choice to look for in the back-translation. If your organisation has a translation service, the back-translation helps you check, and the service still has the last word on a text that will be published.
9. The front desk's answers
The situation. The same questions reach the front desk and the phone line every day the scheme is open.
The request. In a project (stage 12) with the notice and any official FAQs, in the instructions:
"Answer the front-desk colleagues' questions only on the basis of the uploaded documents, in three lines, citing the paragraph of the notice. If the documents do not answer, write 'The notice does not say: ask the responsible officer' and do not infer."
Then try it with three questions: two that have an answer and one that does not.
What to check. The question with no answer is the real test. And the date: when the council publishes a correction or a new FAQ, upload it to the project, or the front desk answers with the old notice.
Cases tested on 7 November 2026.