The Missing Layer in the Context Conversation: Context Articulation

David

Oct 6

14 min read

We are getting much better at designing how organisational context is structured, connected and delivered. But there is a question that sits before all of that:

has the organisation actually articulated the context in the first place? And does it have the capability to continue to do so?

You can build technically strong containers, smartly connected, but with nothing meaningful to full them.

Recently, and rightly so, a significant part of the enterprise AI conversation has shifted towards context.

Context engineering. Enterprise context layers. Ontologies. Knowledge graphs. Semantic models. Institutional memory. Company brains.

In a quick scan of LinkedIn, I pulled out at least eight posts and articles exploring different versions of this problem, including several published in just the past couple of weeks. Several are linked at the end of this article and are worthwhile reading for anyone interested in recent thinking on the context layer.

They reflect an important evolution in the AI conversation.

Increasingly, the challenge is understood not simply as giving AI access to more information, but giving it the right context, represented and connected in a way that allows systems to understand relationships, meaning, history, authority and relevance.

That direction is right.

Technical teams are becoming increasingly sophisticated at designing the infrastructure through which context can be represented, connected, retrieved and delivered. But there is a preceding organisational problem that receives far less attention.

Much of the conversation still carries an implicit assumption: That the context already exists, explicitly, waiting to be connected. Often, it does not.

The system can have the fact without having the context

Consider something relatively simple.

A customer record may correctly show: Customer X → 60-day payment terms → Review at renewal

Technically, there may be nothing wrong with that information. A knowledge graph can represent the relationship. A retrieval system can find it and an AI agent can reason from it. But the people involved may know much more.

Perhaps the 60-day terms were granted following a significant supply disruption.
Perhaps they were accepted as a customer-specific concession rather than a change in general commercial policy.
Perhaps leadership accepted the working-capital impact because of the strategic value of the relationship.
Perhaps the renewal date is not merely an administrative milestone, but the deliberately agreed point at which the organisation should reconsider whether the original reason for the concession still exists.
And perhaps continuing the exception requires a level of authority that the account manager does not hold.

The technical record says: Customer X has 60-day terms, to be reviewed at renewal.

The organisation understands: Customer X has 60-day terms for a particular reason, under particular conditions, with particular implications, and they should neither become precedent nor continue automatically without reconsidering the original rationale.

The system has the fact, but the people have the context.

And if that second layer was never articulated, there is nothing for the context infrastructure to connect.

The more dangerous problem: an incomplete graph can look complete

There is another issue here that is easy to underestimate.

Imagine there are ten pieces of context that materially affect how a particular decision, relationship or process should be understood. The organisation recognises three of them.

Those three are articulated clearly, structured beautifully, governed properly and represented perfectly in the graph.

The other seven are not badly captured. They were never recognised as context in the first place. The resulting graph does not necessarily look 30% complete.

It may look finished, and that false completeness may be more dangerous than an obvious gap.

Missing context does not always create an empty field, there may be no broken relationship, no red warning light and no visibly absent node.

If nobody recognised that an assumption, exception, weighting, rationale or historical lesson should have been made explicit, the technical environment may provide no indication that anything is absent at all.

You can see context that is wrong. It is much harder to see context that was never articulated.

This is one reason the problem cannot be solved entirely downstream through better retrieval, modelling or governance. Quality controls can improve what enters the system, they cannot automatically tell us everything the organisation failed to recognise should have entered it.

So what do we actually mean by “context”?

The word context can become vague very quickly and it helps to make it practical.

Organisations routinely hold the formal information while relying on people to supply an additional interpretive layer.

As you read these examples, consider where the same pattern exists in your own organisation or team.

The SOP says: Escalate after three failed attempts. The experienced person knows: Two particular warning signs make this situation different. Waiting for the third failure may create unnecessary risk.
The forecast says: Revenue will be R50 million. The experienced person knows: R35 million is contracted, R10 million is probable pipeline and R5 million depends on assumptions the team considers a stretch.
The supplier record says: Supplier A remains the preferred supplier. The experienced person knows: The team is already reducing exposure because service quality has deteriorated, even though the formal classification has not yet changed.
The decision record says: Option B was selected. The experienced person knows: Option A was cheaper but failed a security review. Option C depended on a system that is being retired. Reopening the decision without that history will simply repeat work already done.
The commercial record says: An exception has been approved. The experienced person knows: It applies to this situation for a specific reason and should not automatically establish precedent elsewhere.
The process says: Follow these steps. The experienced person knows: There are circumstances in which following the process literally is precisely the wrong thing to do.

None of these examples necessarily mean the original record is factually incorrect. The problem is that correct information can still be organisationally incomplete.

The missing layer may include things such as:

why something exists;
when it applies and when it does not;
which assumptions sit underneath it;
how much weight to place on one factor relative to another;
how confident the organisation is in it;
whether circumstances are changing;
what should and should not become precedent;
what alternatives have already been considered;
whose judgement carries authority when legitimate views conflict;
what historical experience materially changes how the information should be interpreted.

This is the sort of context experienced people apply almost invisibly.

Historically, organisations have been able to function with much of it unstated because humans supplied the missing interpretation at the point of use.

Someone knew who to ask, remembered why a decision had been made, understood when the written policy did not quite fit the situation, and could distinguish between factors that looked equally important on paper but clearly were not in practice.

In that sense, tribal knowledge has often functioned as invisible organisational middleware. People made incomplete systems usable, but AI makes that dependency much harder to ignore.

But this is not only an AI problem. Where context remains implicit, teams themselves remain dependent on proximity, tenure and particular individuals to interpret what the formal record cannot tell them. The consequences appear in familiar forms: inconsistent decisions, repeated questions, slow onboarding, rework, reopened debates and the loss of institutional memory when experienced people leave.

AI exposes the gap more starkly, but the organisational cost already exists.

This is not only a fragmentation problem

The distinction is important.

Fragmentation exists when the organisation has already expressed the knowledge, but it is scattered, duplicated, contradictory, outdated or difficult to trust. The challenge is to find it, reconcile it, establish authority, structure it and make it reusable.

Articulation is different.

The organisation relies on understanding that has never been expressed in a form the organisation itself can reuse.

It exists primarily as experience, judgement, assumptions, rationale, habits, conversations and memory.

And much of that gap is specifically a Context Articulation problem: making explicit enough of the meaning around organisational knowledge that somebody else can understand, trust and apply it appropriately.

That distinction matters because solving fragmentation extremely well does not necessarily solve articulation.

An organisation can have excellent search, strong governance, sophisticated ontology and beautifully connected knowledge, and still have a substantial amount of the understanding on which it actually operates sitting outside the system.

A brief distinction: Knowledge Articulation is the broader capability.

There is a broader capability sitting around this discussion that is worth distinguishing.

Knowledge Articulation is the capability to make what the organisation knows explicit and reusable. Not everything that needs articulating is context. A previously undocumented heuristic, lesson, operating practice or piece of expertise may be knowledge in its own right.

Context Articulation sits within that broader capability. It focuses specifically on the interpretive layer: making explicit how that knowledge should be understood, trusted and applied. Both matter.

For the purposes of this article, I am deliberately staying focused on Context Articulation.

“Capture what is in people’s heads” is not quite enough

Some of the current context discussion gets much closer to this problem.

It recognises that a large amount of organisational understanding exists in people rather than systems and that organisations need better ways to capture it.

I agree. But even that formulation can hide another assumption:

Do the people carrying the context actually recognise it as context, and are they able to articulate it?

Expertise does not normally sit in somebody's head as a neatly structured knowledge object waiting to be uploaded.

Experienced people often do not experience themselves as “using organisational knowledge” when they recognise an exception, spot a pattern or know that one factor matters more than another.

It feels like judgement. Instinct. Common sense. Many cases of “This is just how we handle these.”

They may explain the decision without making the assumptions behind it explicit, describe what happened without capturing why it mattered, or reach the right conclusion without being able to clearly articulate the signals that led them there. Often, they also assume that another capable person would interpret the same situation in much the same way.

Think for a moment about a recent decision-making meeting.

A decision was made.

Can you clearly recall why?
What alternatives were explicitly rejected?
What assumptions made the chosen option the right one?
Six months from now, if the people in that room were not available, where would somebody go to reconstruct that reasoning?

And some context only becomes visible when a situation forces somebody to say:

“No, in this case the normal rule doesn't apply, and here's why.”

This means the challenge is not simply extracting context.

It is helping an organisation become better at recognising when meaningful context exists or is being created, and articulating it clearly enough that it can survive beyond the people currently carrying it.

Context is being created continuously

This is not a finite stock of tacit knowledge that an organisation needs to extract once before implementing AI, as context is continuously produced through work.

A customer exception is agreed today.
A supplier begins deteriorating next month.
A team discovers that a process works differently under a particular set of conditions.
A forecast assumption changes.
A failed approach creates a lesson.
A decision is made for reasons that will be obvious to everyone in the room today and almost invisible to somebody revisiting it eighteen months later.

The organisation is constantly generating new context.

So even the most successful one-off knowledge-capture exercise would begin ageing almost immediately.

Context Articulation therefore has to become an ongoing organisational capability.

And importantly, organisations should not assume that capability will emerge naturally.

People need to be deliberately trained to recognise the forms of context they carry, understand why that context matters to somebody who was not present, and articulate it in a way that another person or system can interpret correctly.

That requires intentional capability development.

If there is one point I would want a reader to take away from this article, it is this: organisations need to invest as deliberately in their people’s ability to recognise and articulate context as they do in the technical infrastructure designed to consume it.

Otherwise, they risk building increasingly sophisticated systems on top of an organisational capability that has never been developed.

And so this means teaching people to notice assumptions, exceptions, rationale, uncertainty, relative weighting, changing conditions and authority.

It means giving them repeated opportunities to practise articulating those things.

It means reinforcing the behaviour through leadership, workflows and governance.

And it means providing prompts and low-friction tools that make good articulation part of everyday work rather than a separate documentation exercise people are expected to remember.

This is not simply a communication skill. It is an organisational capability that has to be designed, taught, practised and reinforced.

What Context Articulation can look like in practice

This does not mean every employee needs to work through a complex framework every time they make a decision. At its simplest, people can be given structures that help them express the judgement they are already applying.

One lightweight Context Statement I use is:

In [context], interpret [signal / knowledge] as [meaning], because [reason]. Treat it differently when [condition or exception].

For example: In a renewal discussion, interpret a request for extended payment terms as a relationship-specific commercial exception rather than a change in general policy, because retaining the account may justify the short-term working-capital cost. Treat it differently when the request reflects deteriorating payment behaviour rather than a temporary negotiation point.

There is nothing technically complex about that sentence.

But look at what it forces into the open.

The situation.
The interpretation.
The reasoning.
And the boundary condition at which that interpretation should change.

Without those elements, somebody reading “60-day payment terms” later may have the fact while completely misunderstanding its meaning.

The purpose of structures like this is not to force every piece of organisational knowledge into a sentence formula.

It is to help people recognise that their interpretation is itself organisational knowledge worth making explicit.

Four useful questions for finding missing context

A broader way to think about Context Articulation is through four simple questions. These are not intended here as an exhaustive framework, but they help show how much context can sit around an apparently straightforward piece of information.

1. How should I understand it?

What does this actually mean? What assumptions sit underneath it? When does it apply, and when does it not? What exceptions, relationships or history change how it should be interpreted?

2. How should I use it?

Why does it matter? What outcome is it intended to support? How much weight should I give it relative to other factors? Under what conditions should I act differently?

3. How far should I trust it?

How certain are we? How current is it? Is the situation changing? Is this an established position, a working assumption or an estimate? What evidence or experience supports it?

4. Who stands behind it?

Who owns the judgement? Whose view takes precedence when there is disagreement? Who may approve an exception? What can override the current position, and under what conditions?

Take the forecast example again.

R50 million revenue is a fact recorded in the forecast.

But asking these four questions immediately surfaces a different level of understanding:

How should I understand it? Some of the figure is contracted and some relies on assumptions.
How should I use it? It may be suitable for planning, but not every component should carry equal decision weight.
How far should I trust it? The contracted portion may be highly reliable while the final portion is deliberately stretching.
Who stands behind it? Different assumptions may have different owners, and someone needs authority to decide which forecast position the organisation is prepared to act upon.

Suddenly, the number has context. And importantly, none of that context is created by the graph itself. It had to be recognised and articulated first.

In practice, TKA uses a more comprehensive and structured set of context dimensions to work through this systematically.

The purpose here is not to reproduce that methodology, but to make the underlying point visible:

context is not one extra field sitting beside the knowledge. It is a collection of interpretive elements that determine whether the knowledge can be used properly.

The architecture has to support the capability

This should not become another expectation placed on employees with the instruction to “document better.”

If the organisation wants better Context Articulation, the environment needs to make it easier.

A decision workflow can ask why the decision was made and what was rejected.
A process template can ask when the standard approach should not apply.
A forecast can make assumptions and confidence visible.
A customer record can distinguish a commercial exception from standard policy.

And AI can help identify candidate decisions, surface likely assumptions, prompt for missing rationale, compare new information against established knowledge and structure first drafts.

There is a useful irony here: AI needs context to work well, but it can also be one of the most effective tools for helping people see where that context is missing and articulate it more clearly.

It can ask the person the question nobody thought to ask. It can notice that a decision has been recorded without its rationale, that an exception appears to conflict with a stated rule, or that an assumption has been implied but never made explicit. It can compare what somebody has just said with the organisation’s existing knowledge and prompt: Is this a change? An exception? A new learning? Does this apply everywhere, or only here?

But AI should not be treated as the creator of organisational context.

Why? Because, ultimately, much of that context is still created by people.

It is created when somebody applies judgement to an unfamiliar situation, notices nuance in a real customer interaction, weighs competing signals, learns from something that failed, understands why a rule does not quite fit the circumstances, or makes sense of conditions that have changed since the process was written.

And for as long as people continue to play a meaningful role in organisations (and I hope they always do) this may be one of the most valuable things they contribute.

People do not simply execute against existing knowledge. They create new organisational understanding through applying their minds to the real world.

They interpret nuance, notice what does not fit, understand customers beyond what is recorded in a CRM, make trade-offs, recognise when circumstances have changed, and connect experience from one situation to another.

The challenge is that much of this value is still lost because people have never been taught to recognise it as organisational context, let alone articulate it in a way that can survive beyond themselves.

That is a new skill set that needs to be deliberately developed.

And this is where the surrounding architecture becomes important. Governance can make authority, precedent and reliability visible, while training can teach people what kinds of context matter, how to recognise it, and how to express it.

In other words, architecture can help elicit articulation. But the container and the capability have to develop together.

The best-designed structure in the world does not help if people do not recognise the context worth putting into it. And training people to articulate context achieves little if there is nowhere reliable for that understanding to live, evolve and be reused.

The relationship is iterative:

Architecture supports articulation. Articulation improves the architecture.

Context delivery is not context production

The major implication is that employees cannot be treated only as consumers of organisational knowledge. They are also part of the organisation's knowledge-production system.

Every day they encounter decisions, exceptions, customer nuance, failed approaches, changing assumptions, operational learning and new interpretations.

The capability required is recognising: What happened here that somebody else may need to understand later?

And:

What context am I carrying that another person, even with access to exactly the same information, would not automatically have?

This leads to an important distinction.

Technical teams are increasingly good at solving context delivery.

The organisational challenge that sits upstream is context production, and Context Articulation is a critical part of that.

Before context can be engineered, connected, retrieved or delivered, somebody has to recognise that it matters and make it explicit.

And that capability cannot simply be assumed. It has to be built.