The Question Nobody Asks Before Building an Org Knowledge Environment
Updated: Sep 17
TL;DR: Most knowledge platforms are built from a content question: what do we have, and where should it go?
The result is a structure organised around containers, which works for storage and fails for reasoning. AI is now reading that structure as if it were meaning.
There is a more important question, how does this organisation actually think, and it is answerable across five observable dimensions. The answer is what a knowledge structure should be derived from. This piece lays out the five.
Open your knowledge platform and look at the top level. Not the content. The structure. There is a reasonable chance your org chart is looking back at you.
A space for each department. A folder for each team, then sub-folders by project, by year, by document type. Somewhere, a section that mirrors a shared drive from two systems ago, migrated intact because untangling it was never anyone's job. And if you have no platform to speak of, only shared drives, look at those instead. Same shape. Same reason.
Nobody chose this structure, exactly. It accumulated, one reasonable decision at a time.
And it accumulated from a question. When an organisation begins to build up a knowledge platform, the question it asks, almost without noticing, is: "what do we have, and where should it go?"
It's a content question. So it produces a content answer: knowledge organised around containers. Departments, document types, project folders, legacy locations. The same logic that organised filing cabinets for a century, carried into software that could have done something else.
To be clear, a department space is not automatically wrong. People often navigate through the teams, functions and domains they recognise. The problem is when that becomes the only organising logic. A knowledge environment should be recognisable to the people who use it, but it should not simply reproduce the org chart or the old drive structure. It should reflect how knowledge is owned, applied, trusted and changed.
When the organising question remains “what do we have, and where should it go?”, the result is typically a structure optimised for storage and retrieval. Which is exactly what the question asked for.
But storage was never the point. Nobody funds a knowledge environment so files have somewhere to sit. They fund it so people can find what's true, rely on it, and make the next decision coherently. And increasingly, so AI can do the same. The point was always reasoning. The structure they ended up with wasn't built for it.
For a long time, people made up the difference themselves. The structure didn't carry the meaning, so they carried it: which page is current, which one lapsed, which is the real rule and which is one team's workaround that quietly hardened into habit. They searched, and asked the person who asked someone else. Often they found what they needed. Sometimes they found something that only looked right, and acted on it, because nothing on the page told them not to. The cost of that surfaced later, somewhere downstream, where no one thought to trace it back.
It worked, in the way a thing works when people are quietly holding it together. Then we connected AI.
An AI layer doesn't interpret your environment the way your people do. It has no memory to supply the missing meaning, no instinct that a page feels off. It uses the structure as meaning signals. Hierarchy, proximity, links, labels, metadata: these are the signals it uses to decide what is authoritative, what is current, what belongs together. If the structure encodes an org chart and a filing history, that is the meaning available. So a team's workaround gets returned as company policy. A draft nobody approved carries the weight of the decision it never became. Three versions of the truth collapse into one confident answer. The judgement people used to supply is no longer automatically present, and nothing in the structure replaces it. Technically sourced. Organisationally misleading.
The instinct at this point is to blame the tool, or the content, and launch a documentation clean-up. Better naming, fewer duplicates, an archive sweep. Useful, and not the problem. The problem sits underneath: the existing structure was derived from the wrong question, and tidying doesn't change what it was built to represent.
Before a single space or template is designed, before anything is migrated, there is a prior question almost nobody asks: how does this organisation actually think?
Not personality. Not culture in the vague sense. I mean something more practical: who can say what is true, what a decision depends on, how fast knowledge changes, whether words mean the same thing across teams, and where new knowledge is created before it becomes documented.
That sounds abstract. It isn't. How an organisation reasons is a set of observable, diagnosable patterns. Structural, not psychological.
Importantly, the unit of analysis is not the whole company. It is the knowledge area: a bounded subject the organisation relies on to make decisions or do work. Pricing rules. Customer definitions. Supplier knowledge. Incident response. Sales qualification. Regulatory interpretation. Each may have a different authority pattern, dependency chain, cadence, level of shared meaning and creation route.
In our work they resolve into five dimensions.
1. Decision topology: where authority to act actually sits
Not where the org chart says. Where decisions actually happen. Many organisations have formally centralised decision rights and operationally distributed decision-making, because speed and local context push decisions to the edges. And the pattern differs by knowledge area: some knowledge has one owner of its truth; some has a canonical source that teams legitimately adapt to their context; some genuinely varies, because the contexts genuinely differ. A structure that cannot represent these differences will present a local adaptation as a company-wide rule, or collapse three legitimate approaches into one false universal.
2. Dependency chains: what has to be known before someone can act
Every significant decision relies on a chain: facts, definitions, constraints, precedent, judgement. Consider approving a non-standard customer request. The person deciding might need product specifications, pricing authority, regulatory constraints, contract terms, similar past cases, and the strategic weight of the relationship. Six areas of knowledge, likely in six locations, with no path between them. The chain exists. It's just invisible, held together by the memory of whoever made this decision last time.
3. Reasoning cadence: how knowledge ages and understanding changes
Not all knowledge changes at the same rate, and the rate carries information. Some knowledge is foundational: it rarely changes, and carries high authority while it holds. Some moves with planning cycles. Some changes only when an event fires, a regulation, an incident, a market shift, and the real question is whether the trigger propagates. Some is still forming, and not yet anyone's position. A policy page untouched for three years might be perfectly current or dangerously stale. The structure usually can't tell you which. Neither can anything interpreting it.
4. Mental model coherence: whether the same words mean the same thing
When someone says "premium customer" or "critical incident," does everyone in the room hold the same meaning? In some organisations, yes. In many, the terms are used constantly and mean different things to different teams: an illusion of alignment masking real operational divergence. People navigate this from context, mostly. AI conflates the meanings without warning, and semantic ambiguity in the knowledge base becomes semantic confusion in every answer built on it.
5. Creation patterns: where knowledge is actually created
Some knowledge is written deliberately: policies, procedures, specifications. Far more emerges in conversation, in workshops, forums, and decisions made in the flow of work. Some sits inside experienced people as judgement and pattern recognition, and never gets written at all. If the platform only has a home for the first kind, it captures the documented tip while the iceberg stays invisible. And anything reasoning from the platform reasons from the tip.
Together, these five form a diagnostic. We call it an Organisational Reasoning Profile.
It is not a maturity assessment and it doesn't produce a score. It produces a characterisation of how a specific organisation reasons, area by area, because the same organisation may reason one way about governance standards and another way entirely about emerging commercial practice. Two organisations in the same industry can hold radically different profiles, and both can be valid. The profile is not about what's wrong. It's about what's real, and therefore what the structure must serve.
But serving what's real is not the same as preserving it in place. Some of what the profile surfaces is genuine fragility, not legitimate variation: meaning that only looks shared, dependency chains no one can see, triggers that fire and never propagate. Encode those faithfully and you make them permanent. So the architecture reflects how the organisation reasons now, and where that reasoning is weak, it makes the weakness visible rather than burying it. Which is the first condition for better reasoning over time.
This is where knowledge architecture begins. Not with a platform, a migration plan, or a generic set of spaces, but with the profile, because the profile is the translation layer between how the organisation thinks and how its knowledge environment should be structured. From it, the design becomes derivable rather than default: which bodies of knowledge need governed homes, what orientation people meet inside them, and what every page must carry for a person, or an AI, to know what it is, how current it is, and how far it can be trusted.
How an organisation thinks also keeps moving. New dependencies form, authority shifts, terms drift, yesterday's emerging practice becomes today's standard. An architecture built from the profile has to account for that, or it decays the way the folders did, one reasonable addition at a time, back into the sprawl we started with.
Ask the content question and you get a repository. Ask the reasoning question and you get an architecture.
Structure always follows something. The important choice is what.
Comments