The system does the groundwork on each file. A case officer makes the call.
Planning and housing applications, grant claims, licences, insurance claims and appeals go through several desks before anyone decides. We build case flows that take in structured data, ask the applicant just once for anything missing, pull what State registers already hold, run versioned rules and draft the decision letter, so case officers can give their time to the assessment itself.
For local authorities, State agencies and insurers in Ireland that handle applications and claims under Irish law, in Irish and English.
An application comes in as structured data and is checked to see if it is complete; if anything is absent, the applicant gets a single request and the file moves on once the items are in. The system pulls data from registers, applies the versioned rules and writes a summary where each statement points to its source. A case officer weighs up the file and decides, then approves the decision letter drafted from an approved template before it is sent and filed.
Before and after
How the work changes for case officers and applicants
Today
With the system
Today
Today: Files going round in circles
Weeks after the application went in, someone spots a missing document, a letter goes out to the applicant, and the file sits idle until a reply comes.
With the system
With the system: Complete from day one
Completeness is checked the moment the application arrives, and the applicant gets one request naming exactly what is still needed.
Today
Today: Asking for what the State already has
Applicants send in statements and certificates that a public register already holds, and staff then type them into the case system again.
With the system
With the system: Register data pulled, not requested
Data that an official register already holds is pulled through its API, with the purpose logged, and shown to the officer along with where it came from.
Today
Today: Similar files, different results
Each officer works through the criteria from personal notes and bases the letter on an old one, so comparable files can end in different results, and later nobody can show which version of the rules was used.
With the system
With the system: One set of rules, on file
Criteria run as versioned decision models backed by test cases, letters begin from approved templates, and each case file records the rule version that applied.
Today
Today: Time limits tracked by hand
Statutory time limits live in spreadsheets, and older files drift to the back of the queue until they turn urgent.
With the system
With the system: Time limits always visible
Each file carries its statutory time limit, team leaders can see which files are at risk, and the queue is broken down by age and by type of case.
Workflow
The workflow, step by step
The system handles the groundwork: intake, register data, rule results, a referenced summary and a draft letter. Weighing up the file and deciding stay with the case officer, who has all of it on one screen.
Illustrative workflow
7 steps · 2 human checkpoints
Legend
System
AI agent
Person
Human checkpoint
Exception path
Case processing: illustrative workflow and missing-documents route
Read the diagram as text
The usual route goes from taking in and checking the application, through pulling register data, running the versioned rules and writing a referenced summary, to the case officer weighing up and deciding, and closes with the decision letter drafted and sent.
If the completeness check shows something is missing, the file leaves the usual route and the applicant gets a single request listing what is needed. When the items come in and pass the check, the file returns to the route at the register step.
The point where a person steps in is the case officer’s assessment and decision, followed by the officer approving the letter: the system prepares and drafts, but no decision is made and no letter is sent without a person.
01
Step 1: Take in and check the applicationSystem
Applications come in as structured data from an online service, e-forms or the document intelligence intake. A file is opened under its case type, the statutory time limit starts from the date of receipt, and the items that case type requires are checked off.
02
Step 2: Ask for what is missingSystem
On the channel they used, the applicant gets a single request setting out which documents or details are missing and the date they are due. What comes back is checked against that same list, and any effect on the time limit is recorded in line with the procedure.
Exception path: Application not complete· Returns to step 3
03
Step 3: Pull data from registersSystem
Using the applicant’s verified identity, for example through MyGovID, and the legal basis of the procedure, data is pulled from official registers through their APIs. For cross-border procedures under the Single Digital Gateway, evidence from another Member State can be exchanged through the Once-Only Technical System if the applicant asks for it. Each query is logged along with its purpose.
04
Step 4: Run the versioned rulesSystem
Rules for eligibility and calculation run as versioned decision models (DMN or rules as code), each tied to the section of the Act, Statutory Instrument or scheme it applies. The output marks every criterion as met, not met or left for the officer, with the facts and the rule version behind it.
05
Step 5: Write a referenced case summaryAI agent
A model condenses the application, the attachments and the register extracts for the officer: facts, dates, amounts, open questions and any conflict between sources. Each statement links back to the page or register extract it rests on. The summary makes no judgement on eligibility and suggests no outcome.
06
Step 6: Weigh up and decidePerson
On one screen the case officer has the rule results, the summary and the evidence beneath them. They assess what the rules leave open, make the decision and write out the reasons. A rule result can be overridden as long as the reason is recorded.
Human checkpoint
The case officer always makes the decision. No decision with a legal effect rests only on automated processing, and a second officer can be required by case type, amount or outcome.
07
Step 7: Draft and send the decisionSystem
The letter is built from the approved template for that case type and outcome, carrying the officer’s reasons and the legal basis, in Irish or English as the applicant chose. After approval it is signed, sent and filed with the case. A review or appeal opens a linked file holding the original papers, the rule version and the reasons.
Human checkpoint
No letter goes out until the case officer has approved the final wording.
Components
What we would put in place
01
Intake and completeness checks
Takes submissions from online services, e-forms and document intelligence, works through a checklist for each case type and sends requests for missing items on the applicant’s own channel.
API clients for official registers and data-sharing services, and for the Once-Only Technical System where a procedure falls within it, each logging the purpose of every query.
Eligibility and calculation rules in DMN or as code, versioned with commencement dates, tied to their legal source and covered by test cases your legal advisers can read.
A single screen for evidence, rule results, summary, decision and reasons, built into your current case system where we can, with letter templates in Irish and English owned by your legal team.
Ways to notify applicants: online account inbox, email and post
Controls
Safeguards built in
Access boundaries
Case officers see only the case types and sections their role permits. Register queries run under the legal basis of the procedure and fetch only the fields that case type needs, each logged with the file reference and purpose. The summary service can read the file but has no power to change case data, rule results or decisions.
Human review
Each decision is made by a case officer who can see the rule results, the summary and the evidence underneath. Decisions with a legal or similarly significant effect on the applicant are never based only on automated processing (Article 22 GDPR). Officers may depart from a rule result if they record why, so the assessment is a genuine one.
Auditability
For each file we log the data received, every register query and its answer, the rule version and the result per criterion, the summary with its sources and model version, the decision and reasons, and the letter as sent. In a review, an appeal or an audit, you can show which rules and facts applied on the day of the decision.
Data protection
Only the register fields the rules need are pulled. Retention and destruction follow your records schedule for each case type, processing stays in the EU region agreed with you, and case data never trains outside models. The GDPR and the Data Protection Act 2018 frame each step.
AI transparency
Decision letters set out the facts, the rules used, the reasons and how to seek a review or appeal. If a model helps prepare files, its role is documented and entered in your AI register, and published in any public algorithm register that applies to you.
Measures
How we would judge it
We set measures for each case type and take a baseline from your current case data before anything changes.
How we would judge it
Metric
Why it matters
How we would measure it
01Processing time by case type
Why it mattersWhat applicants actually feel, split by case type so a quick procedure does not mask a slow one.
How we would measure itTime from receipt to the decision being sent, and from a complete file to the decision being sent, from case timestamps.
02Applications complete on arrival
Why it mattersTells you if forms, prefilled data and checklists are stopping the back-and-forth.
How we would measure itFiles that pass the completeness check first time, by channel and case type.
03Requests sent per file
Why it mattersEach request costs the applicant time and the officer a follow-up.
How we would measure itRequests for missing items or clarification per file, by reason, taken from the case log.
04Files over the statutory time limit
Why it mattersThe legal minimum for timeliness, and an early warning that the queue is growing.
How we would measure itOpen and closed files past the time limit, and files inside the warning period, by team and case type.
05Consistency in sampled second reviews
Why it mattersComparable files should end the same way, no matter which officer takes them.
How we would measure itHow often a second officer’s assessment of the same file agrees with the original decision, on a random sample.
06Appeals and reviews upheld
Why it mattersAn appeal that succeeds points to rules, evidence or reasons needing attention.
How we would measure itReviews and appeals upheld fully or partly, by ground and by the rule version used.
No targets are set before a baseline exists.
Rollout
How we would introduce it
Phase 01
Discovery and analysis of the rules
A single case type and its legal basis. We map how files move today, write the criteria up as a decision model with your legal advisers and gather anonymised past files as test cases.
Exit criteria
Rules reviewed by legal advisers
Test cases and expected results signed off
Baseline recorded for each measure
Data protection impact assessment and AI Act classification under way
Phase 02
Build and replay past files
Intake, register connections, rules and the officer workspace for the chosen case type. Past files are run again through the rules and the summary service and compared with the decisions actually made.
Exit criteria
Rule results match the test cases, or every gap is explained
Source links checked on a sample of summaries
Register owners have approved access
Phase 03
Live use under supervision
New files of the chosen type go through the system. Officers decide as they always have, and a sample of decisions gets a second review.
Exit criteria
Second reviews confirm consistent decisions
Team leaders use the time-limit alerts
Runbook, monitoring and rollback ready
Phase 04
Further case types
Other case types reuse the intake, connections and workspace, each with its own rules, test cases and legal review.
Planning, housing and grant applications at local authorities and State agencies, with register data pulled once and statutory time limits followed for each procedure.
Requests for approval and scheme applications in health services, with each scheme’s rules versioned and any clinical judgement left to qualified staff.
Permits for oversized loads and for works at ports or on roads, with route, vehicle and works details checked against network data and other permits before an officer decides.
Illustrative example
Housing grant applications at a county council
Situation
A county council runs several housing grant schemes. Applications come through an online service after a MyGovID login, or on paper, in Irish or English, with income statements and quotes attached as PDFs, and staff chase missing documents by phone and letter.
System
Intake checks each application against the checklist for its scheme. Details are pulled from official registers where an interface exists and otherwise read from the attachments through document intelligence. Eligibility and grant amount rules run as a versioned decision model, and a model summarises each file with links to the source pages.
Human control
Grant officers weigh up and decide every application, and a second officer reviews a sample. Letters come from approved templates in the applicant’s chosen language, and payments are released from the finance system only once the decision is signed.
What we would measure
Applications complete on arrival per scheme, requests sent per file, consistency in second reviews, and processing time per scheme.
Ireland
Irish case files, Irish and EU rules
Irish public bodies work under Acts, Statutory Instruments and scheme rules that change often, carry Irish-language duties under the Official Languages Act, and often verify identity through MyGovID. We design one case flow with versioned rule sets, register connections and letter templates in both languages, so each file follows the same controlled route.
Under the Single Digital Gateway Regulation, users of the listed procedures have been able since 12 December 2023 to ask for evidence to be exchanged directly between authorities through the Once-Only Technical System. Case officers keep the decision, as Article 22 GDPR requires, and AI systems that assess eligibility for essential public assistance benefits and services are high-risk under the AI Act, which Ireland now gives effect to through the Regulation of Artificial Intelligence Act 2026.
No. It opens the file, pulls data, runs the rules, writes a referenced summary and drafts the letter. The case officer weighs up the file, decides and approves the letter. Article 22 GDPR gives people the right not to be subject to a decision based only on automated processing that has legal effects on them or affects them in a similarly significant way. The workflow is built so that a person carries out a genuine assessment on every file, not a click to confirm.
02Where does the AI Act come in, now that Ireland has its own Act?
That turns on what the model is used for. Under Annex III, point 5(a), AI systems used by or for public authorities to assess whether people qualify for essential public assistance benefits and services, or to grant, cut, withdraw or recover them, are high-risk. Point 5(b) covers AI that scores the creditworthiness of individuals, fraud detection excepted. With the 2026 amendments, those duties start on 2 December 2027. In Ireland, the Regulation of Artificial Intelligence Act 2026 gives effect to the regime, with the AI Office of Ireland as the central coordinating authority.
Should a model play a part in assessing eligibility, we design for the high-risk duties from the outset. Our usual design keeps the model out of that: versioned rules test the criteria, a case officer decides, and the model only summarises and drafts. Whether a component falls outside the high-risk category is a classification your legal team records, and we provide the technical description they need. Read our guide to the AI Act for public bodies.
03Must our case management system be replaced?
No. The intake, rules, summary and letter services link to your current case system through its APIs, or are built into it where the platform permits, for instance on Salesforce. Replacing the case system is a different question, only worth asking when that system is itself the bottleneck; legacy modernisation explains how to do it in stages.
04How do the rules keep up when Acts and Statutory Instruments change?
Every rule set is a versioned decision model tied to the section or scheme clause it applies, with test cases stating the expected result. When the law changes, your legal advisers review the new version, the test cases are revised and run, and the version is given a commencement date. Each file is assessed under the version that applies to it, and the file records which one that was.
05How do applicants find out how their file was handled?
The decision letter sets out the facts, the rules used and the reasons, and explains how to ask for a review or appeal, in Irish or English. The online account can show what data came from which register. If a model helps prepare files, that use is documented and recorded in any public algorithm register that applies. Status queries can be answered from the same case data through service assistance, and anyone dealing directly with an AI system is told so, as Article 50 of the AI Act has required since 2 August 2026.
06What would a sensible first scope be?
A single case type with a clear legal basis and enough files to measure, and one set of rules. It tests intake, register connections, rules, summary and letter on live files before other case types are added. How we work explains the discovery and delivery phases.
Pick one case type
Tell us about one case type, the registers it relies on and how applicants reach you. We will sketch a first release around that set of rules.