Monitoring council minutes and resolutions

The department monitors public council minutes and resolutions published on open government portals and open-data registers. A few times each week, new documents appear across these sources, and two case officers are responsible for reading through them, identifying topics that are relevant to their municipality or department, summarising the findings, and alerting the right colleague or department head in time to act. The process also includes filing a record of each review so that decisions can be traced and justified if challenged under administrative procedure law. In total, this cycle runs roughly 600 times per year, with each pass taking an average of 40 minutes of staff time, adding up to around 400 hours of manual reading and classification annually.

The difficulty is not the logistics of finding documents but the judgement involved in reading them. Council minutes are written in natural language, cover a wide range of topics, and do not follow a single consistent format across different publishing bodies. Deciding whether a given resolution is relevant, which items within it need escalation, and who should receive the alert requires a combination of domain knowledge and contextual judgement. About a quarter of cases involve some ambiguity that cannot be resolved without a human making a call. The remaining three quarters are broadly routine: the topic is clearly within scope, the relevant passage is identifiable, and the right recipient is obvious.

Currently the process lives across email and shared spreadsheets, with no single system owning the full workflow. This creates a dependency on the tacit knowledge of a small number of people, and delays when staff are unavailable. The goal is to automate the routine majority while keeping humans firmly in the loop for exceptions and for any output that could trigger an official action.

The recommended path is an AI Workflow: a structured, automated pipeline that ingests newly published documents from open-data sources, runs them through a natural-language processing model to detect topics of interest, generates plain-language summaries for matched items, and routes alerts to the appropriate case officer or department head. Exceptions and low-confidence matches are held in a human review queue rather than acted on automatically. This design fits the process almost exactly because the core task, reading and classifying unstructured text, is precisely what modern language models do reliably when given a well-defined topic taxonomy and a calibrated confidence threshold.

The case for an AI Workflow over the alternatives comes down to what the hard part of this process actually is. RPA can retrieve documents from websites but cannot read or understand them, so it would automate only the first step and leave the real work untouched. A Traditional Code approach using keyword matching or regular expressions could catch obvious cases cheaply, but council minutes use varied language, and maintaining an expanding ruleset to keep pace with evolving policy topics would quickly become its own manual burden. An AI Agent capable of browsing, reasoning, and taking autonomous actions is more power than this process needs and introduces unpredictability that is genuinely hard to justify under administrative procedure law, where every decision must be traceable and defensible. The Hybrid path scored almost as high as the AI Workflow and is worth considering: the practical difference between the two is whether the human sign-off gate is a hard architectural requirement or a configurable option. If the legal or compliance team requires a formal review before any alert is acted on, the implementation can be adjusted to enforce that gate without changing the underlying technology. The AI Workflow recommendation already assumes that no automated output triggers official action without a human having approved it, so the gap between the two paths is narrow.

The client has no stated technology preference and is constrained by central IT and public procurement rules. This is an important constraint, not a footnote. The recommendation is therefore to build on open-source language models or EU-compliant cloud NLP services, deliver outputs via email and a lightweight web dashboard, and avoid any integration that would require central IT involvement or a formal procurement process in the first version. Open-data sources reduce integration risk significantly: the pipeline can pull documents directly from public registers without touching internal systems. Topic definitions should be manageable by non-technical staff through a simple interface, because policy priorities will shift and the team cannot wait for IT to update configuration files every time they do.

There is an honest tradeoff to name here. An AI Workflow built to this specification will not be perfect out of the box. Detection quality depends on how well the topic taxonomy is defined at the start and on feedback from case officers during the pilot period. A classifier that is tuned too conservatively will pass too many borderline items to the exception queue, which defeats the purpose; one tuned too aggressively will let relevant items slip through unnoticed, which is exactly the failure the system is meant to prevent. Getting that calibration right takes a structured pilot phase and a genuine feedback loop, not just a launch. The build and pilot effort is estimated at 13 to 18 weeks depending on scope, with a total cost between EUR 8,000 and EUR 18,000. At an estimated 70% reduction in manual reading time, the projected annual saving is around EUR 7,000, giving a payback period of roughly 18 months. That is a reasonable return for a public-sector automation of this type, and the non-financial benefit of earlier awareness of relevant council decisions is harder to quantify but arguably more important.

The top two paths, AI Workflow and Hybrid, are close in score and share almost all of their technology. The real difference is governance design. An AI Workflow routes routine matches directly to case officers as email summaries and sends low-confidence items to a human review queue, but it does not impose a mandatory sign-off step before a summary reaches the recipient. A Hybrid adds a formal human-in-the-loop gate, meaning every output, routine or not, is reviewed before it is acted upon. For a process governed by administrative procedure law where decisions must survive appeal, that additional defensibility is genuine and not just bureaucratic caution. The reason AI Workflow still wins the recommendation is that the process already has a natural exception path built in: borderline and ambiguous cases are escalated by design, and the roughly 75% of routine cases carry low risk if the detection quality is high and every output is fully traceable to its source document. Adding a mandatory gate to the routine majority would recover very little in terms of legal protection while eroding most of the time savings.

Traditional Code scores considerably lower and is worth addressing directly because it will come up as a cheaper alternative during procurement discussions. A keyword or regex-based scraper can handle document retrieval and basic alerting at minimal cost, and it carries no AI procurement risk. The problem is that council minutes are natural-language documents where relevance is contextual. A resolution about housing development may be highly relevant when it concerns a boundary the department manages and entirely irrelevant when it concerns a different municipality, and a keyword match cannot make that distinction reliably. The maintenance burden of a rule-based system grows as policy priorities shift, and the exception rate, which is already around 25%, would likely stay elevated rather than improve over time. Traditional Code is a reasonable fallback if AI procurement stalls, but it should be understood as a temporary measure rather than a destination.

RPA and AI Agent both score low and for different reasons. RPA is well suited to navigating fixed UI screens and copying structured data, but it cannot read and classify unstructured document text, so it would automate only the retrieval step and leave the analytically hard part entirely untouched. An AI Agent capable of autonomous multi-step reasoning would technically handle the full task, but the process is linear enough that the additional autonomy adds unpredictability without adding value, and autonomous action is difficult to justify under administrative procedure law where every output must be explainable and traceable.

The pipeline starts with a scheduled fetch job that polls identified public council portals and open-data registers for newly published documents. In the Dutch and Belgian public sector context, many municipalities publish minutes via overheid.nl, lokale besturen registers, or equivalent open-data endpoints, typically as PDF or HTML. A lightweight Python-based fetcher, run on a small cloud VM or a managed service such as Azure Functions or AWS Lambda, checks these sources on a configurable schedule, compares against a log of already-processed documents, and downloads only new items. This step requires no deep IT integration and no access to the client's internal systems, which keeps it outside the central IT procurement perimeter for the initial build.

New documents are passed to a text extraction and classification layer. PDF text is extracted using a library such as pdfplumber or Apache Tika, and the resulting plain text is chunked into sections corresponding to agenda items or resolution paragraphs. Each chunk is then scored against the department's topic taxonomy using a language model. For a public-sector client subject to GDPR and data residency concerns, the practical choices are an open-source model such as a quantised Llama or Mistral variant running on the client's own infrastructure, or an EU-hosted cloud NLP service such as Azure OpenAI deployed in a European region. The model is prompted with the defined topic list and asked to identify matches, assign a confidence level, and produce a short plain-language summary of each matched item. Crucially, the prompt and the model's output are both logged alongside the source document reference and a timestamp, satisfying the audit and traceability requirements from the outset.

The routing layer reads the confidence score on each flagged item and applies a threshold that the team can adjust without touching code. Items above the threshold generate an email summary delivered to the relevant case officer, identified by mapping topic categories to named recipients in a simple lookup table maintained as a spreadsheet or lightweight web form. Items below the threshold, or items the model has flagged as ambiguous, are added to a review queue. That queue can be as simple as a shared folder of structured JSON files rendered into a readable format, or a minimal web dashboard built with a tool such as Streamlit or Retool, showing the source document, the model's reasoning, and a one-click approve or dismiss action. Every action taken in the queue is logged. No automated summary triggers any official action until a human has reviewed and approved it, which satisfies the hard design constraint imposed by administrative procedure law.

During the pilot phase, case officers use the review queue's feedback mechanism to mark false positives and missed items. This feedback is collected weekly and used to adjust either the confidence threshold or, if systematic gaps appear, to fine-tune the topic definitions. The department head reviews the exception queue to set the threshold at a level that balances recall against queue volume. After the pilot, a simple topic-management interface, a spreadsheet or a short web form, allows non-technical staff to add or retire topic definitions without raising an IT change request. A quarterly review cadence, agreed at handover, keeps the taxonomy aligned with shifting policy priorities and prevents the system from drifting out of calibration silently.