Context Lives in People, Not Data
Why Ross Mason is right, why he is also incomplete, and what this means for modern API and integration work
Some ideas reappear at the right moment. A few days ago my colleague Annegret Junker shared a short but striking line on LinkedIn. She had heard Ross Mason say at apidays in Amsterdam that context is not in the data and that context is in the human’s heads. The sentence stayed with me because it captures a tension that has shaped the API and integration world for years.
Human Interpretation as the Starting Point
The statement feels true the moment you hear it. Data alone never explains what is happening in a business process. A dataset shows that an order was created but reveals nothing about whether this reflects a final commitment or an informal intention. An event carries a familiar name yet speaks a dialect that only the producing team understands. Misaligned interpretation is often the real reason why integrations break and why APIs frustrate consumers. Teams assume they share a context while each of them carries a different one in their mind.
At the same time Mason’s statement risks being read too literally. If context lived only in people’s heads, large organisations could not function. Human understanding is essential, but it is fragile. People interpret things differently. People leave. People forget. Without shared structures, semantic drift becomes inevitable. This is why so much energy goes into externalising and stabilising context. Domain models, event semantics, capability maps, operating procedures and interface guidelines all exist because organisations cannot rely on personal interpretation alone.
Knowledge Graphs as Semantic Memory
This is also where Knowledge Graphs enter the picture. A Knowledge Graph is more than a clever data representation. It is a way of externalising relationships, meanings and assumptions that would otherwise remain buried in individual mental models. Knowledge Graphs create an explicit network of concepts, entities and links that represent how a business understands its world. They do not replace human context, but they capture and structure enough of it so that others can build on it without reinventing the meaning every time. In this way they become a form of semantic memory for the organisation. They make tacit context discoverable and explainable rather than allowing it to float invisibly between teams.
There is also the contrasting perspective that emerges when we recall Mason’s background. As the founder of MuleSoft he helped promote the belief that integration could be scaled through connectors, templates and catalogues of building blocks. The implicit message was that context problems could be solved through platform engineering. His remark now reveals the limits of that belief. Platforms accelerate connectivity. They do not create shared understanding. They solve the technical layer. They do not solve the semantic one.
It is equally important not to neglect the context that does appear inside data structures. Data never carries full meaning, but it does carry clues. The evolution of an event stream reflects workflow thinking. Field names reveal priorities. Relationships between entities show how teams understood their boundaries. Even the absence of certain attributes tells a story about what was considered irrelevant. These traces matter because they show the historical reasoning that shaped a domain.
Capabilities as Containers of Meaning
This brings us to Capability Thinking.
Capabilities describe what the organisation must be able to do, independent of systems or teams. Because they bundle purpose, responsibilities and concepts, they become containers of meaning where human context becomes stable. Once a capability is clearly defined, APIs become expressions of that capability rather than arbitrary technical pipelines. Integration becomes a conversation between capability boundaries instead of a negotiation between systems. Context becomes durable because it is anchored in organisational structure rather than individual memory.
Knowledge Graphs complement capability maps by providing the semantic fabric that connects concepts, events, responsibilities and data. They reveal how meaning flows through the organisation. They expose contradictory definitions. They show where teams quietly diverge in their understanding. Together, capabilities and Knowledge Graphs offer a path to externalise context without freezing it into rigid structures. They create shared organisational memory that improves over time.
There is also an important implication for AI. Generative models can support summarisation, highlight semantic gaps and work with Knowledge Graphs to provide reasoning paths. But they cannot originate the tacit meaning that defines a capability. They operate on the visible traces of context, not on the invisible human reasoning behind them.
Toward Shared Organisational Context
The closing reflection brings the elements together. Mason is right that context does not arise from data alone. It begins in human interpretation. But if it stayed there, organisations would be unable to scale their digital efforts. The real challenge is to move context from individual minds into shared structures. Capability maps, semantic models, Knowledge Graphs and disciplined API practice make this possible. They turn fragile personal understanding into coherent organisational memory. Context may originate in the mind, but it becomes powerful only when it is shared.