The system prepares and checks each case. A case handler decides.
Applications, permits, subsidies, claims and objections pass through several hands before anyone decides. We build case flows that receive structured data, ask applicants once for what is missing, fetch what registers already hold, run versioned rules and draft the letter, so case handlers spend their time on the assessment.
For organisations that handle applications and claims from several EU Member States, each with its own registers, rules and time limits.
An application arrives as structured data and is checked for completeness; if items are missing, the applicant receives one request and the case continues once they arrive. The system fetches data from registers, runs the versioned rules and prepares a summary in which every statement links to its source. A case handler assesses and decides, and approves the decision letter drafted from an approved template before it is issued and recorded.
Before and after
What changes for case handlers and applicants
Today
With the system
Today
Today: Files that bounce back and forth
A missing annex is noticed weeks after submission, the applicant is asked by letter, and the case waits in the meantime.
With the system
With the system: Complete before it starts
The completeness check runs at intake, and the applicant receives one request that lists exactly what is missing.
Today
Today: Asking for data that already exists
Applicants supply extracts and certificates that a register already holds, and staff retype them into the case system.
With the system
With the system: Register data fetched, not requested
Data held in an authentic source is retrieved through its API with a logged purpose and shown to the handler with its origin.
Today
Today: Same case, different outcome
Each handler checks the criteria from their own notes and writes the letter from an old example, so similar cases can end differently and nobody can say afterwards which version of the rules applied.
With the system
With the system: One rule set, on the record
Criteria run as versioned decision models with test cases, letters start from approved templates, and the case record shows which rule version applied.
Today
Today: Deadlines in spreadsheets
Statutory time limits are tracked by hand, and old cases sink to the bottom of the backlog until they become urgent.
With the system
With the system: Time limits in view
Every case carries its statutory time limit, team leads see which cases are at risk, and the backlog is visible by age and case type.
Workflow
How the workflow runs
The system does the preparation: intake, register data, rule results, a sourced summary and a draft letter. The assessment and the decision belong to the case handler, who sees 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 with missing-items path
Read the diagram as text
The main path runs from receiving and checking the application, through fetching data from registers, applying the versioned rules and preparing a sourced case summary, to the case handler’s assessment and decision, and ends with drafting and issuing the decision letter.
When the completeness check finds items missing, the case leaves the main path and the applicant receives one request listing what is missing. Once the items arrive and pass the check, the case rejoins the main path at the register step.
The case handler’s assessment and decision is the human checkpoint, followed by the handler’s approval of the letter: the system prepares and drafts, but no decision is taken and no letter is sent without a person.
01
Step 1: Receive and check the applicationSystem
Applications arrive as structured data from the portal, e-forms or the document intelligence intake. The case is opened under its case type, the statutory time limit is set from the date of receipt, and the items required for that case type are checked.
02
Step 2: Request missing itemsSystem
The applicant receives one request, on the channel they used, listing which items or data are missing and by when. Items that arrive are checked against the same list, and the effect on the time limit is recorded as the procedure prescribes.
Exception path: Application incomplete· Returns to step 3
03
Step 3: Fetch data from registersSystem
Based on the applicant’s identity and the legal basis of the procedure, data is retrieved from authentic sources and base registries through their APIs. For cross-border procedures covered by the Single Digital Gateway, evidence from another Member State can be exchanged through the Once-Only Technical System at the applicant’s request. Every query is logged with its purpose.
04
Step 4: Apply versioned rulesSystem
Eligibility and calculation rules run as versioned decision models (DMN or rules as code), each linked to the legal or policy provision it implements. The result lists every criterion as met, not met or open for assessment, with the facts and the rule version used.
05
Step 5: Prepare a sourced case summaryAI agent
A model summarises the application, attachments and register extracts for the case handler: facts, dates, amounts, open points and contradictions between sources. Every statement links to the document page or register extract it comes from. The summary does not assess eligibility or recommend an outcome.
06
Step 6: Assess and decidePerson
The case handler reviews the rule results, the summary and the underlying evidence on one screen, assesses the points the rules leave open, takes the decision and writes the motivation. A rule result can be set aside with a recorded reason.
Human checkpoint
The decision is always the case handler’s. No decision with legal effect is based solely on automated processing, and four-eyes review can be required per case type, amount or outcome.
07
Step 7: Draft and issue the decisionSystem
The letter is drafted from the approved template for the case type and outcome, with the handler’s motivation and the legal grounds. Once approved, it is signed, sent and recorded with the case. An objection or appeal opens a linked case that carries the original file, rule version and motivation.
Human checkpoint
No letter leaves without the case handler’s approval of the final text.
Components
What we would build
01
Intake and completeness service
Receives submissions from portals, e-forms and document intelligence, applies a checklist per case type and sends requests for missing items on the applicant’s channel.
API clients for authentic sources, base registries and national data exchange platforms, and for the Once-Only Technical System where a procedure is in scope, each with purpose logging.
Eligibility and calculation rules in DMN or as code, versioned with start dates, linked to their legal source and covered by test cases your legal experts can read.
One screen for evidence, rule results, summary, decision and motivation, built into the existing case system where possible, with letter templates owned by your legal team.
Notification channels: portal inbox, email and electronic registered delivery
Controls
Controls designed in
Access boundaries
Case handlers see only the case types and units their role allows. Register queries run under the legal basis of the procedure, for the fields the case type needs, and each one is logged with the case reference and purpose. The summary service reads the case file but cannot change case data, rule results or decisions.
Human review
Every decision is taken by a case handler who sees the rule results, the summary and the evidence behind them. Decisions that produce legal effects or similarly significantly affect the applicant are never based solely on automated processing (GDPR Article 22). Departures from a rule result are allowed and recorded with a reason, so the assessment is a real one.
Auditability
Per case we log the data received, every register query and its result, the rule version and the outcome per criterion, the summary with its sources and model version, the decision and motivation, and the letter as sent. An objection or an audit can reconstruct which rules and facts applied on the day of the decision.
Data protection
Only the register fields the rules need are fetched. Retention and destruction follow your records schedule per case type, processing stays in the agreed region, and case data is not used to train external models.
AI transparency
Decision letters state the facts, the rules applied, the motivation and how to object or appeal. Where a model helps prepare cases, its role is documented, recorded in your AI register and, where your jurisdiction keeps a public algorithm register, published there.
Measures
What we would measure
Measures are set per case type, with a baseline taken from your current case data before anything changes.
What we would measure
Metric
Why it matters
How we would measure it
01Lead time per case type
Why it mattersThe measure applicants notice, split by case type so one fast procedure does not hide a slow one.
How we would measure itTime from receipt to decision sent, and from complete file to decision sent, from case timestamps.
02Share of complete applications at intake
Why it mattersShows whether forms, prefilled data and checklists prevent the back-and-forth.
How we would measure itCases that pass the completeness check on first submission, per channel and case type.
03Information requests per case
Why it mattersEvery request costs the applicant time and the handler a follow-up.
How we would measure itRequests for missing items or clarification per case, by reason, from the case log.
04Cases past their statutory time limit
Why it mattersThe legal floor for timeliness, and an early sign of a growing backlog.
How we would measure itOpen and closed cases past the time limit, and cases inside the warning window, per team and case type.
05Decision consistency in sampled peer review
Why it mattersSimilar cases should get the same outcome, whoever handles them.
How we would measure itAgreement between the original decision and a second handler’s assessment of the same file, on a random sample.
06Share of objections upheld
Why it mattersSuccessful objections point to rules, evidence or motivation that need attention.
How we would measure itObjections and appeals upheld in full or in part, by ground and by the rule version applied.
No targets are set before a baseline exists.
Rollout
How we would roll it out
Phase 01
Discovery and rule analysis
One case type and its legal basis. We map how cases run today, write the criteria as a decision model with your legal experts and assemble anonymised past cases as test cases.
Exit criteria
Rule set reviewed by legal experts
Test cases with expected outcomes agreed
Baseline recorded per measure
Data protection impact assessment and AI Act classification started
Phase 02
Build and replay
Intake, register connectors, rules and the handler workspace for the chosen case type. Past cases are replayed through the rules and the summary service and compared with the decisions taken.
Exit criteria
Rule outcomes match the test cases, or each difference is explained
Source links checked on sampled summaries
Register access approved by the data owners
Phase 03
Controlled production
New cases of the chosen type run through the system. Handlers decide as before, and a sample of decisions is peer reviewed.
Exit criteria
Peer review shows consistent decisions
Deadline monitoring used by team leads
Runbook, monitoring and rollback in place
Phase 04
More case types
Further case types reuse intake, connectors and the workspace, each with its own rule set, test cases and legal review.
Insurance claims and complaints handling, with cover rules versioned per policy wording, claims handlers deciding and complaint response deadlines in view.
Special transport and road works permits, with route, vehicle and works data checked against network data and other permits before a handler decides.
Illustrative example
Grant applications from several Member States
Situation
A public funding agency runs a grant programme open to organisations established in several EU Member States. Applications arrive through one portal in four languages, with company and tax extracts attached as PDFs, and officers chase missing annexes by email.
System
Intake checks completeness against a checklist per applicant country. Company data is retrieved from business registers where an interface exists and otherwise taken from the extract through document intelligence. Eligibility and co-financing rules run as a versioned decision model, and a model summarises each application with links to the source pages.
Human control
Programme officers assess and decide every application, and a second officer reviews a sample. Letters come from approved templates in the applicant’s language, and payments are released from the finance system only after the decision is signed.
What we would measure
Share of complete applications per country, information requests per case, decision consistency in peer review, and lead time per call.
International
Cases that cross borders
Organisations that receive cases from several EU Member States work with national registers, national procedural rules and evidence in several languages. We design one case flow with rule sets and register connectors per country, so every application follows the same controlled path wherever it comes from.
Since 12 December 2023, users of the procedures listed in the Single Digital Gateway Regulation can ask for evidence to be exchanged directly between competent authorities through the Once-Only Technical System. Decisions stay with case handlers, in line with the GDPR right not to be subject to decisions based solely on automated processing, and AI systems used by or on behalf of public authorities to evaluate eligibility for essential public assistance benefits and services are high-risk under the EU AI Act.
No. The system opens the case, fetches data, runs the rules, writes a sourced summary and drafts the letter. The case handler assesses the case, decides and approves the letter. Under GDPR Article 22, people have the right not to be subject to a decision based solely on automated processing that produces legal effects for them or similarly significantly affects them. The workflow is designed so that a person makes a real assessment in every case, not a confirmation click.
02How does the EU AI Act apply?
It depends on the role the model plays. AI systems intended to be used by or on behalf of public authorities to evaluate whether people are eligible for essential public assistance benefits and services, or to grant, reduce, revoke or reclaim them, are high-risk under Annex III, point 5(a). AI used to evaluate the creditworthiness of natural persons is high-risk under point 5(b), except for fraud detection. Under the Act as amended in 2026, these obligations apply from 2 December 2027.
If a model is to take part in the eligibility assessment, we design for the high-risk obligations from the start. Our default keeps the model out of it: versioned rules evaluate the criteria, a case handler decides, and the model only summarises and drafts. Whether a component stays outside the high-risk category is a classification your legal team documents, and we supply the technical description it needs. See our AI Act guide for public bodies.
03Do we have to replace our case-management system?
No. Intake, rules, summary and letter services connect to the case system you have through its APIs, or are built inside it where the platform allows, for example on Salesforce. Replacing the case system is a separate decision, worth taking only when the system itself is the bottleneck; legacy modernisation describes how to do that in steps.
04How do the rules stay aligned with changing legislation?
Each rule set is a versioned decision model linked to the article or policy clause it implements, with test cases that state the expected outcome. When the law changes, your legal experts review the new version, the test cases are updated and run, and the version gets a start date. Each case is assessed under the version that applies to it, and the case record keeps which one that was.
05How are applicants informed about how their case was handled?
The decision letter states the facts, the rules applied and the motivation, and explains how to object or appeal. The portal can show which data was fetched from which register. Where a model helps prepare cases, that use is documented and, where a public algorithm register exists, recorded there. Status questions can be answered from the same case data through service assistance, and people who interact with an AI system directly are told so, as Article 50 of the AI Act has required since 2 August 2026.
06What does a first scope look like?
One case type with a clear legal basis and enough volume to measure, and one rule set. It proves intake, register connections, rules, summary and letter on real cases before further case types follow. Our approach describes the discovery and delivery phases.
Discuss your case types
Name one case type, the registers it draws on and the countries its applicants come from. We will outline a first release around that rule set.