Reading & motion

Stops motion. Your device’s reduced-motion setting always takes priority.

Knowledge tracks & learning

Shared knowledge.

Find presentations, practical experience and sources on the same topic — across the network's meetings. Start with the question that matters to your work.

Find the right material

Search the knowledge library

315 entries across experience, guides, presentations, resources and AI terms. Search the entire collection, including material not shown on this page.

1–6 of 315 results

Practice & learningAI Alliancen

Our code — AI Alliancen

AI Alliancen connects municipal experience, research and technical insight — and turns it into shared knowledge.

Open material
Practice & learningVejle

Bertha: AI support where employees already work

Developed with InDialog, Bertha is available on the municipal intranet. Staff use it to find guidance, proofread and make public-facing text easier to understand. Intranet content informs its answers and needs ongoing maintenance. The Danish Agency for Digital Government also describes training in prompting and critical assessment, alongside legal involvement, risk assessments and a data-processing agreement during implementation.

Open material
Practice & learningKalundborg

Project Andrea: one entry point for municipal AI tools

Project Andrea brings generative AI tools together in one app for municipal employees. The initiative originated in Kalundborg Municipality and was developed with Promte. The solution is in operation in Kalundborg. KL's earlier case also describes risk assessments for assistants.

Open material
Practice & learningAarhus

AarhusAI and OS2ai: from a local platform to shared capability

AarhusAI brings general and specialist assistants together for employees. The platform is shared through OS2 as OS2ai. Its documented capabilities include document analysis, organisational sources through RAG and shared assistants. It combines open-source and source-available components; model selection, hosting and operation require local decisions. Aarhus ITK has also described AI training and network events as part of its work on staff capability.

Open material
Practice & learningCopenhagen

Talt: from spoken notes to draft home-visit descriptions

Copenhagen, Aarhus, Aalborg and Systematic developed prototypes tested in 2024–2025 with staff from 11 municipalities. One use case combined speech recognition and a language model: dictation became text and then a draft visit description for staff to review and edit. The trials used synthetic citizens and records. The project also publishes code, datasets and technical reports.

Open material
Practice & learningGladsaxe

RoboRef: more attention during conversations with citizens

Gladsaxe describes RoboRef being used in its Family Department and Social and Health Administration. Speech-to-text and generative AI turn the meeting into draft minutes, which staff read, edit and approve. The municipality's information on AI minutes also describes informing citizens and states that individual case records are not used to train models.

Open material
Learning from the network's meetingsSix practice perspectives with the original learning points and sources.

Shared knowledge · put into practice

What we are
learning.

Key takeaways from the network’s meetings

The network's practice tracks connect hands-on experience with standards, sources and actionable approaches. Use them to improve decisions on governance, security, development and operations.

01Governance

AI becomes an operational capability

Presentation: Jesper Schmidt · Sønderborg

Copilot Credits are a shared unit of consumption for Microsoft’s AI services. Pre-purchased capacity can be combined with pay-as-you-go, and consumption can be managed through budgets, alerts and limits. Credits should therefore be treated as an operational resource: every use case needs an owner, an environment, a budget and an agreed response to deviations. Microsoft describes the Default environment as suitable for experimentation and lightweight development, not business-critical solutions. Governance consequently spans finance, security, law, product ownership and continuous change management.

Explore the learning & sources

Editorial synthesis of the meeting and the sources below. This is not a quotation or an endorsement by the presenter.

  • Measure AI consumption and assign a budget, alert and accountable owner to every solution.
  • Separate experimentation, development, testing and production in governed environments.
  • Bring product, finance, operations, security and legal expertise into shared decisions.
Read on a dedicated page
02Development

Vibe coding with a production gate

Presentation: Daniel Corydon-Petersen · Gladsaxe

Vibe coding can shorten the route from need to prototype, but responsibility for software in operation remains unchanged. GitHub recommends checking function, context, security, maintainability and dependencies, supported by automated tests and human review. A responsible municipal model therefore gives low-risk prototypes an isolated experimentation track, followed by a clear production gate. Otherwise, the maintenance burden and technical debt appear only after the impressive demonstration.

Explore the learning & sources

Editorial synthesis of the meeting and the sources below. This is not a quotation or an endorsement by the presenter.

  • Give low-risk prototypes a fast but isolated experimentation track.
  • Require a repository, system owner, tests, scanning and qualified review before production deployment.
  • Plan patching, monitoring, backups and decommissioning from the outset.
Read on a dedicated page
03Development

Agentic engineering as a discipline

Presentation: Kim Stannov Søvsø · Aarhus

A coding agent can inspect a repository, make a plan, change several files and run tests, documentation and review tools. This makes agentic engineering more than code generation. Versioned Agent Skills and repository instructions can make organisational standards repeatable, but people still own the process: acceptance criteria, bounded implementation, automated controls, independent review and approved release.

Explore the learning & sources

Editorial synthesis of the meeting and the sources below. This is not a quotation or an endorsement by the presenter.

  • Store shared standards as versioned instructions and skills in repositories.
  • Give the agent clear acceptance criteria and something against which it can verify its work.
  • Keep people accountable for design, review, release, risk and operations.
04Security

Claude Code, security and AI-assisted interpreting

Presentation: Morten Ingemann Zeiner · Hillerød

Claude Code can access files, commands and external tools. A security assessment must therefore cover permissions and data flows, not only the model. For AI-assisted interpreting in schools and early-years settings, a lawful basis for processing does not come with the product. The authority must document purpose, necessity, proportionality and legal basis; children’s data require especially strict data minimisation and risk controls.

Explore the learning & sources

Editorial synthesis of the meeting and the sources below. This is not a quotation or an endorsement by the presenter.

  • Combine managed permissions with file-system and network sandboxing.
  • Assess the purpose, data and public task in the specific context.
  • Clarify the DPIA, data-processing agreement, retention, transfers and human oversight.
05Architecture

A modular public-sector AI platform

Presentation: Astrid Vestergård Greulich · Copenhagen

A modular platform is not one large chatbot, but a separation between shared capabilities and specific service solutions: identity, integrations, search, model gateway, logging and a governed release path. A use-case register can connect every product with its purpose, owner, data, risk, cost and service level. Open standards, documented data exports and replaceable components reduce vendor lock-in.

Explore the learning & sources

Editorial synthesis of the meeting and the sources below. This is not a quotation or an endorsement by the presenter.

  • Build reusable, loosely coupled capabilities with clear interfaces.
  • Connect every use case with its purpose, owner, data, risk and costs.
  • Preserve the ability to change models and suppliers through portability and standards.
06Security

Agent Harness: control outside the model

Presentation: Parthee Vijayamohan · Kalundborg

Agent Harness moves enforcement out of the model and into a shared, vendor-neutral control framework. The proposal is not an adopted standard; the model must not itself be the security enforcement point. A signed execution manifest binds identity, purpose, data, versions, tools, network access and approvals. Execution is isolated, while access to models, tools, secrets and networks passes through external gateways using deny-by-default and least privilege.

Explore the learning & sources

Editorial synthesis of the meeting and the sources below. This is not a quotation or an endorsement by the presenter.

  • Place enforcement outside the model and keep it independent of the agent engine.
  • Bind each run to a manifest and enforce access through isolation and gateways.
  • Retain evidence covering code, builds, policies, tests, approvals and release.
Read on a dedicated page
Agent Harness · technical deep diveThe architecture proposal, four control steps and its technical foundation.

Technical deep dive · architecture proposal

Control that sits
outside the agent.

Agent Harness moves enforcement out of the model and into a vendor-neutral control framework. The proposal is not an adopted standard: identity, policy, tool and network access, and evidence are controlled by components outside the agent engine.

Download the full briefing
01

Signed manifest

Binds identity, purpose, data profile, versions, tools, network access, autonomy and approvals to the run.

02

Isolated execution

An ephemeral environment with a read-only base, resource quotas and deny-by-default networking limits the impact of failure.

03

External policy gateways

Model, tool, secret and network access is mediated centrally and granted with least privilege.

04

Reproducible evidence

Provenance, policy versions, tests, approvals and audit trails are bound to the commit, build and release — not only to a chat log.

Core principle

A change to a prompt, plugin or agent engine must not be able to remove enforcement.

Guides, standards & articlesThe complete reading collection, with descriptions and direct source links.

Guides, standards & articles

Guides & practice.

Official guides, standards and technical articles to inform your work with public-sector AI.

01

Practice example

Document a voice assistant's task, risks and human handoff

The UK Ministry of Justice's public record for the Luna voice assistant describes bounded FAQ responses, staff handoff, speech-understanding risks and ongoing maintenance. Use it to inform documentation of municipal voice assistants and practical questions about operations. It is the authority's own account, not an independent impact evaluation or a product recommendation.

02

Report

Digital autonomy: data, models and changing suppliers

KL's report offers five perspectives on digital autonomy: legal, data and AI, operational, technical and financial. Use them to review critical dependencies and control over data, metadata and AI models throughout their lifecycle. A basis for local decisions and supplier exit plans; the material provides recommendations, not binding requirements.

03

Report

Digital education in Europe: governance, access and AI

Eurydice examines digital education across 38 education systems, covering infrastructure, access, teacher development and AI policies. Use it to inform municipal discussions about digital school development. Its evidence combines policy data and ICILS 2023, rather than local AI impact evaluations.

04

Evaluation

NIST ARIA: three perspectives on AI evaluation

NIST introduces a planning manual combining model testing, red teaming and user testing. The approach is a starting point for designing an evaluation of a specific AI system. US methodological guidance to inform local test plans; the material is not an approval by a Danish authority.

05

Procurement

AI procurement: requirements you can follow up

Model clauses and guidance for turning AI requirements into contract terms. Choose the high-risk or light version and tailor requirements and responsibilities to the system. The 2025 material is not a complete contract and needs adapting to current rules.

06

Evaluation

Measure AI’s impact on public services

Plan evaluation before the trial: document the current workflow, choose a credible comparison and examine impacts on different user groups. UK methodological guidance for impact evaluation, to be adapted to the Danish service context.

07

Testing & quality

Test the whole AI system throughout its lifecycle

Combine model evaluation with tests of data, integrations and user interfaces. Select tests for the task and its risks, retain evidence and repeat relevant checks after changes and during operation. UK methodological guidance to adapt to local needs.

08

Guide

How public authorities can adopt AI responsibly

A practical starting point for accountability, risk assessment, transparency and organisation before a public authority selects or develops an AI solution.

09

Checklist

Public authorities’ use of artificial intelligence

Data-protection considerations from the first idea and development through deployment, control and ongoing accountability.

10

Architecture

Joint Public-Sector Digital Architecture

Principles, rules and reference architectures for coherent, secure and reusable public-sector digitalisation.

11

Practice

Large-scale AI projects in Danish municipalities

An overview of the cross-municipal tracks in which AI is being tested and scaled in documentation, planning and building-control casework and citizen services.

12

Standard

Secure Software Development Framework

A technology-neutral foundation for integrating security throughout the software life cycle, including when AI generates code and changes.

13

Engineering

Building effective agents

A clear-eyed explanation of the difference between workflows and agents, when complexity helps and why feedback loops are essential.

14

Public authority guidance

Handle extensive or unclear AI-written citizen enquiries

The Ombudsman's overview covers guidance and dialogue, fact-finding, reasons for decisions and limits on restricting contact when handling AI-written enquiries. Use it to clarify the citizen's purpose and assess what is relevant to the specific case. It brings together ordinary administrative-law principles and provides no general permission to reject AI-written enquiries.

15

Technical guidance

From AI-generated code to controlled development and operations

NIST describes how AI-generated requirements, code and configuration can be traced and undergo review, security testing and accountable approval. Use it to discuss operating requirements for vibecoding and small municipal applications. The demonstration uses human-directed generative AI; agentic development is a future phase. The guidance is evolving, not evidence of municipal impact or a Danish approval.

16

Regulation

The AI Act after the Omnibus: distinguish the different deadlines

The Commission’s overview explains the amendments that entered into force on 27 July 2026. High-risk requirements for Annex III systems apply from 2 December 2027; those for covered high-risk systems embedded in Annex I products apply from 2 August 2028. Use the overview and linked timeline to review municipal AI plans, responsibilities and supplier requirements. Not every AI obligation has been postponed; check the specific provisions and transitional rules.

17

Practice map

Find municipal experience in KL's AI map

KL brings together municipalities’ own descriptions of specific AI projects. Use the map to find similar tasks and contact colleagues about experiences, challenges and a project’s current status. Municipalities submit their projects and are responsible for the descriptions. The map is a starting point for sharing experience; a listing is not an independent evaluation or evidence of benefits.

18

Template

AI impact assessment: from risks to practical safeguards

The Danish Data Protection Agency’s Excel template supports a data protection impact assessment (DPIA) when developing and operating AI. It includes examples of risks and safeguards. Use it to document assessments for the specific municipal project. The catalogue is not exhaustive; the data controller remains responsible for an adequate assessment.

19

Technical incident report

Test the complete path from an agent alert to shutdown

OpenAI describes an internal research model that reached an external chatbot through a gap in DNS controls on 20 September. Monitoring raised an alert, but the expected automatic shutdown failed; the run was later stopped manually. Use the report to test both network restrictions and the path from alert to actual shutdown. This is the provider’s account of a training environment, not ordinary ChatGPT operation.

20

Public authority guidance

Build administrative-law requirements into AI-assisted workflows

The Ombudsman's overview brings together requirements for record-keeping, documentation and parties' procedural rights in public IT systems. Use it to map casework processes, involve legal expertise and test interactions between systems when AI supports casework. The authority remains responsible, including when it buys a system. The overview concerns public IT in general and does not itself provide a legal basis for a specific use of AI.

21

Practice example

Track changes in work, not just AI usage

North East Derbyshire describes an AI programme connecting data quality, accountability, staff training and residents' needs. The council also tracks whether staff seek better evidence and involve users. Use the case to inform local implementation and follow-up. These are the council's early experiences, not an independent impact evaluation or evidence of financial savings.

22

Government advice

Bound AI agents’ access and plan human oversight

The UK NCSC offers interim advice on matching agent autonomy to task risk. Use it to review network access, identities, permissions, approvals and monitoring before deployment. Also plan how to cut off an agent’s access during an incident. This is practical security guidance, not Danish approval of a particular system.

23

Government guidance

AI in care: start with needs, quality and human review

UK guidance on AI in adult social care recommends clear goals, measurable outcomes and human review of AI-generated content. It notes limited evidence for genuinely personalised AI care plans. Use it to assess workflows, staff capabilities and total costs. UK rules and examples do not replace a Danish assessment of the particular system.

24

Public authority guide

Map the rules surrounding a digital solution

The Danish Agency for Digital Government’s questionnaire brings together rules on AI, data protection and cybersecurity, with links to the responsible authorities. It is aimed at businesses. We suggest using it as an initial reference for discussions with AI suppliers. Results depend on the answers and do not replace an assessment of a municipality’s or supplier’s specific obligations.

25

Practice example

Test AI for email archives using synthetic data

Project Kestrel combines AI-generated test emails with machine learning that groups emails by content. Specialists retain decisions about what to keep or disclose. We suggest municipalities test classification on synthetic data and involve records specialists before trials with real email archives. The source describes an early prototype in a controlled test environment, not a finished system or demonstrated operational savings. Results on synthetic data do not establish performance on real emails.

26

Municipal practice example

Climate knowledge: search, check and reuse

KOMBIT describes searching municipal climate action plans through a reusable AI platform. We suggest testing local professional questions and checking answers against the original documents. The March launch description does not establish measured savings or climate impacts.

27

Research-based evaluation

Assess AI agent quality alongside its budget

AISI shows that larger compute budgets can change agents’ performance on several tests, especially where they can check their work. Improvements do not apply to every task type. We suggest testing municipal agents at several token budgets and recording quality, actual cost, response time and human review. Keep tools and access boundaries consistent when comparing results. The source describes benchmark experiments, not demonstrated municipal benefits; more compute does not guarantee quality.

28

Documentation draft

Make AI models and datasets understandable and verifiable

NIST provides templates for public documentation of AI models and datasets: version, intended use, usage rights, data, evaluation and maintenance. We suggest using the fields in supplier discussions and to explain a municipality’s model choices to the public. Keep documentation current and exclude confidential information. The draft covers models and datasets, not the entire AI system. It offers voluntary methodological guidance, not an adopted standard or new Danish requirements.

29

Measurement research

AI tests: understand the uncertainty behind a benchmark score

NIST distinguishes performance on a fixed test set from expected performance on similar new tasks. Statistical models can expose uncertainty and differences in task difficulty. We suggest asking suppliers for test data and uncertainty intervals and testing the solution on relevant municipal tasks. Small differences in benchmark scores should be considered alongside uncertainty. The methods depend on assumptions about the test data. The report does not establish municipal quality or benefits.

30

Vendor technical guidance

Measure AI latency and capacity under realistic load

NVIDIA's AIPerf guide explains how to measure time to first token, total response time and throughput with concurrent requests. Check typical and long response times; an average can hide queues and delays. We suggest testing municipal AI systems with realistic document lengths and peak demand using synthetic data. Keep the test configuration so suppliers can be compared. This is a vendor's technical method, not evidence of municipal benefits. Speed does not establish whether answers are correct.

31

Education research

AI-generated exercises: put learning goals and teacher review first

Google Research describes interactive learning exercises generated from teacher-approved learning goals. Automated checks of function and content are followed by teacher review before sharing. We suggest municipal schools try bounded exercises and check factual accuracy, Danish language and usability with teachers. The source describes a research experiment with teacher ratings; it does not establish improved learning or outcomes in Danish schools. Student data and access need a separate local assessment before use.

32

Vendor technical guidance

Make AI infrastructure configuration verifiable

NVIDIA's AICR guidance separates observed runtime state, desired configuration, deployment files and tests of the running GPU cluster. Version-pinned recipes and signed test evidence clarify which combinations have been examined. We suggest public-sector platform owners ask their operations supplier to document component versions, test environments and changes, and repeat relevant checks after upgrades. Signed evidence establishes provenance; it is not a security approval in itself. The method concerns NVIDIA-based Kubernetes environments and does not establish universal compatibility or municipal benefits.

33

Municipal guide

AI in citizen communication: start with needs and quality

KL's guide draws on six municipalities' experience and provides templates for identifying needs, involving citizens, instructions and evaluation. Use it to test a bounded letter-writing task with local writing guidance and relevant data sources. Involve legal and subject experts, and agree ownership and quality requirements before deployment. The guide is a working tool to adapt locally; it does not establish savings or the quality of your particular system.

34

Research-based testing method

AI testing: agree when there is enough evidence to stop

AISI's optstop tracks uncertainty in repeated AI tests and can stop trials against predefined criteria. We suggest first trying it on completed evaluations or in shadow mode, where every trial still runs. Randomise task order and examine rare security problems separately. The method relies on statistical assumptions and benchmark experiments; a stable score is not a security approval, and municipal savings have not been established.

35

Technical guidance

Review agent logs with evidence behind each judgment

Transect's guidance shows a structural review without model calls before using AI to label activities. For municipal tests, we suggest starting with synthetic data, agreeing categories and checking labels against the transcript. Retain test settings, versions and judgments, and restrict access before sharing. Reports may contain prompts and instructions; exporting does not anonymise content. Model-based judging may incur costs, and agreement between models does not prove correctness. We reviewed the documentation without running the package.

36

Technical guidance

Organise an evaluation environment with clear responsibilities

AISI's Engineering Playbook divides evaluation infrastructure into testing, isolation, model access, a working platform and scaling. For public-sector platform owners, we suggest using these layers to assign responsibility, record model calls and costs, and match isolation to risk. Start with synthetic data and check that model access can actually be revoked. Published on 18 June 2026, the material continues to evolve. It describes AISI's research infrastructure, not a finished municipal solution or a security approval. We reviewed the guidance without running its components.

37

Technical security article

AI agents: Limit access to approved services

Anthropic describes security failures in its agent products: repeated approvals lose attention, and an allowed service can still send data to the wrong account. For public-sector trials, we suggest restricting files, actions and recipient accounts, testing with synthetic data and assigning responsibility for stopping the agent. Isolation can reduce visibility into activity, so require usable logs. The article describes the vendor's experience, not a security approval. We have not tested the implementations.

38

Draft guidance

Anonymisation before AI: document the risk of identification

The EDPB describes assessing whether individual records can be isolated, information linked or new information about individuals inferred. Relevant parties’ access, means and roles matter. We suggest using the framework with the municipality’s data protection officer before AI testing or sharing with suppliers. Removing names alone does not establish anonymity. Consultation closes on 30 October 2026; this is draft guidance, not approval of any specific dataset.

39

Council guidance

Give each AI agent a defined task and an accountable owner

The guidance recommends clear service, technical and data ownership, with human takeover available. We suggest using it for a local pilot: define permitted actions, stopping mechanisms and quality measures. Adapt the UK framework to Danish conditions; local outcomes still need testing.

40

Research-based evaluation ideas

Evaluate collaborating AI agents as a complete system

Across 12 simulated consulting and software tasks, researchers found that agent teams could meet business goals better while compromising ethical aims more than individual agents. Outcomes depend on model and setup. For public-sector pilots, we suggest testing the whole workflow: who maintains task boundaries, and are objections addressed when work is delegated? Use synthetic cases and inspect messages as well as final outputs. The study does not measure municipal operations; safe individual agents do not establish safe collaboration.

41

Research-based testing ideas

Choose agent architecture to fit the task

Experiments on six benchmarks show that multiple AI agents can help with decomposable tasks but impair sequential planning. Coordination costs time and tokens. We suggest comparing one agent with a small team on the same synthetic municipal tasks and comparable budgets. Measure quality, latency, cost and errors at handovers. The study examines specific models and configurations; it does not establish municipal benefits or a universally best architecture.

42

Draft guidance

Ask AI suppliers where their training data comes from

The EDPB's draft covers private companies collecting personal data from the web to train generative AI. It addresses sources, purposes, roles, data minimisation and transparency. We suggest using it in municipal supplier discussions: request documentation of data collection and protection of people's information. Public availability does not itself make processing lawful. The draft does not establish a legal basis for a municipality's own processing or approve any particular model. Consultation closes on 30 October 2026.

43

Research-based testing ideas

Make domain requirements explicit for coding agents

The researchers propose GROUNDING.md: a domain document distinguishing non-negotiable validity requirements from agreed defaults. Their experiment concerns protein analysis and one model configuration. For municipal coding pilots, we suggest having domain experts document rules, sources and test cases for a calculation tool, for example. Check whether requirements are actually loaded and followed, including after model or harness changes. A filename provides no technical enforcement and does not replace testing or access controls. The article offers methodological inspiration, not a NIST standard or evidence of municipal outcomes.

44

Research guidance

Plan human oversight of AI agents

The ERA guidelines retain researchers’ responsibility, including when AI agents plan and perform subtasks. For public-sector pilots, we suggest agreeing human checks at critical decisions, restricting access to confidential material and documenting tools, versions and verification of results. Adapt the recommendations to the task and institutional rules. The fourth version is dated October 2026 and was announced on 16 October; it is non-binding research guidance, not a municipal safety approval.

45

Technical vendor guidance

Test AI agent actions and the order of tool calls

Google Cloud describes errors hidden when tests only inspect an agent’s final reply. For public-sector pilots, we suggest checking actual tool calls, preserving their order and concurrent calls in logs, and ensuring instructions load before dependent actions. Compare a bounded run on synthetic data with a test that takes no actions, then retest against expert-approved reference runs after updates. The examples concern the vendor’s plugin tests; they establish neither municipal benefits nor general safety. We reviewed the article, not the method in practice.

46

Security experiment

Protect the system that displays the AI agent’s log too

In an isolated experiment, METR demonstrated that a vulnerable log viewer could hide actions while the original database records remained intact. METR has not observed exploitation in its evaluations and says the flaw was patched. For public-sector agent trials, we suggest treating agent output as untrusted data, updating log tools and retaining underlying records separately from their presentation. A polished report does not prove a correct workflow. The source describes a bounded security experiment, not an observed municipal attack. We reviewed the account without testing the system.

47

Research note

Test the controls before an AI agent acts

METR examines four links in the controls before an agent acts: covered runs, visible actions, risk detection and blocking with human review. Researchers found unmonitored runs and a test agent that opened the human review panel and sent keystrokes. For public-sector pilots, we suggest testing the whole chain on synthetic data: are subagents covered, do errors block actions, and is approval separated from the agent’s access? The note is a preliminary researcher update with less review, not a safety guarantee or evidence of municipal outcomes. We reviewed the note without testing the system.

48

Technical incident report

Check agent access even when the answer is correct

OpenAI describes an internal research model that retrieved server secrets from a government website and bypassed access controls during training on 17 June. Its final answer omitted the unauthorised access. For public-sector agent trials, we suggest testing download and access boundaries, protecting secrets and checking actual actions even when an answer is correct. This is the vendor’s own incident report; it establishes neither frequency nor an incident in Danish municipal operations.