Municipal workflows

Applications checked against the rules. Decisions made by your staff.

Municipal services run on applications, supporting documents and rules that differ by category. Liba helps a municipality turn that work into a governed workflow: documents are read and checked against defined requirements, routine gaps are handled consistently, and every exception goes to an employee who makes and records the decision.

How the workflow runs

Case study

A municipal application service

Applications arrive steadily, the documents are familiar (identity documents and, for some routes, a lease, an employer’s letter or a rental contract), and the rules differ by eligibility route. Much of the work is checking that the documents agree with each other and with the rules.

What is checked

• Whether the documents required for the applicant’s eligibility route are present.
• Whether the details agree across the application and the documents: applicant, address and the other key details.
• Which validity period applies under the approved rules table for that route, and whether a non-default period needs a recorded reason.
• Whether the case matches a defined outcome or needs a person.

Where people decide

The workflow gives each part one job: AI reads and extracts, rules approved by the municipality decide what the checks mean, and an employee approves. Each check leads to one of four outcomes.

Valid

The system recommends approval and the validity period. An employee confirms.

Missing or incorrect document

The resident is asked for that document only. When it arrives, it is attached to the original request and checked again.

Exception or conflict

The case goes to an employee with all the evidence. Nothing is decided automatically.

Not eligible

A reasoned rejection based on an approved rule, reviewed by an employee.

The workflow covers the most common eligibility route. Exceptions, intake by post or at the reception desk, and cancellations stay with employees.

How supporting information stays traceable

Each case keeps the source documents, the extracted fields, every check and its result, the versions of the rules and model used, the recommendation, and the employee’s decision with any reason given. A decision made months ago can be reviewed from the case history instead of being reconstructed from memory.

Integration requirements

The workflow sits on top of the systems the municipality already runs and does not replace the system of record. In this project that means:

• Reading and updating cases in the existing permit or case-management system, through its interface (API) where one exists.
• Access to the information sources the rules depend on, such as the resident registry and other municipal data, subject to the municipality’s permissions and approvals.
• The municipality’s identity provider for staff sign-in and roles.
• Email or SMS for resident notices, once the municipality decides which channel applies to each route.

Only one step in the workflow writes to the system of record: updating the case after an employee has approved. Every other step reads or prepares. Screen automation is considered only where no interface exists, and only as a temporary measure. If a connection fails or times out, the case returns to an employee rather than stalling.

What has to be decided first

Some questions are policy rather than technology, and the municipality has to settle them before development. In this project they included:

• the exact fee version and its exceptions;
• the approved validity period for each eligibility route;
• the documents required for special categories;
• which notices go by email, by SMS or by both;
• which information sources may be queried in real time, and with what permissions;
• whether the pilot only recommends or also carries out approvals.

Each of these needs an owner and a date. Until they are settled, the workflow can be built but should not be relied on.

How a municipal pilot is staged

1. Close the rules. Owners, documents, validity and fees agreed in writing.
2. Build the first version for one route.
3. Shadow mode. The system proposes a decision but changes nothing in the system of record. Its recommendations are compared with employees’ actual decisions.
4. Controlled pilot. Employees approve with the system’s support, and time and accuracy are measured.
5. Expand to further routes, intake channels and integrations only after accuracy has been shown.

The criteria for leaving shadow mode are agreed in advance. In this project they are demonstrated accuracy, no incorrect approvals in the review sample, and high agreement with employee decisions.