1. Intelligibility Is a Condition of Participation
Many discussions treat intelligibility as a quality of information. A document may be readable, a model may be clear, a repository may be complete, and a dashboard may be accessible. Those qualities matter, but they do not establish intelligibility.
An enterprise is not a collection of representations. It is an ongoing interweave of agents, practices, responsibilities, obligations, systems, resources, decisions, and consequences. Knowledge becomes intelligible only when it helps agents participate effectively within that interweave.
This distinction changes the architectural question. Instead of asking whether information has been represented correctly, we ask whether the relevant agents can use that knowledge to understand what matters, what depends on what, what can be trusted, and what actions become possible, necessary, or dangerous.
The focus moves from representation to participation.
This shift is more significant than it first appears. Much of traditional architectural practice has concentrated on representation. It has developed models, views, taxonomies, metamodels, repositories, and classifications. These activities are valuable. Yet none of them guarantees that the resulting knowledge will be usable by the people who must act on it.
An executive deciding between investments, a regulator examining evidence, a product manager balancing trade-offs, an operator responding to an incident, and a software team implementing a change do not primarily need representations. They need understanding that can support action.
Enterprise Intelligibility begins at precisely that point.
2. Enterprises Are Understood From Somewhere
No one understands an enterprise from nowhere.
Executives understand from responsibility.
Practitioners understand from work.
Architects understand from structures and dependencies.
Regulators understand from obligations and evidence.
Operations understand from execution.
AI agents understand through the supplied context.
Software agents understand through rules and structures.
Machines understand through signals, constraints, and operational parameters.
Understanding is always situated.
This observation has profound consequences for architecture. It means there is no single enterprise perspective that can serve every participant equally well. The enterprise appears differently depending on where someone stands within it.
A regulator examining a control framework sees a different enterprise from the operator keeping services running. A product owner sees the enterprise differently from a risk manager. A machine learning model sees a different enterprise from the perspective of the people responsible for governance.
None of these perspectives is wrong.
Each reveals something real.
The challenge, therefore, is not to eliminate situatedness. The challenge is to coordinate through it.
This is one of the central contributions of Interweaving. Interweaving recognises that enterprises are experienced from within, through participation, rather than observed from a neutral external position. Architectural work, therefore, becomes less about imposing a universal perspective and more about connecting situated understandings strongly enough that coordination remains possible.
The enterprise does not need a single understanding.
It needs understandings that can work together.
3. Four Conditions Built as Disciplines
The previous article defined four conditions of Enterprise Intelligibility: relevance, grounding, status clarity, and manifestation.
These conditions explain what must exist.
The next step is turning them into disciplines that can be practised.
3.1 Anchor Knowledge in Situations of Use
Knowledge becomes intelligible when it matters in use.
This sounds obvious, yet much enterprise knowledge fails precisely this test. Strategies are written that do not help make decisions. Capability maps are created that do not help with coordination. Principles are approved that do not influence behaviour. Repositories are maintained that do not support action.
The issue is not necessarily quality.
The issue is relevance.
Anchoring asks whether knowledge is connected to the situations in which people must act. It asks whether knowledge matters to the agents, responsibilities, decisions, obligations, and practices that constitute enterprise participation.
A strategy statement may be perfectly reasonable. Yet if product teams cannot use it to guide priorities, its intelligibility remains weak.
A policy may satisfy governance requirements. Yet if operational staff cannot use it when difficult choices arise, its intelligibility remains limited.
Anchoring, therefore, provides a practical test. Knowledge that does not matter in use cannot carry action.
This point has implications for architecture, but it must be stated carefully. Relevance in use does not by itself make something architectural. It is one of several considerations that, together, determine what carries architectural significance, and what is essential to the enterprise rests on more than mere relevance. Anchoring contributes to the relevance of knowledge for use. It does not, on its own, establish architectural significance.
3.2 Ground Knowledge in Structural Dependencies
Relevance alone is insufficient.
Architectural knowledge must also have a basis.
Grounding concerns the structural dependencies that give enterprise knowledge meaning and validity. It asks what something depends upon, what depends upon it, and what loses meaning, validity, operation, or coordination if that dependency basis changes.
Grounding prevents enterprise knowledge from floating free.
Without grounding, concepts drift. Strategies become aspirations disconnected from operational reality. Capabilities become labels without clear meaning. Principles become slogans. Architectural abstractions become a portable vocabulary detached from the structures that originally gave them significance.
Grounding is often misunderstood.
It is not agreement.
It is not shared understanding.
It is not stakeholder consensus.
People can agree about something ungrounded and disagree about something grounded.
Grounding concerns dependency. It concerns what makes something what it is.
This distinction matters because enterprises frequently confuse acceptance with validity. A statement may be widely accepted while remaining weakly grounded. Another may be contested while remaining strongly grounded. A broadly endorsed principle such as "we are customer-centric" may be accepted everywhere yet depend on no particular capability, decision, or measure, which leaves it weakly grounded. A data-residency rule may be resisted by delivery teams yet remain strongly grounded, because it depends on a regulatory obligation that real systems and contracts rely upon.
Grounding asks a different question.
What gives this knowledge its basis?
The stronger the answer, the stronger the enterprise's ability to reason, coordinate, and adapt.
Grounding is therefore not merely an analytical technique. It is one of the foundations of enterprise intelligibility.
3.3 Make Knowledge Status Explicit
Many enterprises do not lack knowledge.
They lack clarity about the status of knowledge.
The problem is not absence. The problem is uncertainty about how knowledge should be treated.
Is something authoritative or provisional?
Actual or intended?
Current or obsolete?
Human-created or AI-generated?
Observed or inferred?
Binding or advisory?
When status is unclear, people compensate. They rely on institutional memory, personal networks, local interpretations, and informal conversations. Knowledge continues to exist, but confidence in its use declines.
This is why status clarity performs an architectural role.
It allows participants to judge what can be trusted, challenged, escalated, ignored, implemented, or treated as a hypothesis.
A regulator examining evidence needs status clarity.
A programme deciding priorities needs status clarity.
An AI assistant retrieving enterprise knowledge needs clarity on the status.
Without it, coordination becomes fragile because participants no longer know how knowledge should guide action.
Enterprise Intelligibility depends upon this distinction.
3.4 Manifest Knowledge in Forms That Can Carry Action
Knowledge does not become effective because it has been written down.
Some knowledge must be explicit.
Some must be embodied.
Some must be embedded.
These manifestations are not alternative storage locations. They are complementary ways through which knowledge participates in enterprise action.
A principle recorded in a repository remains weak if it never appears in decisions.
A process model remains fragile if the corresponding knowledge never becomes part of operational routines.
A strategy remains rhetorical if it never becomes visible in investments, priorities, incentives, and behaviour.
Knowledge becomes more intelligible when it is manifested where action occurs.
This insight helps explain why documentation alone rarely changes enterprises. Documentation can preserve knowledge, communicate knowledge, and govern knowledge. Yet action depends upon whether that knowledge becomes embodied in judgement and embedded in operational reality.
The practical question, therefore, is not whether knowledge has been documented.
The practical question is where that knowledge must exist if it is to influence action.
4. The Fifth Discipline: Translation Across Multiple Intelligibilities
The predecessor introduced a decisive shift.
There is no single enterprise intelligibility.
Different agents require different intelligibilities.
Executives need consequences, trade-offs, and direction.
Architects need structures, dependencies, and constraints.
Practitioners need implications for work.
Regulators need evidence and traceability.
AI agents need grounded context and permitted use.
Software agents need executable structures and rules.
Machines need executable constraints and operational conditions.
The same representation does not work for every agent.
This is not a weakness of enterprises. It is a characteristic of enterprises.
The challenge is not to eliminate these differences. The challenge is to connect them.
This is where the fifth discipline emerges.
Translation across multiple intelligibilities operationalises the multi-agent nature of enterprise participation. It allows the same underlying reality to become meaningful to different agents without fragmenting into unrelated local interpretations.
Translation is, therefore, architectural work.
Not because architects own translation, but because coordination across boundaries depends upon it.
This point deserves emphasis because enterprises often confuse translation with integration. Integration connects things; translation makes them intelligible to different agents. A fuller account of why integration alone does not produce coherence belongs to a later article in this series. Here, it is enough that the connection is not the same as understanding: translation is what allows knowledge to remain connected while becoming intelligible to different participants.
This is one of the places where Interweaving becomes particularly valuable. Interweaving does not seek to erase differences between perspectives. It seeks to connect perspectives strongly enough that coherent participation remains possible.
Different agents do not require identical understanding.
They require compatible understanding.
The distinction is crucial.
Identical understanding is rarely achievable and often unnecessary.
Compatible understanding is what allows enterprises to function.
5. The Movement of Intelligibility Work
Enterprise Intelligibility is not a methodology.
It is a discipline of attention.
In practice, the movement is straightforward. We begin with the agents who must act and the situations in which they must act. We identify the knowledge required for judgement, coordination, decision, compliance, operation, or change. We ground that knowledge in the dependencies that give it meaning. We make its status explicit so it can be trusted appropriately. We determine where it must be manifested if it is to influence action. We translate it into forms suitable for other relevant agents. Finally, we examine whether action becomes more coherent or whether confusion, contradiction, and fragmentation remain.
This is not a checklist.
It is a way of asking whether enterprise knowledge has become usable.
The emphasis on usability is important. Enterprises often measure knowledge production while paying far less attention to knowledge use. Yet intelligibility emerges only when knowledge participates in action.
The question, therefore, is not how much knowledge exists.
The question is whether the right people can use it.
6. AI Outputs Must Become Intelligible Too
Artificial Intelligence makes this discipline more important, not less.
AI can generate explanations, summaries, recommendations, analyses, models, and architectural artefacts at extraordinary speed.
Yet explanation is not intelligibility.
AI outputs are knowledge claims.
Those claims must still be anchored in use, grounded in enterprise dependencies, clear in status, manifested appropriately, and translated for the agents expected to use them.
Otherwise, AI simply increases the rate at which enterprises produce representations.
The fundamental challenge remains unchanged.
Can knowledge support situated understanding and coherent action?
The stronger AI becomes, the more important that question becomes.
Enterprises that ignore this distinction risk becoming increasingly articulate while becoming increasingly difficult to understand.
7. Intelligibility, Usefulness, and Coherence
Enterprise Intelligibility is not an end in itself.
Its significance comes from what it enables.
An enterprise that cannot make knowledge intelligible struggles to coordinate across boundaries. It struggles to maintain a common direction while preserving local autonomy. It struggles to connect strategy, operation, governance, technology, risk, compliance, and change.
An enterprise that can make knowledge intelligible gains something more valuable than information.
It gains enterprise usefulness.
People become better able to understand consequences, recognise dependencies, judge trade-offs, and participate effectively with others. Knowledge becomes capable of carrying action across organisational, professional, and technological boundaries.
This does not solve the coherence problem.
But coherence cannot emerge without it.
Coherence requires intelligibility because agents cannot participate coherently in realities they cannot understand. Integration may connect systems. Coordination may align activities. Standardisation may reduce variation. None of these guarantees coherence if participants remain unable to understand what they are part of and how their actions relate to others.
This is why Enterprise Intelligibility belongs within the coherence ecosystem.
It occupies a distinct role.
Its concern is not whether things are connected.
Its concern is whether connected things become understandable enough for meaningful participation.
The future enterprise will not be distinguished by how much knowledge it generates.
It will be distinguished by how effectively it turns knowledge into situated understanding and coherent action.
Coherence requires intelligibility.
And intelligibility must be built.
/Anders W. Tell
Reimagining Architectural Understanding
