The system assembles and checks the file. An authorised officer decides.
Insurance claims, licence and permit applications, scheme benefits and grievances pass across many desks before anyone takes a decision. We would build case flows that accept structured submissions, ask the applicant once for whatever is missing, pull documents already held in DigiLocker or your own records with consent, apply versioned rules and draft the order, so officers spend their time on the assessment itself.
For Indian insurers and government departments handling claims and applications at volume, each with its own rules, records and time limits.
A claim or application arrives as structured data and is checked for completeness. If something is missing, the applicant receives a single request, and the case resumes once the items arrive. The system then fetches documents and records held elsewhere, applies the versioned rules and assembles a summary in which each statement points to its source. An authorised officer assesses the case and decides, then approves the order drafted from an approved template before it is issued and filed.
Before and after
How the work changes for officers and applicants
Today
With the system
Today
Today: Files that keep returning
A missing annexure is spotted weeks after filing, a letter goes out asking for it, and the case sits idle in the meantime.
With the system
With the system: Complete at the point of filing
Completeness is checked when the case is filed, and the applicant gets one request naming exactly what is missing.
Today
Today: Papers the system already holds
Applicants upload certificates and records that another department or your own system already has, and staff key them in again.
With the system
With the system: Records fetched, not demanded
Documents held in DigiLocker or in your own systems are retrieved with the applicant’s consent through an API, the purpose is logged, and the officer sees where each one came from.
Today
Today: Similar cases, different results
Each officer applies the criteria from personal notes and drafts the order from an old file, so comparable cases can end differently and no one can later show which version of the rules was used.
With the system
With the system: One rule set, recorded
Every criterion is evaluated by a decision model that carries a version number and its own tests; orders are generated from templates the legal cell has approved, and the file notes the rule version used.
Today
Today: Time limits tracked on paper
The time allowed for each case is followed in registers or spreadsheets, and older files drift to the bottom of the pile until someone escalates them.
With the system
With the system: Every time limit visible
Each case carries its time limit, section heads see which files are at risk, and pending cases can be viewed by age and type.
Workflow
Step by step
The system handles the groundwork: intake, records, rule results, a summary with sources and a draft order. Assessment and decision belong to the officer, who sees everything on a single 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
The main line runs from filing and checking the case, through fetching records already held, running the versioned rules and drafting a summary with sources, to the officer’s assessment and decision, and closes with drafting and issuing the order.
Gaps found by the completeness check send the case off the main line: the applicant gets a single message naming what is needed. Once those papers come in and pass, the case resumes at the fetching step.
The officer’s assessment and decision is where a person must act, followed by the officer’s approval of the order: the system prepares and drafts, but nothing is decided and nothing is sent without a person.
01
Step 1: File and check the claim or applicationSystem
A claim or application is received as structured data, whether typed into the portal, sent through an e-form or passed on by the Document intelligence intake. A case of the right type is opened, its time limit starts from the day of receipt, and the documents required for that type are ticked off.
02
Step 2: Ask once for what is missingSystem
One message goes back to the applicant, through the channel used for filing, naming each missing paper or detail and the date it is due. Whatever comes in is tested against that list, and the procedure’s rule on pausing the time limit is applied and noted.
Exception path: Papers missing· Returns to step 3
03
Step 3: Fetch records already heldSystem
On the basis of the applicant’s identity, consent and the purpose of the procedure, issued documents are fetched from DigiLocker and records from your own or partner systems through their APIs, for example over API Setu where a department offers one. Every query is logged with its purpose.
04
Step 4: Run the versioned rulesSystem
Eligibility criteria and calculations are encoded as decision models in DMN or as rules in code, each carrying a version and a reference to the policy clause, scheme guideline or government order behind it. For every criterion the result reads met, not met or for the officer to judge, along with the facts relied on and the version applied.
05
Step 5: Draft a summary with sourcesAI agent
A model condenses the application, attachments and fetched records for the officer: facts, dates, amounts, open points and conflicts between sources. Each statement links to the page or record it came from. The summary neither judges eligibility nor recommends an outcome.
06
Step 6: Officer assesses and decidesPerson
On a single screen the authorised officer reviews rule outcomes, summary and underlying papers, judges whatever the rules left open, decides and writes down the reasons. If the officer disagrees with a rule outcome, it can be set aside with a justification on record.
Human checkpoint
The decision always belongs to the officer. No decision with legal effect rests on automated processing alone, and a maker-checker step can be required by case type, amount or outcome.
07
Step 7: Draft and issue the orderSystem
A draft order is generated from the template approved for that case type and result, carrying the officer’s reasons and the legal basis. After approval it is signed, dispatched and filed. Any appeal or grievance starts a linked case that inherits the original file, the rule version and the reasons.
Human checkpoint
No order leaves the office until the officer has approved its final wording.
Components
Components we would deliver
01
Intake and completeness checks
Takes in portal filings, e-forms and output from document intelligence, ticks off a checklist per case type and asks the applicant for missing papers through the channel they chose.
API clients for DigiLocker, API Setu and your own or partner systems, each fetching only what the procedure needs and logging the purpose of every query.
Criteria and calculations kept in DMN or code, each version dated, each rule traced to the law, scheme guideline or policy wording behind it, with tests readable by your legal cell.
A single view of papers, rule outcomes, summary, decision and reasons, preferably inside the case system you already use, with templates for orders maintained by your legal cell.
Role settings decide which case types and offices each officer can open. Fetches of records and documents run only for the procedure’s purpose and with the applicant’s consent, cover just the fields that case type needs, and are logged against the case number. The summary service has read access to the file and no power to change data, rule outcomes or decisions.
Human review
Every decision is taken by an officer who sees the rule results, the summary and the evidence beneath them. No decision with legal or similarly significant effect rests on automated processing alone; for applicants whose data falls under the GDPR, its Article 22 sets the same limit. An officer may depart from a rule result with a recorded reason, so the assessment is genuine.
Auditability
Per case, the trail holds what was received, each fetch with its response, the rule version and the result per criterion, the summary with sources and model version, the officer’s decision and reasons, and the order exactly as issued. That lets an appeal, a grievance or an audit see which rules and facts were in force on the day.
Data protection
Fetches stop at the fields the rules use. Each case type keeps and destroys records according to your retention schedule, processing remains in the region agreed, and no case data is used to train external models. Notices to applicants can carry the itemised content that rule 3 of the DPDP Rules prescribes from May 2027.
AI transparency
Every order sets out the facts, the rules used, the reasons and the route for an appeal or grievance. If a model helps prepare files, that role is written down and listed in your AI register, and for deployments that serve the EU the documentation the EU AI Act asks for is prepared alongside.
Measures
How success would be measured
Each case type gets its own measures, and the baseline comes from the case records you hold today.
How success would be measured
Metric
Why it matters
How we would measure it
01Turnaround per case type
Why it mattersWhat applicants actually notice, split by case type so that one quick procedure does not mask a slow one.
How we would measure itDays from filing to order issued, and from complete file to order issued, taken from case timestamps.
02Complete files at first filing
Why it mattersShows whether forms, pre-filled data and checklists stop the back-and-forth.
How we would measure itCases that clear the completeness check on first submission, by channel and case type.
03Requests sent per case
Why it mattersEvery extra request delays the applicant and gives the officer another follow-up.
How we would measure itNumber of requests for papers or clarification in each case, split by reason, drawn from the case log.
04Files beyond their time limit
Why it mattersThe minimum standard for timeliness, and an early warning of growing pendency.
How we would measure itOpen and closed cases beyond the limit, and those inside the warning window, by section and case type.
05Consistency in sampled review
Why it mattersSimilar cases should end the same way whoever handles them.
How we would measure itHow often a second officer, looking at the same file in a random sample, reaches the original decision.
06Appeals allowed
Why it mattersSuccessful appeals point to rules, evidence or reasons that need attention.
How we would measure itAppeals and grievances succeeding wholly or partly, broken down by ground and by rule version.
No targets are set before a baseline exists.
Rollout
Phased rollout
Phase 01
Discovery and rule mapping
A single case type and the law or policy it rests on. Together with your legal cell we chart today’s case journey, express the criteria as a decision model and collect anonymised historical cases to test against.
Exit criteria
Rules reviewed by the legal cell
Test cases and expected outcomes agreed
Baseline recorded for each measure
Privacy assessment begun and EU AI Act relevance checked
Phase 02
Build and replay
Intake, connectors, rules and officer workspace for that case type. Historical cases are fed through the rules and the summary service again, and the results are set against the decisions taken at the time.
Exit criteria
Rule outcomes match the tests, or each gap is explained
Summary references spot-checked
Data owners approve record access
Phase 03
Live with oversight
Fresh cases of that type flow through the system. Officers keep deciding as they did, while a second officer looks over a sample.
Exit criteria
Sampled review shows consistent decisions
Section heads use time-limit warnings
Runbook, monitoring and rollback ready
Phase 04
Further case types
Additional case types reuse the intake, connectors and workspace, each with its own rules, tests and legal review.
Trade licences, building permissions and scheme benefits at State departments and urban local bodies, with records fetched once and time limits tracked per service.
Cashless pre-authorisation and reimbursement requests at hospital groups, with each payer’s rules versioned and medical judgement left to qualified staff.
New connection and load-change requests at distribution companies, with technical details checked at filing and every request tracked against its time limit.
Oversized cargo and road-cutting permits, where the planned route, the vehicle and the works are tested against the road network and permits already granted before an officer decides.
Illustrative example
Permit applications at a State department
Situation
A State department issues trade and building permits through an online portal. Applicants upload identity and property papers as PDFs, many of which already exist in DigiLocker, and officers chase missing annexures by phone and email.
System
Intake would check completeness against a checklist per permit type. With the applicant’s consent, issued documents would be fetched from DigiLocker, and the rest would pass through document intelligence. Fee and eligibility rules would run as a versioned decision model, and a model would summarise each file with links to the source pages.
Human control
Authorised officers would assess and decide every application, with a second officer reviewing a sample. Orders would come from approved templates, and no permit would be issued until the officer had signed the order.
What we would measure
Share of complete files per permit type, requests per case, consistency in sampled review, and turnaround from filing to order.
India
Claims and applications under Indian procedure
Insurers, State departments and urban local bodies in India process claims, licences and scheme applications at scale, each under its own policy wording, government order or scheme guideline. Many supporting papers already exist in digital form: DigiLocker, run by the National e-Governance Division (NeGD), stores, shares and verifies issued documents, and API Setu is another NeGD project. We design one case flow that fetches what is already held, with consent, and asks the applicant only for what is missing.
From May 2027 the DPDP Rules bring in itemised notices, security safeguards and breach intimation for the personal data held in case files, while decisions stay with authorised officers. If an Indian provider supplies a system like this for use in the EU, the EU AI Act classes AI that public authorities use, directly or through others, to assess eligibility for essential public assistance as high-risk.
01Is it the system that decides claims or applications?
No. The system opens the case, fetches records, runs the rules, writes a summary with sources and drafts the order. The officer assesses, decides and approves the order. We design the flow so that a real assessment takes place in every case rather than a confirming click. Where the GDPR applies, its Article 22 protects people against decisions based solely on automated processing, and we apply that principle to every applicant.
02Does the EU AI Act matter to an Indian organisation?
It can. Article 2 extends the Act to providers based outside the Union that put AI systems on the EU market, and to third-country providers and deployers whose system output is used inside the EU. Annex III, point 5(a) classes as high-risk any AI system that public authorities, or others on their behalf, use to judge eligibility for essential public assistance benefits and services; point 5(b) does the same for credit scoring of individuals, with fraud detection excluded. Following the 2026 amendment, those obligations take effect on 2 December 2027.
Where a process stays inside India, MeitY’s India AI Governance Guidelines of November 2025 apply only as non-binding guidance. Either way, our standard design keeps the model away from eligibility: rules carrying versions test the criteria, the officer decides, and the model merely summarises and drafts. Your legal team records whether a component sits outside the high-risk category, and we provide the technical description for that record. The EU AI Act guide goes deeper into the obligations.
03Is a new case-management system needed?
Not necessarily. The intake, rules, summary and order services plug into the case system you run today through its APIs, or sit within it if the platform permits, as on Salesforce. Whether to replace the case system is a separate question, worth asking only if that system is what holds you back. Legacy modernisation describes a staged way to do it.
04How do the rules keep pace with new government orders and policy changes?
Every rule set is a decision model with a version number, tied to the section, scheme guideline or policy clause it encodes, and accompanied by tests that state the expected result. When that basis is amended, the legal cell reviews the revised model, the tests are adjusted and rerun, and the new version is given a commencement date. A case is judged under whichever version governs it, and its file keeps a note of that version.
05How do applicants learn how their case was handled?
Each order sets out the facts, the rules used and the reasons, together with the route for an appeal or a grievance. On the portal, applicants can see which records were fetched and from which source. Any role a model plays in preparing cases is written down. Service assistance can answer status queries from the same case data; for people in the EU dealing with an AI system directly, Article 50 of the EU AI Act has required disclosure since 2 August 2026.
06What would a first scope cover?
A single case type with a clear basis in law or policy, volume enough to measure and one rule set. Live cases then test intake, record fetches, rules, summary and order before more types are added. Our delivery model covers the discovery and delivery phases.
Share your case types
Pick one case type and tell us which records it relies on and which rules govern it. We will sketch a first release built around that rule set.