The Framework Integration Problem
My design systems framework includes events as one of eight core elements, defined following Gärdenfors (2014) as atomic cause-effect triggers with a force vector and a result vector. This definition works well for UI interactions - user clicks button, system responds - but integrating it with Majid Iqbal's service grammar from Thinking in Services (Iqbal, 2018) exposed a conceptual tension. Iqbal also uses "event", but means something quite different: for him, an event (2T) is a "thing with shortfalls" - a condition that creates demand for affordance.
Consider a patient on a waiting list with a deteriorating condition: in Iqbal's sense this is an "event", a thing with a shortfall that demands access to treatment capacity. But "clinician clicks validate button" is an "event" in the reactive systems sense - a discrete happening that triggers a state change. These are not the same thing at all. Which framing is more useful for service design, or do we need both?
Events as Happenings
Peter Gärdenfors, in The Geometry of Meaning (Gärdenfors, 2014), offers a cognitive theory of events built on conceptual spaces and force dynamics. His two-vector condition states that "an event must contain at least two vectors and one object; these vectors are a result vector representing a change and a force vector that causes the change". A prototypical event involves an agent generating a force vector, a patient (the thing acted upon), and a result vector representing the change in the patient's state.
A clinician validates a referral: the force is the validation action; the result is the change in referral status from "pending" to "validated"; the event is the causal connection between force and result.
This view treats verbs as referring to either the force vector (manner verbs like "pull", "push", "drag") or the result vector (result verbs like "break", "open") but not both simultaneously. The strength of this framing is that it gives events causal structure - we can analyse why something changed, not just that it changed. This is valuable for understanding service failures, tracing accountability, and designing interventions.
Events as Conditions
Iqbal's event (2T) sits in his "why" layer - the layer that explains why services exist at all. His four "why" elements are all "things" with particular properties, arranged across two axes: demand and supply on one hand, performance and affordance on the other.
In this view, an event is not something that happens but something that exists in a state of deficiency. A patient waiting for surgery is an "event" in Iqbal's sense: a thing with a shortfall - unmet clinical need - that creates demand for the affordance of treatment capacity. Iqbal is explicit: "events are things with shortfalls. They express their needs in terms of having access to resources". The event expresses a need; it signals demand into the world.
The strength of this framing is that it explains why services are needed at all. Events-as-conditions are the latent gaps in the world that services exist to fill. Without shortfalls, there would be no demand.
Reactive Systems Theory
David Harel's work on statecharts and reactive systems (Harel, 1987; Harel and Politi, 1998) offers yet another perspective - and one directly relevant to how platform products actually work. In reactive systems, input consists of a sequence of stimuli - events and changes in data values - generated by the environment, and a reactive event-driven activity is continuously active in an idle state, waiting for an event to cause it to perform some action. The ISO architecture standard (ISO/IEC/IEEE, 2019) defines event-driven architecture around "the production, detection, consumption of, and reaction to events, where an event is a significant change in state".
Here, events are neither force-result pairs nor conditions - they are signals. Something happened that the system needs to know about. The emphasis is on detection and reaction rather than causation or potential. This maps directly onto technical implementation: message queues, data pipelines, workflow actions. An event is a message passed between components saying "this happened, you might care".
The Temporality Question
One critical difference between these framings is their relationship to time. Gärdenfors' events are inherently temporal: the force vector precedes or accompanies the result vector, there is a before and after, and the structure of an event is a structure of time because change requires duration. Iqbal's events are quasi-atemporal: a "thing with shortfalls" exists in a state and persists; the patient's need for surgery does not happen to exist but simply is, remaining so until someone provides treatment. The condition has duration but no internal temporal structure. Harel's events are instantaneous markers: in statechart semantics, an event is a point in time - the moment something changed. The system was in state A, an event occurred, now it is in state B. Events are boundaries between states, not durations.
This matters because service interactions unfold over time. As Graves (2024) notes, "given that the before, during, and after interactions may all occur at different times, through different channels and on different timescales", a service interaction - say, a patient being validated on a waiting list - unfolds across distinct temporal phases.
No single "event" concept captures all of this. We need at least the condition (before), the transitions (during), and the signals (the moments that mark boundaries).
Signals and Directionality
This observation exposes a gap in the framework as I had been developing it. I had been treating "signals" as notifications from the system - acknowledgements that something happened, coordination messages between components. But this is only half the picture.
When a user clicks a button, that is a signal. When a shortfall becomes acute enough to demand attention, that is a signal. Iqbal's events "express their needs" - they signal demand into the service system. A ward clerk opening a patient record is a demand signal; a breach threshold approaching is a demand signal. The world is constantly signalling to the system. The system responds with its own signals, which as Krippendorff (2005) notes should be "as immediate and as direct as possible, starting with confirmations that users' actions are accepted".
Burgess (2020) makes a related distinction between pull requests - "asynchronous retrieval promises" where the user requests content - and push notifications - "synchronous signalling" where the system alerts the user. The directionality of signals matters: demand signals flow from world to system, expressing need and requesting action; supply signals flow from system to world, acknowledging, coordinating, and confirming.
Signifiers and Signals
Norman's signifiers (Norman, 2008) are cues that indicate possible actions - the button that says "click me", the handle that says "pull". Harel's signals are notifications that something occurred - the event that says "user clicked", the message that says "state changed". These are not quite inverses, but they are complementary. A signifier is a communication from system to user, positioned before action, that prompts or affords action. A demand signal is a communication from user to system, at the moment of action, that expresses intent. A supply signal is a communication from system to user, after action, that confirms or acknowledges.
The sequence, then, is: a signifier indicates an affordance; the user acts on it; a demand signal is generated; the system processes the demand; a supply signal confirms the outcome; and new signifiers appear indicating new affordances. Signifiers and supply signals are both system-to-user communications, but at different points in time and with different purposes - signifiers prompt action while supply signals acknowledge it.
Promise Theory and Locus of Control
Mark Burgess's promise theory (Burgess, 2017) adds another dimension. In promise theory, agents make voluntary commitments about what they will provide (positive promises) or accept (negative promises); crucially, promise theory locates control at the agent making the promise, not at a system commanding action. This reframes the signal discussion.
A signifier is a displayed promise ("I promise to validate this patient if you click here"), a demand signal is a request to fulfil a promise ("you promised to validate, I am clicking"), and a supply signal is evidence of promise-keeping ("I have validated as promised").
Each framing places the locus of control differently and suggests a different focus for service design. Events as happenings distribute control between agent and patient, focusing design on intervention - where to apply force. Events as conditions place control in the environment, focusing design on opportunity recognition - where shortfalls exist. Events as signals place control in the system architecture, focusing design on orchestration - how to route information. And events as promises place control with autonomous agents, focusing design on commitment architecture - what promises are made and kept.
A Revised Synthesis
Given the temporality and directionality analysis, a five-element model emerges as more useful than the original single "event" concept.
Conditions are states creating potential for action - shortfalls, gaps, needs - that persist until addressed. Signifiers are cues indicating possible action, displayed promises positioned before the moment of choice. Demand signals are expressions of need or intent flowing from world to system at the moment of request. Transitions are force-result pairs that change state, the Gärdenfors events with their causal structure. And supply signals are acknowledgements and confirmations flowing from system to world at the moment of response.
This synthesis preserves Iqbal's insight that conditions explain why services exist, Gärdenfors' insight that transitions have causal structure, Harel's insight that signals enable coordination, Norman's insight that signifiers prompt action, and Burgess's insight that promises create reliability. The temporal sequence forms a cycle: condition leads to signifier, which leads to demand signal, which leads to transition, which leads to supply signal, which reveals a new condition.
A Rasmussen-Style Abstraction Hierarchy
Rasmussen's (1985) abstraction hierarchy provides a way to think about systems across levels of abstraction, from physical form to functional purpose. Each level answers a different question, and levels are connected by why-what-how relationships: moving up answers "why?" while moving down answers "how?". As Flach and Voorhorst (2019) note, "the top two levels in Rasmussen's Abstraction Hierarchy (Functional Purpose and Abstract Function) represent the deep structure of a problem".
Adapting this to the service framework, with promises as the meta-layer:
Reading the Hierarchy
The hierarchy can be read in two directions. Moving upward, each level answers "why?": supply signals exist to confirm that transitions happened; transitions exist to fulfil demands; demand signals exist to express needs created by conditions; conditions matter because they instantiate the potential embedded in promises; and promises themselves create the binding commitments that make coordination possible in the first place.
Moving downward, each level answers "how?": promises are enacted through conditions that create or enable action; conditions become actionable through signifiers that display possibilities; users act on signifiers through demand signals that express intent; demands are fulfilled through transitions that change state; and transitions are confirmed through supply signals that close the loop.
Promises as the Meta-Layer
Promises sit above the operational hierarchy because they explain why the whole system exists. A shortfall only creates demand if someone has promised to fill it; a signifier should only appear if the underlying capability is promised; a demand signal is valid only if it invokes an existing promise; the transition taken should match what was promised; and if you promise, you must confirm whether you delivered. In Burgess's (2017) terms, "promises act as calibrators for fault detection" - they are the reference against which we measure whether the system is working.
Implications for the Design System
The original framework had a single "events" element as an atomic cause-effect trigger. The revised framework replaces this with five elements: conditions (states that create potential, drawing on Iqbal), signifiers (cues that prompt action, drawing on Norman), demand signals (expressions of need from world to system), transitions (state changes with causal structure, drawing on Gärdenfors), and supply signals (acknowledgements from system to world). This is more complex, but it handles the temporality of service interactions, the directionality of communication, the difference between potential and actualisation, and the coordination problem in distributed systems.
For the design system, this suggests thinking about components not just as UI elements but as participants in this signal flow. A button is a signifier that, when activated, generates a demand signal that triggers a transition that should produce a supply signal. The transaction patterns identified in earlier work map onto different configurations of this signal flow.
Several questions remain open. The relationship between this five-element model and Iqbal's 16x frame needs further exploration; his "why" layer (artefacts, events, resources, capabilities) maps onto conditions, while his "how" layer (tasks, activities, access, availability) maps onto transitions, but the correspondence is not yet precise.
Failed signals present another area for investigation: a demand signal with no supply signal is a service failure, and a signifier with no corresponding capability is a broken promise - connecting to deeper questions about accountability and the visibility of failure. There is also the question of whether the five-element model can be simplified for some contexts; a three-layer model of potential (conditions plus signifiers), action (demand signals plus transitions), and confirmation (supply signals) might suffice where the full granularity is not needed.
The question of nested promises is perhaps the most generative. A service may promise an outcome that depends on multiple capabilities, each making their own promises, and this raises questions about promise composition that promise theory itself may help answer. If promises are the meta-layer, then the product/service distinction may matter less than the architecture of commitments: "products" as bundles of capabilities (promise-makers) and "services" as journeys that invoke those promises.
References
Burgess, M. (2017). Thinking in Promises: Designing Systems for Cooperation. O'Reilly Media.
Burgess, M. (2020). A Treatise on Systems, Volume 2: Intentional Systems Theory. ChiTek-i.
Flach, J. M. and Voorhorst, F. (2019). A Meaning Processing Approach to Cognition. Wright State University Libraries.
Gärdenfors, P. (2014). The Geometry of Meaning: Semantics Based on Conceptual Spaces. MIT Press.
Graves, T. (2024). Mapping the Enterprise. Tetradian Books.
Harel, D. (1987). Statecharts: a visual formalism for complex systems. Science of Computer Programming, 8(3), 231-274.
Harel, D. and Politi, M. (1998). Modeling Reactive Systems with Statecharts: The STATEMATE Approach. McGraw-Hill.
Iqbal, M. (2018). Thinking in Services: Encoding and Expressing Strategy Through Design. BIS Publishers.
ISO/IEC/IEEE (2019). ISO/IEC/IEEE 42020:2019 Software, systems and enterprise - Architecture processes.
Krippendorff, K. (2005). The Semantic Turn: A New Foundation for Design. CRC Press.
Norman, D. A. (2008). Signifiers, not affordances. Interactions, 15(6), 18-19.
Rasmussen, J. (1985). The role of hierarchical knowledge representation in decisionmaking and system management. IEEE Transactions on Systems, Man, and Cybernetics, SMC-15(2), 234-243.