Abstract Public-sector ICT procurements frequently emphasize the importance of “quality,” yet rarely define what that quality means in operational or measurable terms. This ambiguity often leads to mismatches between buyer expectations and supplier interpretations, hindering requirement clarity, evaluation rigor, and delivery outcomes. In our earlier work, we analyzed public ICT tender documents and introduced the concepts of quality proxies–symbolic expressions of quality without clear operational definitions–and the tendering gap, which describes the structural misalignment between clients’ intentions and suppliers’ interpretations. This extended study revisits and generalizes these concepts in the context of AI-driven software systems, where quality specification is further complicated by probabilistic behavior, data dependencies, and evolving regulatory expectations. Drawing on twelve public procurement cases and conceptual analysis, we demonstrate how emerging AI-related quality attributes–such as explainability, fairness, robustness, and transparency–often function as AI quality proxies: abstract normative goals that lack shared operational meaning across stakeholders. To address this challenge, we extend the tendering gap model by introducing the notion of an epistemic gap, reflecting fundamental differences in stakeholders’ understanding of what constitutes measurable quality in AI systems. We discuss how this gap arises from knowledge asymmetry, measurement uncertainty, and cross-disciplinary communication barriers, and examine its implications for requirements engineering, procurement practices, and software quality models. The paper contributes a unified conceptual framework for understanding quality ambiguity across both traditional ICT and AI-driven systems, and outlines practical directions for improving quality specification through scenario-based requirements, calibrated evaluation rubrics, and enhanced stakeholder alignment. These findings support the development of more operational, transparent, and accountable approaches to specifying and evaluating software quality in an increasingly AI-driven world.

One distinctive characteristic of software is its malleability and succeeding opportunity and also need for a constant change. However, in certain types of software, many agencies in the public sector are bound by the laws on competition and financed by governmental budgeting processes. Consequently, the acquiring agencies adapt their processes to what the existing systems allow due to complexities in making changes and modifications. In this paper, we study the relation of public sector software acquisition and delivery, and the continuously changing nature of software. Then, we analyse pain points of evolving software in public sector information systems, and propose technical artefacts to improve the status quo. Finally, to add flexibility to public sector information systems’ acquisition and evolution, we elaborate a novel architectural pattern called Mosaic architecture, based on macroservices, which allows independent subcontracting, development, and deployment. The approach is demonstrated with a real-world industrial study from a public service that has been sketched applying the macroservice principles.

In this paper, we outline the challenges we have encountered in mission critical system development projects based on public tendering processes and list reasons why the challenges we have faced are difficult to tackle. Furthermore, based on our experiences in the mission critical system provision domain, we see that the software-as-a-service (SaaS) model saves us from many of the shortcomings of the common RFQ process and helps us, at least partly, to tackle the encountered challenges.

With the traditional on-site installation model of enterprise software, end-user characteristics often remain at least partly unknown to the system providers. While users are typically modeled and their personas described during the development, those models and personas are rarely verified or refined based on operative usage of the system after installation. There are several reasons for this, but often the main reason is that it is simply too hard to obtain reliable and comprehensive information on the system usage from an on-site installation. The software as a service (SaaS) model introduces drastic improvement to the situation, as the service provider can now have direct access to the user data and analyze it, if agreed appropriately with the customer. In this paper, we present experiences regarding a company's transition from a provider of installed software systems to a SaaS provider from the viewpoint of customer care and related activities. The paper is based on observations gained with an industrial system that has recently experienced such transition. The results, although partly preliminary, already show that many of our assumptions on the user behavior may not hold true and substantial effort is required to understand various user needs thoroughly. As the studied company is just starting the journey to create customer care processes for the SaaS era, in addition to the descriptions of the current designs and implementations, some plans for future work are presented. These plans aim to better understand the changing role of softer aspects in software engineering when adopting the SaaS paradigm.

Public tender processes typically start with a comprehensive specification phase, where representatives of the eventual owner of the system, usually together with a hired group of consultants, spend a considerable amount of time to determine the needs of the owner. For the company that implements the system, this setup introduces two major challenges: (1) the written down requirements can never truly describe to a person, at least to one external to the specification process, the true intent behind the requirement; (2) the vision of the future system, stemming from the original idea, will change during the specification process – over time simultaneously invalidating at least some of the requirements. This paper reflects the experiences encountered in a large-scale mission critical information system – ERICA, an information system for the emergency services in Finland – regarding design, implementation, and deployment. Based on the experiences we propose more dynamic ways of system specification, leading to simpler design, implementation, and deployment phases and finally to a better perceived quality.