The problem with calling everything a transaction
The previous post identified four orientations that public sector programmes tend toward - risk, efficiency, provider, and demand - and showed how each orientation shapes which failures become visible and which remain hidden. Those orientations also shape what counts as service work in the first place, and a single service can look like entirely different things depending on which orientation frames it.
Consider a waiting list validation service. Under a risk orientation, the service exists to ensure no patient breaches the 52-week referral-to-treatment standard; the core tasks are compliance checks against breach thresholds, audit trail maintenance, and exception flagging - work that is fundamentally epistemic (does this patient meet the criteria?) shading into deontic (who is accountable for acting on the flag?). Under an efficiency orientation, the same service is a throughput operation: how many validations per session, what is the average handling time, how can the process be streamlined - and the tasks are framed as transactions to be completed as quickly as possible, regardless of their modal character. Under a provider orientation, the service is about managing clinical capacity: are there enough slots, is the right specialist available, can the system absorb the referral volume - and the work foregrounds availability and access rather than the epistemic or governance work that determines whether a patient should be on the list at all. Under a demand orientation, the service asks what patients actually need: which patients are deteriorating while waiting, whose clinical situation has changed since referral, who needs to be escalated - and the core tasks involve discovering unmet need and redistributing clinical attention, which is epistemic and deontic work that the transactional framing renders invisible.
A similar pattern holds for classic GDS-style citizen services. "Apply for a passport" under an efficiency orientation is a throughput problem - processing time, unit cost, digital take-up rate. Under a risk orientation it is an identity verification problem - fraud detection, document authentication, compliance with immigration rules. Under a demand orientation it becomes a question about who cannot access the service and why - users without internet access, applicants whose documentation does not fit standard categories, people whose circumstances require discretionary judgement rather than algorithmic processing. Each orientation foregrounds different kinds of task, yet the dominant vocabulary for describing service tasks - the GDS "transaction" - flattens these differences into a single category.
GDS service patterns frame the middle layer of service design around transactions: "apply for something", "check something", "book something". These are useful as reusable journey steps - and the pioneering work by Downe, Tarling, and others in establishing them has given service design a shared vocabulary it previously lacked. But the transactional framing rests on an implicitly transactional ontology of service: service as a series of discrete state-changing exchanges between a user and a system. Kimbell (2017) argues for a fundamentally different orientation: services understood not as fixed transactional entities but as "a fluid arrangement of human and nonhuman artefacts" constituted through ongoing relational practice. The distinction between designing services as products to be delivered and design for service as a relational process (Kimbell, 2011) matters here because the transactional framing captures only one kind of work - the constitutive act that produces a state change - while leaving invisible the epistemic and governance work that surrounds it.
Tarling (2023) comes close to surfacing this distinction. Their desired outcomes for service stages include "users knowing what to do", "having the right data to make a decision that's right first time", "users being confident they've done the right thing", and "a decision being made and communicated, and users understanding what happens next" (Tarling, 2023, p. 19). These criteria implicitly encode different modal types - knowing and having the right data are epistemic conditions; choosing the right option involves deontic judgement; a decision being made and communicated is a constitutive act - but the framework treats them as properties of good stages rather than as indicators of fundamentally different kinds of work. The distinction remains latent.
Practitioners working on service patterns have consistently identified a gap between the high-level pattern names ("check something", "book something") and the design system components that implement them. Kirsty Sinclair, leading the Scottish Government's service pattern work, describes this gap as "the bit in the middle" - the space between abstract task types and concrete UI components that feels "really grey and a little bit wobbly". The verbs, nouns, and hierarchy of action post offered one account of why this gap exists: Leontiev's distinction between activities (oriented to a motive, extending over time), actions (oriented to a discrete goal, bounded and completable), and operations (automatised routines shaped by conditions) suggests that service patterns, task patterns, and component patterns occupy different structural levels. The task level - bounded, goal-directed episodes that compose larger service journeys - is where the gap sits. Kaptelinin and Uden (2012) made the most sustained attempt to apply activity theory to service design, characterising services as "delegated actions" - actions embedded in the activity structure of one actor (the customer) but carried out by another. Their analysis establishes that services sit at the action level of Leontiev's hierarchy, not at the activity or operation level, and that understanding the hierarchical structure of customer activity is crucial for service design. What their framework does not address - and what the practitioner community's flat lists of pattern verbs also leave open - is what differentiates one delegated action from another: why "validate a referral", "delegate a case", and "book an appointment" are not merely instances of the same category at different granularities but represent fundamentally different kinds of work. The transactional criterion - produces a state change - is too broad to be analytically useful. What kind of state change? For whose benefit? Under what conditions does the state change count as valid?
What modality reveals about task types
There is a substantial tradition of applying speech act theory to system design and organisational coordination, beginning with Winograd and Flores's (1986) Language/Action Perspective and its implementation in The Coordinator, and continuing through the Action Workflow research programme in CSCW and business process modelling. That tradition demonstrated that organisational work consists largely of networks of requests, commitments, and completions - deontic structures in the sense used here.
Palmer's (2001) foundational treatment of modality distinguishes two principal categories: epistemic modality, which concerns knowledge, belief, and justified inference about the state of the world, and deontic modality, which concerns permission, obligation, and the rights and responsibilities that govern what agents may, must, or cannot do. The case grammar post explored these modal dimensions as features of verb meaning; what they also reveal, at a higher level of analysis, is a principled distinction between types of task.
Epistemic tasks produce a revised knowledge state: something is now known, classified, or evaluated differently as a result of the work. Deontic tasks produce a revised governance state: the distribution of rights, obligations, and accountabilities over a case or process has changed. And there is a third type, not directly captured by the epistemic/deontic distinction, that Austin (1962) called declaratives: tasks that produce new institutional facts - entities or states that exist because a community of agents with appropriate authority treats them as existing within a framework of constitutive rules. These three types are ontologically distinct, and the distinction is not merely taxonomic; it has direct implications for how each should be designed and governed.
Epistemic tasks: discovering, classifying, evaluating
In an epistemic task, the agent occupies what Fillmore's case grammar calls the Experiencer role: they are acquiring, organising, or evaluating knowledge about a state of affairs. The patient - in the semantic sense - or object of the service interaction is a data domain or clinical situation; the work product is a change in the agent's or institution's epistemic relation to that domain. Discovering which patients (in the medical sense) on a waiting list require urgent intervention, cohorting a patient population by clinical criteria, and validating whether a referral meets pathway requirements are all epistemic tasks in this sense. The list has not changed; the distribution of attention and informed judgement across it has changed. The patient record has not changed; what is known about the patient's clinical readiness has changed.
The Gärdenfors (2017) force-result framework, explored in the events post, describes the semantic structure of epistemic tasks precisely: the force vector is the agent's examining or evaluating activity; the result vector is a shift in epistemic state rather than a change in the physical or institutional world. This is why epistemic tasks can be undone or revised without residue - if the analyst realises they have misclassified a patient cohort, they can reclassify; the error leaves no institutional trace in the way a wrongly issued decision does. Design for epistemic tasks therefore needs to support reversibility, comparative judgement, and criteria transparency - not the completion-state confirmation that constitutive tasks require.
Validation sits at the border between epistemic and deontic work. A validation task produces an epistemic claim (this referral meets the criteria), but in institutional contexts it simultaneously authorises downstream action - the validated referral may now proceed. Where the validation is performed by an agent with authority to make it binding, it shades into a constitutive act; where it is performed as an informational check that another agent will act on, it remains epistemic. The design implications differ accordingly.
Deontic tasks: exercising authority and redistributing responsibility
In a deontic task, the agent exercises a right or discharges an obligation in a way that changes the governance structure of a case or process. Austin (1962) called these "exercitives": the exercise of powers, rights, and authority through utterances that are felicitous (properly authorised and contextually valid) rather than merely true or false. When a clinical manager routes a case for consultant review, they do not change what is known about the patient; they change in whose hands the decision now rests. The obligation to decide has been transferred; the accountability structure has been modified.
Winograd and Flores (1986) applied this analysis to organisational systems design through their Conversation for Action framework, showing that much of what organisations call "work" consists of networks of requests, commitments, and completions that are fundamentally deontic in character: someone asks for something (creating an obligation), someone commits to delivering it (accepting the obligation), and someone confirms completion (discharging it). This deontic structure is systematically obscured when operational tools are designed as analytical dashboards: the list architecture surfaces the epistemic picture (who is where, what state are they in) while making the deontic structure (who is responsible for what, who has authority to act) invisible or difficult to act upon.
Design for deontic tasks must address the structure of authority - who is the legitimate agent for this exercitive act, and under what conditions - as well as the state changes involved. An approval that is issued by someone without authority is not merely wrong; it is infelicitous in Austin's sense, which is a different kind of failure from an epistemic error. The error conditions, audit requirements, and remediation paths differ accordingly.
Constitutive tasks: creating institutional facts
In a constitutive task, the agent performs an act that brings a new institutional fact into existence. Searle (1995) provides the theoretical account: institutional reality is constituted wherever a community collectively accepts that "X counts as Y in context C" - where a signature on a form counts as a legal registration, a confirmation number counts as a booked appointment, or a clinician's declaration counts as a "medically optimised" status. These are not descriptions of pre-existing facts but declarations that create the facts they describe, provided the constitutive conditions are met.
The distinction from deontic tasks is subtle but real. A delegation redistributes existing authority; a booking creates a new entity (the appointment) with its own rights and obligations attached. A routing decision changes who is responsible; a pathway registration creates a new institutional relationship between patient and service. Constitutive tasks are the points in a service where something genuinely new comes into being, and they are therefore particularly sensitive to the conditions of felicity: the system must be authorised to issue the declaration, the context must be appropriate, and the institutional framework must recognise the act. Design failures at constitutive task points - a booking that does not register in the downstream system, a validation that does not update the pathway status - are not merely usability failures; they are institutional failures, in Searle's sense, that leave agents uncertain about the actual state of their obligations and rights.
Why monitoring is an activity, not a task
The original list included "track outcomes" alongside the epistemic, deontic, and constitutive examples. It does not belong at the same level, and the misfit illuminates the Leontiev distinction that underpins the whole framework. The Scottish Government's service pattern work recognises something similar by separating "ongoing" patterns (renewals, appeals, updates) from "transactional" ones, and Tarling (2023, p. 15) acknowledges that "real life is messy" with "loops, backtracking and missed stages" and stages like "get help" that "need to be there the whole time". But neither framework explains why monitoring resists being treated as a bounded step. Tracking outcomes is an activity in Leontiev's (1978) sense: it is oriented toward a motive (ensuring a patient's pathway progresses; maintaining oversight of a service's performance over time), extends over time without a natural completion point, and cannot be discretised into a bounded episode with an identifiable work product.
Kaptelinin and Nardi (2012, p. 30) summarise the distinction: actions are "defined by their goals" and are "completed when the goal has been attained", while activities are motivationally whole orientations toward the world that "may last over extended periods of time". Tracking outcomes has no completion; it is the ongoing activity that organises the discrete actions within it. It belongs at the service level - as an ongoing relationship between a user and a case or service - rather than at the task level as one type of bounded episode among others.
From transactions to a task-level hierarchy
The practitioner service pattern work discussed above tends to organise patterns into a loose hierarchy: service-level journeys at the top, transaction or task patterns in the middle, and UI components at the bottom. The GDS framing distinguishes service patterns ("apply for a licence") from design system components (buttons, form fields, date pickers). The Scottish Government adds a third grouping - early-stage, transactional, and ongoing - which is a temporal rather than structural distinction. Holliday (2022) and the Essex County Council work frame the middle layer as "modular" patterns that can be "designed and tested once, and then reused" (Holliday, 2022, p. 15). In my own earlier design system work, I had introduced a "capability patterns" layer between transaction patterns and UI components, intended to capture composed solutions like task inboxes, configuration managers, and audit trails that recur across services.
The problem with this layering is that the capability patterns layer rested on a different criterion from the other levels: self-containment, the architectural property of being deployable independently. This is an inconsistency because the other levels are distinguished by activity properties - what question a level answers, what kind of change it produces - not by architectural properties. GOV.UK Notify is, under a properly activity-theoretic analysis, a platform-level service: it has its own service patterns, its own users, its own governance, and its own development trajectory. A task inbox is a component pattern that supports epistemic tasks (discovering, filtering, prioritising items in a list) by composing multiple interaction elements. These are not at the same level; calling both "capability patterns" and distinguishing them by self-containment places an architectural criterion into a hierarchy that otherwise uses activity-theoretic ones.
The resolution is to ground the distinction between the task level and the component level in compositional scope rather than self-containment, following Frost's (2016) atomic design hierarchy. At the component level, design solutions are composed of interaction elements (organisms composed from molecules composed from atoms); at the task level, design solutions address a complete bounded episode of a particular modal type. GOV.UK Notify sits at the platform level; a task inbox is a component pattern; the distinction between them does not require a separate capability layer.
Burns and Hajdukiewicz (2017) argue that, at least in their definition, the levels of an abstraction hierarchy are distinguished by the question each level answers - "why?" moving upward, "how?" moving downward - and that a hierarchy built around consistent questions will be analytically more powerful than one built around granularity or disciplinary tradition. Applying this principle produces a hierarchy in which the task level is explicitly distinguished by modal character:
The revised hierarchy consolidates capability and interaction patterns into a single component level distinguished by compositional scope, removes the self-containment criterion, and replaces the transaction layer with a task layer distinguished by modal character. The platform layer is clarified as encompassing independent services (including things like GOV.UK Notify) rather than design patterns. Monitoring and ongoing oversight move to the service level where, as activities rather than actions, they belong.
The practical implication is that design system documentation at the task level should specify not just what a pattern enables users to do but what kind of work it supports: whether the design problem is to help users change a knowledge state, redistribute governance responsibility, or constitute a new institutional fact. Each type requires different conditions of success, different error models, and different governance structures - and conflating them in a single transactional category produces design systems that address the mechanics of interaction while leaving the activity-theoretic distinctions unresolved.
Relationship to practitioner service pattern work
What the epistemic/deontic/constitutive distinction offers is not a replacement for the practitioner service pattern work discussed throughout this post but a theoretical account of something that work already senses. The practitioner vocabulary names tasks by their verb ("check", "book", "apply") without articulating what kind of state change the verb produces or what conditions must hold for the task to succeed. Tarling's (2023, p. 12) warning to "watch out for sentences that start with a verb that describes what an organization wants... rather than from the perspective of what someone actually needs or wants to do" reflects an intuition that the verb alone does not capture the character of the work, but the existing frameworks do not yet provide a criterion for distinguishing one kind of verb-work from another.
The modal distinction provides that criterion. "Check something" is typically epistemic: the user revises their knowledge state, and the task succeeds when they know something they did not know before. "Book something" is constitutive: a new institutional fact (the appointment) comes into being, and the task succeeds only if the institutional conditions of felicity are met. "Approve something" is deontic: authority is exercised and the governance structure of a case changes. These are not merely different verbs; they require different error models (epistemic errors are revisable; constitutive errors leave institutional residue), different design affordances (epistemic tasks need comparative judgement; deontic tasks need authority verification; constitutive tasks need confirmation and downstream propagation), and different accountability structures. Making these distinctions explicit could help address the "grey and wobbly" middle that Sinclair identifies - not by prescribing specific design solutions but by clarifying what kind of problem each task pattern is solving, so that the design guidance at the component level can be appropriately differentiated.
The activity-theoretic grounding also offers the practitioner community something it does not yet have: a principled account of why some patterns resist being treated as bounded steps. Tarling and the Scottish Government both recognise that "ongoing" patterns behave differently from transactional ones, but without the Leontiev distinction between activities and actions, the difference can only be described phenomenologically ("it's messy", "it loops") rather than explained structurally. If monitoring is an activity rather than an action - oriented to a motive rather than a goal, extending over time rather than completing - then it belongs at a different level of the hierarchy, and trying to document it as a service pattern alongside "book something" will always feel awkward, because it is not the same kind of thing.
References
Austin, J.L. (1962). How to Do Things with Words. Oxford University Press.
Burns, C.M. and Hajdukiewicz, J.R. (2017). Ecological Interface Design. CRC Press.
Downe, L. (2020). Good Services: How to Design Services That Work. BIS Publishers.
Ford-Downes, M., Stephens, L. and Thomas, G. (2025). Developing service patterns: reusable designs for building government services. Services in Government Blog. https://services.blog.gov.uk/2025/03/19/developing-service-patterns-reusable-designs-for-building-government-services/
Frost, B. (2016). Atomic design. Brad Frost Web.
Gärdenfors, P. (2017). The Geometry of Meaning: Semantics Based on Conceptual Spaces. MIT Press.
Holliday, B. (2022). Multiplied: How the Best Companies Manage at Scale. Practical Inspiration Publishing.
Kaptelinin, V. and Nardi, B. (2012). Activity theory in HCI: Fundamentals and reflections. Synthesis Lectures on Human-Centered Informatics, 5(1), 1-105.
Kaptelinin, V. and Uden, L. (2012). Understanding delegated actions: Toward an activity-theoretical perspective on customer-centred service design. In Proceedings of the International Conference on Information Systems Development.
Kimbell, L. (2011). Designing for service as one way of designing services. International Journal of Design, 5(2), 41-52.
Kimbell, L. (2017). The Turn to Service Design. In Julier, G. and Moor, A. (eds.) Design and Creativity: Policy, Management and Practice. Bloomsbury Academic.
Leontiev, A.N. (1978). Activity, Consciousness, and Personality. Prentice Hall.
Palmer, F.R. (2001). Mood and Modality (2nd ed.). Cambridge University Press.
Searle, J.R. (1995). The Construction of Social Reality. Free Press.
Tarling, K. (2023). The Service Organization: How to Deliver and Lead Successful Services, Consistently. Pearson.
Winograd, T. and Flores, F. (1986). Understanding Computers and Cognition. Addison-Wesley.