Software assembles and verifies the file. The officer determines it.
A permit, grant, benefit, claim or objection often crosses several desks before anyone rules on it. We build case flows that take in structured submissions, ask the applicant only once for what is lacking, pull what Government registers already hold, apply rules under version control and prepare the letter, leaving officers free to concentrate on judgement.
For ministries, public entities, local councils and insurers in Malta that handle applications and claims under legal time limits, often with Malta e-ID sign-in and servizz.gov as the front door.
A submission comes in as structured data and its completeness is verified; where something is lacking, the applicant gets a single request and the file moves on when the items are in. Software pulls register data, applies the rules in their current version and compiles an overview in which each statement points to its origin. The officer weighs the file, determines it and signs off the letter drafted from an approved template, after which it is issued and filed.
Before and after
What shifts for officers and applicants
Today
With the system
Today
Today: Files going to and fro
Weeks after submission someone spots that an annex is absent, a letter goes out to the applicant, and the file sits idle until a reply comes.
With the system
With the system: Complete from the outset
Completeness is verified as soon as the submission arrives, and the applicant receives a single message naming precisely what is lacking.
Today
Today: Requesting what Government already holds
Applicants hand in certificates and extracts that a register already keeps, and officers key them into the case system again.
With the system
With the system: Register data pulled, not demanded
Information already kept in an authoritative register is obtained through its API, with the purpose logged, and shown to the officer together with where it came from.
Today
Today: Similar files, different results
Every officer checks criteria from personal notes and adapts an old letter, so comparable files can be determined differently, and later nobody can tell which edition of the rules was used.
With the system
With the system: A single, recorded rule set
Criteria are executed as decision models under version control with their own test cases, letters begin from approved templates, and the file records the rule version used.
Today
Today: Time limits kept on spreadsheets
Legal time limits are followed by hand, and older files slide down the pile until they turn into emergencies.
With the system
With the system: Legal time limits on screen
Each file carries its legal time limit, section heads see which files are in danger of overrunning, and the pile can be viewed by age and by type of file.
Workflow
The workflow, step by step
Software handles the groundwork: intake, register data, rule outcomes, an overview with sources and a draft letter. Weighing the file and determining it are for the officer, who has all of this in front of them on a single screen.
Illustrative workflow
7 steps · 2 human checkpoints
Legend
System
AI agent
Person
Human checkpoint
Exception path
Case processing with its route for missing items (illustrative)
Read the diagram as text
The main route goes from taking in and verifying the submission to pulling register data, executing the rules under version control and compiling an overview with sources, then to the officer who weighs and determines the file, and finishes with preparing and issuing the decision letter.
If the completeness check shows that items are lacking, the file steps off the main route and the applicant gets a single request naming them. When the items are in and pass the check, the file returns to the main route at the register step.
People decide at two points: the officer weighs and determines the file, and then approves the letter. Software prepares and drafts, but nothing is decided and nothing is dispatched without a person.
01
Step 1: Take in and verify the submissionSystem
Submissions reach the system as structured data from servizz.gov or an entity’s own portal, from e-forms or from the document intelligence intake. The file is opened under its type, the legal time limit starts from the date of receipt, and the items that type requires are verified.
02
Step 2: Ask once for what is lackingSystem
Through the channel the applicant chose, a single request names the items or information still needed and the date they are due. Whatever comes back is verified against that same list, and any effect on the time limit is noted as the procedure lays down.
Exception path: Submission lacks items· Returns to step 3
03
Step 3: Pull register dataSystem
Using the applicant’s identity, confirmed through Malta e-ID where needed, and the legal basis of the procedure, information is obtained from authoritative registers through their APIs. For cross-border procedures within the Single Digital Gateway, evidence held in another Member State can be exchanged over the Once-Only Technical System if the applicant asks for it. The purpose of each query is logged.
04
Step 4: Execute rules under version controlSystem
Eligibility and calculation rules are executed as decision models under version control (DMN, or rules written as code), each tied to the provision of law or policy it reflects. The outcome marks each criterion as satisfied, not satisfied or left for the officer, together with the facts and the rule version applied.
05
Step 5: Compile an overview with sourcesAI agent
A model compiles an overview of the submission, its annexes and the register extracts for the officer: facts, dates, amounts, open questions and points where sources disagree. Each statement points to the page or extract it is based on. The overview does not judge eligibility and does not suggest a result.
06
Step 6: Weigh and determinePerson
On a single screen the officer goes through the rule outcomes, the overview and the evidence beneath them, weighs whatever the rules have left open, determines the file and records the reasons. An officer may depart from a rule outcome by stating why.
Human checkpoint
Determining the file is always for the officer. No decision with legal effect rests on automated processing alone, and a second officer’s review can be made mandatory by type of file, amount or result.
07
Step 7: Prepare and issue the decision letterSystem
The letter is prepared from the approved template for that type of file and result, carrying the officer’s reasons and the legal basis. After approval it is signed, dispatched and filed with the case. An objection or appeal starts a linked file that brings along the original papers, the rule version and the reasons given.
Human checkpoint
No letter is dispatched until the officer has approved its final wording.
Components
The building blocks
01
Intake and completeness service
Accepts submissions from portals, e-forms and the document intake, applies a checklist for each type of file and sends requests for missing items through the applicant’s own channel.
API clients for authoritative registers and national data exchange, plus the Once-Only Technical System where a procedure falls within it, each logging its purpose.
Eligibility and calculation rules in DMN or as code, versioned with effective dates, tied to their legal source and covered by test cases your legal advisers can read.
Model-written overviews in which every statement carries a link to its source, tested on a set built from closed files, and kept out of the eligibility judgement.
Evidence, rule outcomes, overview, decision and reasons on one screen, inside the current case system wherever possible, with letter templates owned by your legal office.
Notification channels: portal mailbox, email and electronic registered delivery
Controls
Controls built in from the start
Access boundaries
Officers can open only the types of file and sections their role covers. Register queries rely on the legal basis of the procedure, ask only for the fields that type of file needs, and are each logged with the file reference and purpose. The overview service may read the file but has no way to alter case data, rule outcomes or decisions.
Human review
Each file is determined by an officer who can see the rule outcomes, the overview and the evidence underneath. A decision with legal effect on the applicant, or one that affects them in a similarly significant way, never rests on automated processing alone (Article 22 GDPR). Officers may depart from a rule outcome with a recorded reason, so the judgement they make is genuine.
Auditability
For each file we log what was received, every register query with its answer, the rule version and the outcome for each criterion, the overview with its sources and model version, the decision with its reasons and the letter as dispatched. In an objection or an audit you can show which rules and facts applied on the day the file was determined.
Data protection
We pull only the register fields the rules call for. Retention and destruction follow your records schedule for each type of file, processing stays in the region agreed within the EU, and case data never trains outside models. The IDPC supervises this processing in Malta.
AI transparency
Decision letters give the facts, the rules applied, the reasons and the route to object or appeal. Where a model helps prepare files, its role is documented and entered in your AI register, and published in a public algorithm register wherever one is kept.
Measures
Indicators we would track
Indicators are defined for each type of file, starting from a baseline drawn from your present case data before anything is changed.
Indicators we would track
Metric
Why it matters
How we would measure it
01Turnaround by type of file
Why it mattersWhat applicants actually feel, broken down by type so that one quick procedure does not mask a slow one.
How we would measure itDays from receipt to dispatch of the decision, and from a complete file to dispatch, taken from case timestamps.
02Files complete on arrival
Why it mattersTells you whether forms, pre-filled data and checklists stop the to-and-fro.
How we would measure itFiles that pass the completeness check at the first attempt, by channel and by type.
03Requests sent per file
Why it mattersEach request takes up the applicant’s time and gives the officer another follow-up.
How we would measure itRequests for missing items or clarification per file, grouped by reason, from the case log.
04Files beyond their legal time limit
Why it mattersThe minimum standard for timeliness set by law, and an early warning that the pile is growing.
How we would measure itOpen and closed files past the limit, and files within the alert period, by section and type.
05Consistency in sampled second reviews
Why it mattersComparable files deserve the same result, no matter which officer handles them.
How we would measure itHow often a second officer, reviewing a random sample, reaches the same decision on the same file.
06Objections that succeed
Why it mattersAn objection that succeeds points to a rule, a piece of evidence or a set of reasons that need another look.
How we would measure itObjections and appeals upheld wholly or partly, by ground and by rule version.
No targets are set before a baseline exists.
Rollout
A phased rollout
Phase 01
Discovery and analysis of the rules
A single type of file and the law behind it. We chart how files move today, express the criteria as a decision model together with your legal advisers and collect closed files, anonymised, as test cases.
Exit criteria
Rules reviewed by your legal advisers
Test cases and their expected results settled
Baseline recorded for each indicator
Data protection impact assessment and AI Act classification under way
Phase 02
Build and replay closed files
Intake, register connectors, rules and the officer workspace for the chosen type. Closed files are run again through the rules and the overview service and set against the decisions actually taken.
Exit criteria
Rule outcomes agree with the test cases, or each gap is explained
Source links verified on a sample of overviews
Register owners have approved access
Phase 03
Supervised go-live
New files of the chosen type go through the system. Officers determine them as they always have, and a sample of decisions receives a second review.
Exit criteria
Second reviews confirm consistent decisions
Section heads using the time-limit view
Runbook, monitoring and a way back in place
Phase 04
Further types of file
Additional types reuse the intake, the connectors and the workspace, each with its own rule set, test cases and legal review.
Permits, grants and social benefits handled by ministries, public entities and local councils, with register data pulled once and legal time limits tracked per procedure.
Requests handled by energy service firms for solar and connection work, with technical details checked for completeness on arrival and every request followed against its deadline.
Permits for oversized loads and road works, where route, vehicle and works details are compared with network data and other permits before an officer decides.
Illustrative example
A support scheme run by a public entity
Situation
A Maltese public entity runs a grant scheme for small businesses. Applications come in through its portal after Malta e-ID sign-in, with company documents and receipts attached as PDFs, and officers chase missing annexes by email and phone.
System
Intake checks each file against the scheme’s checklist. Information an authoritative register holds is pulled through its interface where one exists, and otherwise read from the attached document by the document intake. Eligibility and co-funding rules run as a decision model under version control, tied to the scheme’s terms, and a model compiles an overview of each file with links to the source pages.
Human control
Officers weigh and determine every application, and a second officer reviews a sample. Letters come from approved templates, and the finance system releases payment only once the decision has been signed.
What we would measure
Files complete on arrival, requests sent per file, consistency in second reviews, and turnaround per call for applications.
Malta
Files that start on servizz.gov
In Malta many applications begin on servizz.gov or an entity’s own portal, with Malta e-ID confirming who the applicant is, and the procedures themselves are set out in Chapters of the Laws of Malta and their Subsidiary Legislation. We design the case flow so that each rule set cites the Chapter or Legal Notice it reflects, and so that a new Legal Notice becomes a new rule version with its own effective date.
Since 12 December 2023, users of the procedures listed in the Single Digital Gateway Regulation may ask for evidence to pass directly between competent authorities over the Once-Only Technical System. Officers keep the decision, in line with the GDPR right not to face decisions based solely on automated processing, and AI systems used by or for public authorities to judge eligibility for essential public assistance benefits and services count as high-risk under the EU AI Act, with the MDIA leading its supervision in Malta.
No. Software opens the file, pulls data, applies the rules, compiles an overview with sources and prepares the letter. The officer weighs the file, determines it and approves the letter. Article 22 GDPR gives people the right not to be subject to a decision based solely on automated processing that has legal effects for them or affects them in a similarly significant way. We design the flow so that an officer makes a genuine judgement on every file rather than clicking to confirm.
02Where does the EU AI Act come in?
That depends on what the model is asked to do. Under Annex III, point 5(a), AI systems meant for use by or for public authorities to judge whether people qualify for essential public assistance benefits and services, or to grant, cut, withdraw or recover them, are high-risk. Point 5(b) does the same for AI that assesses the creditworthiness of natural persons, fraud detection excepted. Following the 2026 amendment, these duties apply from 2 December 2027. In Malta the Malta Digital Innovation Authority (MDIA) is the lead market surveillance authority under the Act.
Should a model take part in judging eligibility, we design for the high-risk duties from day one. By default we keep it out: versioned rules test the criteria, an officer determines the file, and the model only compiles overviews and drafts. Whether a component falls outside the high-risk category is a classification your legal advisers record, and we provide the technical description they need. Our guide to the AI Act for public entities goes into more detail.
03Must our case system be replaced?
No. The intake, rule, overview and letter services connect to your current case system through its APIs, or are built within it where the platform permits, for instance on Salesforce. Replacing the case system is a decision of its own, sensible only when that system is what holds you back; our page on legacy modernisation explains how to do it in stages.
04How do the rules keep pace with new legislation?
Every rule set is a decision model under version control, tied to the article of the Act, Legal Notice or policy clause it reflects, with test cases that spell out the expected result. When a new Legal Notice amends the rules, your legal advisers review the new version, the test cases are revised and run, and the version receives an effective date. Each file is judged under the version that applies to it, and the file keeps a record of which one that was.
05What do applicants learn about how their file was handled?
The decision letter gives the facts, the rules applied and the reasons, and sets out how to object or appeal. The portal can show which information came from which register. Where a model helps prepare files, that use is documented and, where a public algorithm register exists, entered there. Questions about status can be answered from the same case data with 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 type of file with a clear legal basis and enough volume to measure, and one rule set. That is enough to prove intake, register links, rules, overview and letter on real files before other types are added. The discovery and delivery stages are set out on our approach page.
Tell us about your types of file
Pick one type of file, the registers it relies on and the law behind it. We will sketch a first release built around that rule set.