Frugal Algorithms and Communities of Practice
The preceding posts in this series developed a theoretical apparatus - state spaces, grammars, the planning/design distinction - and sketched, in the grammar post, what a compositional approach to service specification might look like. This post connects that apparatus to practical constraints, drawing on work in a rather different context: military AI research. I am currently working at FOI (the Swedish Defence Research Agency) on a project examining AI in resource-constrained military environments - developing frugal algorithms, working with edge computing, explainability - and the work has surfaced, alongside my earlier experience at SCÖ, questions that bear directly on what service design's formal ambitions might actually encounter when they meet operational reality.
The argument of this post is that the concept of "frugal AI" - the development of artificial intelligence systems under conditions of genuine resource constraint (Pechenizkiy and Huang, work in progress) - offers a productive lens through which to reconsider the relationship between design, constraints, and the communities of practice within which capability actually develops. It also, I want to suggest, illuminates a persistent weakness in the way public sector design projects tend to begin.
The Frugal AI Problem
In mainstream AI development, the assumptions are generous: abundant labelled data, scalable cloud compute, reliable connectivity, and the engineering resources to iterate rapidly. Frugal AI, as the KOIOS project at FOI defines it, refers to the development and implementation of AI systems under conditions where one or more of these assumptions fail. The constraints are not abstract; in military edge computing, where systems must operate at what doctrine calls "the tactical edge" - the point where the technology meets the operational situation - they are simultaneous and severe. Data is scarce, with too few labelled examples to train conventional supervised models, requiring practitioners to work with few-shot, zero-shot, and transfer learning techniques that presuppose architectural decisions quite different from those assumed by mainstream machine learning pipelines. Compute is limited by the Space, Weight and Power (SWaP) constraints of devices that must be carried, powered from batteries, and operated without the infrastructure that a data centre provides. Connectivity is intermittent or denied, so systems must function offline and synchronise opportunistically. Power is finite, and inference must be cheap enough to sustain over the duration of a mission.
What makes these constraints instructive for service design is not their military specificity but their structural character. They invert the usual design logic. Conventional AI development - and, I would argue, conventional service design - tends to proceed from aspiration to implementation: define the capability you want, gather the resources needed to realise it, deploy the infrastructure to support it, iterate to improve performance. Frugal AI asks the questions in the opposite order: what data actually exists? What compute is actually available? What connectivity can actually be relied upon? Given these realities, what capability is achievable? The constraints come first; the design follows from the constraints. Goodwin (2011) argues that there is, in truth, no such thing as unconstrained design; but the frugal AI literature makes the point with unusual force, because the consequences of ignoring constraints are, in military contexts, immediate and potentially fatal.
Constraints and the SCÖ Experience
The resonance with the SCÖ case, discussed in earlier posts, is direct. The Pathway Generator assumed data infrastructure that did not exist - patient records fragmented across four systems with no shared identifier, consent barriers to data linkage, no dedicated machine learning engineering resource. It assumed technical capacity that was not available, and organisational readiness that had not been cultivated. The project or programme preceded any serious engagement with constraints; the constraints then made the project inoperable.
Frugal thinking, applied to the SCÖ situation, would have started from a fundamentally different position: what patient data actually exists across the Swedish rehabilitation system? What is its quality, its completeness, its accessibility? What can legally and practically be shared across organisational boundaries, given GDPR, sector-specific healthcare data regulations, and the requirement for ethical review? What analytical capacity does the organisation actually possess - not in the abstract, but in terms of specific people with specific skills? Given these realities, and only given these realities, what is achievable? The constraints would have been treated not as obstacles to be overcome or assumed away but as design material - as the substance from which any realistic specification would need to be built.
Alexander (1977), in his work on pattern languages, argued that good design emerges from a proper understanding of the constraints within which it must operate: a building that ignores its site, climate, and the properties of its materials will fail, however elegant its conception; a building that responds to these constraints can achieve a kind of fitness that unconstrained design never reaches. Jackson (2021), extending this tradition into software design, describes Alexander's insight as the recognition that design expertise can be captured in generic patterns - but that the instantiation of those patterns always depends on the specific constraints of the situation. The same principle, it seems to me, applies to services. A service grammar, of the kind sketched in the preceding post, could include constraints as first-class elements of the specification - not just what we want to achieve but what conditions delimit what is achievable. Making constraints explicit does not remove them, but it does make the design honest, and it makes it considerably harder to propose capabilities that the constraints preclude.
The Knowledge Problem
The connection between frugal AI and the theoretical apparatus of this series illuminates a further difficulty: the knowledge problem in design. De Mozota (2003) makes the point directly: design knowledge is tacit. It resists the kind of codification that would allow it to be transferred through documentation, specifications, or formal training alone. Nonaka's (1991) distinction between explicit and tacit knowledge, which de Mozota invokes, maps onto a tension that runs through the grammar proposal: a grammar of services attempts to make design knowledge explicit - to specify states, transitions, promises, constraints in a form that can be communicated, validated, and computationally reasoned about - but the effectiveness of such a specification depends on practitioners who understand what those formal elements mean and how to apply them in situated practice.
Frugal AI faces the same challenge. Model architectures and training procedures can be documented; but the judgement required to apply them - when to use which technique, how to diagnose failures, what trade-offs to accept in a given operational context - develops through what Wenger (1998) describes as legitimate peripheral participation in communities of practice, not from reading papers or following procedures. Nutley and Walter (2007) make the general point from the evidence-use literature: the importance of tacit knowledge, situated learning, and situated action in the effective use of codified knowledge is well established; communities of practice are the primary mechanism through which this kind of knowledge transfer occurs. Brown and Duguid (2001) argue that knowledge and practice are inseparable at the organisational level - that organisations are, in a meaningful sense, communities of communities of practice, and that the knowledge an organisation possesses inheres in the social practices of its members, not in its documents or systems.
The implication for the grammar proposal is sobering. A grammar of services, however rigorously developed, does not eliminate the knowledge problem; it merely relocates it. The formal specification makes certain things explicit - states, transitions, constraints - but its effective use still requires communities of practitioners who know what those specifications mean, who have developed the situated judgement to interpret them, and who participate in the social practices through which design knowledge is created, tested, and refined. Malmberg (2017) demonstrates the same point in her study of design capability building in the Swedish public sector: knowledge acquisition without the organisational capacity for assimilation - without the communities and practices that give knowledge its operational force - leaves the organisation functionally unchanged.
The Military Connection
There is a question worth confronting directly: what does military AI research illuminate for public service design? The domains are, on their surface, very different.
The answer, I think, is that military contexts force a kind of honesty about constraints that public sector environments - at least the ones I've been operating in recently - have lacked. In combat, systems that do not work under actual conditions - not idealised conditions, not the conditions assumed in the business case or funding application, but the conditions that actually obtain - fail in ways that have immediate and catastrophic consequences. There is strong selection pressure for realism: for designing systems that work with the data that exists, the compute that is available, the connectivity that can be relied upon, the people who are actually present. Herbert (2023), reviewing UK government digital transformation, finds the opposite pattern: over-reliance on suppliers, persistent skills gaps, and a tolerance for the gap between what is promised and what is delivered that would be, in a military or any more delivery oriented context, untenable.
Public services face analogous constraints - scarce data, limited technical capacity, complex organisational boundaries, contested goals - but seem, in my experience across both Swedish and UK contexts, to tolerate failure to a considerably greater degree. The speculative, innovation-branded projects I have been involved in can fail without catastrophic consequences; organisations can sustain the gap between designed and enacted services indefinitely; the feedback loops are slower, the accountability more diffuse. Tsekleves and Cooper (2017) note that there is simultaneously a wave of design coming to healthcare and a push for lean and frugal innovation, but the connection between the two - the recognition that design in resource-constrained public service contexts requires something closer to military frugality than to the aspirational mode that design more typically adopts - remains, in my experience, underexplored.
The underlying challenge is, however, the same: designing for complex, resource-constrained, politically contested environments where idealised assumptions do not hold. Military design thinking and frugal AI thinking converge on this point: you cannot plan your way through problems you do not understand, with resources you do not have, using infrastructure that does not exist. You need design - to construct the problem space - and frugality - to work honestly within the constraints that the problem space reveals.
Implications
The implications of frugal thinking for service design practice are, I think, threefold. First, it suggests that design should begin with constraints rather than with visions - that before articulating what one wants to achieve, the work should be to understand what one has to work with, in terms of data, systems, capacity, legal frameworks, and the political environment within which any design must operate. Second, it suggests that formal specification, of the kind the grammar proposal envisages, should include constraints as first-class elements - not as caveats appended to an otherwise unconstrained design, but as integral components of the specification itself, shaping what is specified and delimiting what is achievable. Third, it reinforces the argument that capability develops in communities of practice (Wenger, 1998; Brown and Duguid, 2001; Parker and Heapy, 2006), not through the production of artefacts alone - that design processes which build community capacity alongside producing documents and specifications are more likely to generate durable capability than those which treat the specification as the deliverable.
The next post applies the full framework to critique the dominant approaches to programme management in public sector digital transformation - the technomagic thinking that assumes capability can be procured without community, that plans can succeed without state spaces, and that vision can overcome constraints.
Next: "Beyond Technomagic: What Military Design Teaches Public Sector Transformation" - applying the planning/design framework to critique programme management orthodoxy.
References
Alexander, C. (1977). A Pattern Language. Oxford University Press.
Brown, J.S. and Duguid, P. (2001). Knowledge and Organization: A Social-Practice Perspective. Organization Science, 12(2), 198–213.
De Mozota, B. (2003). Design Management. Allworth Press.
Goodwin, K. (2011). Designing for the Digital Age. Wiley.
Herbert, J. (2023). Lessons Learnt from Government Digital Transformation. UK Ministry of Defence.
Jackson, D. (2021). The Essence of Software. Princeton University Press.
Lave, J. and Wenger, E. (1991). Situated Learning: Legitimate Peripheral Participation. Cambridge University Press.
Malmberg, L. (2017). Building Design Capability in the Public Sector. PhD thesis, Linköping University.
Nutley, S. and Walter, I. (2007). Using Evidence: How Research Can Inform Public Services. Policy Press.
Parker, S. and Heapy, J. (2006). The Journey to the Interface. Demos.
Pechenizkiy, M. and Huang, T. (2024). Survey of SOTA on Frugal, Robust, and Trustworthy AI. KOIOS Project Report.
Tsekleves, E. and Cooper, R. (2017). Design for Health. Routledge.
Wenger, E. (1998). Communities of Practice: Learning, Meaning, and Identity. Cambridge University Press.