The system assembles and checks every file. An officer makes the decision.
Applications, licences, grants, claims and appeals pass through many hands before anyone decides. We build case flows that take in structured data, ask the applicant once for anything missing, retrieve what your records already hold, apply versioned rules and prepare the letter, so officers can give their time to the assessment.
For organisations in Malaysia that handle applications and claims under their own rules and deadlines, and need every decision to hold up on appeal.
An application comes in as structured data and its completeness is checked; when something is missing, the applicant receives a single request, and the case moves on once the items arrive. The system retrieves records, applies the versioned rules and assembles a summary in which each statement points to its source. An officer assesses the case, decides, and approves the letter prepared from an approved template before it is sent and filed.
Before and after
How the work changes for officers and applicants
Today
With the system
Today
Today: Files that go back and forth
A missing attachment is spotted weeks after submission, the applicant is written to, and the file sits idle until a reply comes.
With the system
With the system: Complete from the start
Completeness is checked on arrival, and the applicant gets one request naming exactly what is still needed.
Today
Today: Asking for what you already hold
Applicants send copies of records your organisation already keeps, and staff type them into the case system again.
With the system
With the system: Records retrieved, not requested
Data your organisation already holds, or may lawfully query, is fetched through an API with the purpose logged, and shown to the officer with its origin.
Today
Today: Similar files, different results
Officers check criteria from personal notes and reuse old letters, so comparable cases can end differently and nobody can later say which version of the rules was applied.
With the system
With the system: One rule set, recorded
Criteria run as versioned decision models with test cases, letters start from approved templates, and each case file shows the rule version used.
Today
Today: Deadlines tracked by hand
Response deadlines live in spreadsheets, and older files drift to the bottom of the pile until they turn urgent.
With the system
With the system: Deadlines in plain sight
Every case carries its response deadline, supervisors see which files are at risk, and the backlog can be viewed by age and case type.
Workflow
How the flow runs
Preparation is the system’s job: intake, records, rule results, a summary with sources and a draft letter. Assessment and decision are the officer’s, with everything visible on one screen.
Illustrative workflow
7 steps · 2 human checkpoints
Legend
System
AI agent
Person
Human checkpoint
Exception path
Case processing: illustrative flow with a missing-items path
Read the diagram as text
On the main path, the application is received and checked for completeness, existing records are retrieved, the versioned rules run and a summary with sources is prepared; the officer then assesses and decides, and the path ends with preparing and sending the letter.
If the completeness check finds gaps, the case leaves the main path and the applicant receives one request naming what is missing. When the items arrive and pass the check, the case returns to the main path at the records step.
The officer’s assessment and decision is the human checkpoint, followed by the officer’s approval of the letter: the system prepares and drafts, but no decision is made and no letter goes out without a person.
01
Step 1: Receive and check completenessSystem
Applications come in as structured data from the portal, from e-forms or through the intake described under Document intelligence. The case is opened under its type, the response deadline is set from the date received, and the items that case type requires are checked.
02
Step 2: Ask for what is missingSystem
The applicant gets one request, on the channel used to apply, naming the missing items or data and the date they are needed by. Whatever arrives is checked against the same list, and the effect on the deadline is recorded as your procedure sets out.
Exception path: Items missing· Returns to step 3
03
Step 3: Retrieve existing recordsSystem
Based on the applicant’s identity, verified through the portal or, for public services, MyDigital ID, and on the purpose of the procedure, data is retrieved through APIs from your own records and from the external sources you are permitted to query. Each query is logged with its purpose.
04
Step 4: Run the versioned rulesSystem
Eligibility and calculation rules run as versioned decision models (DMN or rules as code), each tied to the legal provision or policy clause it puts into effect. The result marks each criterion as met, not met or left for the officer, with the facts and the rule version behind it.
05
Step 5: Summarise with sourcesAI agent
A model condenses the application, attachments and retrieved records for the officer: facts, dates, amounts, open points and places where sources contradict each other. Each statement links to the page or record it comes from. The summary neither judges eligibility nor suggests an outcome.
06
Step 6: Officer decidesPerson
The officer reviews the rule results, the summary and the evidence on a single screen, weighs the points the rules leave open, decides and records the reasons. A rule result may be overridden, with the reason recorded.
Human checkpoint
The decision always belongs to the officer. No decision with legal effect rests on automated processing alone, and a second reviewer can be required by case type, amount or outcome.
07
Step 7: Prepare and send the letterSystem
The letter is drafted from the approved template for that case type and outcome, with the officer’s reasons and the legal basis. After approval it is signed, sent and filed with the case. An appeal opens a linked case that carries the original file, the rule version and the reasons.
Human checkpoint
No letter is sent until the officer has approved its final wording.
Components
Components we would deliver
01
Intake and completeness checks
Takes in submissions from portals, e-forms and document intelligence, applies a checklist for each case type and requests missing items on the channel the applicant used.
Eligibility and calculation rules in DMN or code, versioned with start dates, tied to their legal source and covered by test cases your legal team can read.
One screen for evidence, rule results, summary, decision and reasons, built into your existing case system where possible, with letter templates owned by your legal team.
Case management on Salesforce Service Cloud or Public Sector SolutionsPlatformSalesforce
The case management system you already run
Identity, digital signature and seal services
Document and records management
Payments of grants and claims in SAP financePlatformSAP
Grant payments through Odoo AccountingPlatformOdoo
Notification channels: portal inbox, email and SMS
Controls
Controls built in
Access boundaries
Officers see only the case types and units their role permits. Each record query runs under the purpose of the procedure, for the fields that case type needs, and is logged with the case reference. The summary service can read the case file but has no way to alter case data, rule results or decisions.
Human review
An officer who can see the rule results, the summary and the evidence makes every decision. Under Article 22 of the EU General Data Protection Regulation (GDPR), decisions with legal or similarly significant effects on applicants in the EU may not rest solely on automated processing, and we apply the same standard to every applicant. Officers may depart from a rule result if they record why, so the assessment is a genuine one.
Auditability
The case log holds what was received, each record query with its answer, the rule version with the result for every criterion, the summary with its sources and model version, the decision with its reasons, and the final letter. An appeal or an audit can then rebuild which facts and rules applied on the decision date.
Data protection
Only the fields the rules need are retrieved. Retention and disposal follow your records schedule for each case type, processing stays at the hosting location recorded in the contract, and case data does not train external models. For private organisations, the notice under the Personal Data Protection Act 2010 (PDPA) tells applicants which records are checked and why.
AI transparency
Decision letters set out the facts, the rules applied, the reasons and how to appeal or ask for a review. Where a model helps prepare cases, its role is documented and entered in your AI register.
Measures
Measures we would agree
Each case type gets its own measures, starting from a baseline drawn from your existing case data.
Measures we would agree
Metric
Why it matters
How we would measure it
01Processing time by case type
Why it mattersThe figure applicants feel, split by case type so a quick procedure cannot mask a slow one.
How we would measure itTime from receipt to decision letter, and from complete file to decision letter, taken from case timestamps.
02Applications complete on arrival
Why it mattersShows whether forms, pre-filled data and checklists stop the back-and-forth.
How we would measure itCases passing the completeness check at first submission, by channel and case type.
03Requests sent per case
Why it mattersEach request costs the applicant time and the officer a follow-up.
How we would measure itNumber of requests for missing items or explanations in each case, grouped by reason, from the case log.
04Cases past their deadline
Why it mattersThe minimum standard for timeliness, and an early warning of a growing backlog.
How we would measure itOpen and closed cases beyond the deadline, plus cases inside the warning period, by team and case type.
05Consistency in peer review
Why it mattersComparable cases should end the same way, whoever handles them.
How we would measure itHow often a second officer, assessing the same file from a random sample, reaches the original decision.
06Appeals upheld
Why it mattersSuccessful appeals point to rules, evidence or reasons that need attention.
How we would measure itAppeals and reviews upheld fully or partly, by ground and by the rule version applied.
No targets are set before a baseline exists.
Rollout
Rollout in stages
Phase 01
Discovery and rule mapping
One case type and its legal or policy basis. We map how cases run today, write the criteria as a decision model with your legal team and gather past cases, with personal data removed, as test cases.
Exit criteria
Rule set reviewed by your legal team
Test cases and expected outcomes agreed
Baseline recorded for each measure
PDPA review and EU AI Act classification begun
Phase 02
Build, then replay past cases
Intake, record connectors, rules and the officer workspace for the chosen case type. Past cases are run again through the rules and the summary service and compared with the decisions actually taken.
Exit criteria
Rule outcomes match the test cases, or each gap is explained
Source links checked on a sample of summaries
Data owners approve record access
Phase 03
Live for one case type
New cases of the chosen type go through the system. Officers decide as before, and a sample of decisions goes to peer review.
Exit criteria
Peer review finds decisions consistent
Supervisors using deadline monitoring
Runbook, monitoring and rollback ready
Phase 04
Further case types
Additional case types reuse the intake, connectors and workspace, each with a rule set, test cases and legal review of its own.
Licence, grant and assistance applications at federal agencies, statutory bodies and local authorities, with MyDigital ID login, existing records reused and response deadlines monitored per procedure.
Claims and complaints at insurers and takaful operators, with cover rules versioned by policy wording, claims officers deciding and complaint deadlines in view.
Pre-authorisation and reimbursement requests at private hospitals and third-party administrators, with each scheme’s rules versioned and medical assessment left to qualified staff.
Connection and installation requests at renewable energy developers and solar EPC firms, with technical data checked on arrival and each request tracked to its deadline.
Damage and loss claims at logistics firms and freight forwarders, with shipment data checked against delivery records before an officer decides.
Illustrative example
Admission and credit transfer applications at a private university
Situation
A private university could receive admission and credit transfer applications through one portal, with transcripts and certificates attached as PDFs. Admissions staff would chase missing documents by email and check entry requirements from their own notes.
System
Intake would check each application against a checklist for its programme. Entry and credit transfer rules would run as a versioned decision model, and a model would summarise each file with links to the source pages.
Human control
The registrar’s office assesses and decides every application, and a second officer reviews a sample. Letters come from approved templates, and the PDPA notice tells applicants how their documents are checked.
What we would measure
Applications complete on arrival, requests sent per case, consistency in peer review, and processing time per intake.
Malaysia
Officers decide, under Malaysian and EU rules
Public bodies in Malaysia can let applicants sign in with MyDigital ID, the national digital identity, so that records are retrieved for the right person and nobody is asked again for data the agency already holds. The Personal Data Protection Act 2010 (PDPA) does not apply to the Federal and State Governments; for their procedures we work to the government’s own policies and guidelines.
Private organisations, such as insurers, universities and hospitals, process applications under the PDPA: a notice to the applicant, data used for the stated purpose and, since 1 June 2025, notification of a personal data breach to the Personal Data Protection Commissioner, within 72 hours under the Commissioner’s guidance. Where applicants are in the EU, the EU General Data Protection Regulation (GDPR) protects them from decisions based solely on automated processing, and the EU AI Act sets high-risk duties for certain eligibility and credit assessments.
No. The system opens the case, retrieves data, runs the rules, writes a summary with sources and drafts the letter. The officer assesses the case, decides and approves the letter. For applicants in the EU, Article 22 of the GDPR gives people the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects on them. We design every flow so that a person makes a real assessment rather than a confirmation click, wherever the applicant is.
02Does the EU AI Act matter for a Malaysian organisation?
Only where it reaches you: when you place an AI system on the EU market, or when the output of a system you use is used in the EU (Article 2). Within that scope, the Act classes as high-risk any AI used by or for public authorities to judge eligibility for essential public assistance benefits and services (Annex III, point 5(a)), and AI that evaluates the creditworthiness of natural persons, fraud detection excepted (point 5(b)). Under the Act as amended in 2026, these obligations apply from 2 December 2027.
If a model is to take part in judging eligibility, we design for the high-risk obligations from the outset. By default we keep the model out of it: versioned rules test the criteria, an officer decides, and the model only summarises and drafts. Whether a component stays outside the high-risk category is a classification your legal team records, and we supply the technical description it needs. See the EU AI Act guide.
03Must we replace our case management system?
No. The intake, rule, summary and letter services link to the case system you run through its APIs, or sit inside it where the platform permits, for instance on Salesforce. Replacing the case system is a decision of its own, sensible only if that system is the real constraint; the page on Legacy modernisation explains a stepwise route.
04How do the rules keep up with changes in law and policy?
Every rule set is a versioned decision model tied to the section or policy clause it implements, with test cases stating the expected result. When an Act, a regulation or an internal policy changes, your legal team reviews the new version, the test cases are updated and run, and the version receives a start date. Each case is assessed under the version that applies to it, and the case file records which one.
05How do applicants learn how their case was handled?
The decision letter sets out the facts, the rules applied and the reasons, and explains how to appeal or ask for a review. The portal can show which records were retrieved and from where. Where a model helps prepare cases, that use is documented. Status questions can be answered from the same case data through Service assistance, and where the service reaches people in the EU, anyone dealing directly with an AI system is told so, as Article 50 of the AI Act has required since 2 August 2026.
06How large should the first release be?
One case type with a clear legal or policy basis, enough volume to measure and a single rule set. It proves intake, record connections, rules, summary and letter on live cases before further types follow. Our delivery approach describes the discovery and delivery phases.
Start with one case type
Name one case type, the records it relies on and who applies. We will sketch a first release around that rule set.