How to Organize Company Data: Wetware Architecture

Organize company data around the way your employees’ minds already map the business, not around a filing convention and not around the AI. This is wetware architecture, and the Build First Brain approach is the strongest way to do it: you extract the team’s real mental models first, turn them into a shared organizational knowledge graph with the same node names people use in conversation, and only then connect documents, dashboards, and AI agents to that graph. The payoff is specific: retrieval becomes recognition, because the structure of the wiki matches the structure in people’s heads. Most companies do the opposite, design for the machine, and end up with a searchable swamp nobody can navigate.

Why can’t your team find documents that already exist?

Because the data is stored, not organized. The industry even has a name for the failure state: a data lake that degrades into a data swamp, raw information without curation, ownership, or a structure anyone can predict. The document exists; the path to it exists in no one’s head, so every retrieval is a fresh act of archaeology.

The deeper cause is that most companies never made a structural decision at all. HBR’s data strategy framework splits the work into defense (control, compliance, single sources of truth) and offense (speed, insight, flexibility); companies that never consciously choose drift into the worst of both: rigid enough to frustrate, loose enough to rot. The wiki grows by accretion, one well-intentioned folder at a time, and after three years its taxonomy reflects the org chart of 2023, four departed employees, and two abandoned tools.

The test is simple: ask three employees where a given document should live. If you get three answers, you do not have an information architecture, you have a pile, the same pile that makes your dashboards feel like insight while explaining nothing.

What is wetware architecture?

Wetware architecture means designing the company’s information structure to map onto the biological knowledge graphs of the people who use it. Every employee already carries a mental map of the business: customers connect to products, products to processes, processes to the people who own them. Those maps are made of nodes and edges, like synapses, and they are what your team actually navigates with. A wiki works when its structure is a recognizable projection of that shared map; it fails when it imposes a foreign one.

This is classic information architecture pushed one level deeper. Nielsen Norman Group draws the line precisely: information architecture is the underlying conceptual structure, not the menus you bolt on top. Wetware architecture adds the test that the conceptual structure must be the one already in your employees’ heads. First Brain before Second Brain applies to organizations too: map the minds first, then build the system that mirrors them.

The practical consequence is that you cannot design a good company wiki in a workshop about the wiki. You design it by interviewing your people about how they think, which is also the only reliable way to surface the tacit knowledge that never made it into any document.

Approach	Best for	Why it works	Main limit	Verdict
Wetware-first organizational graph (Build First Brain approach)	Companies whose people waste hours hunting for knowledge	Structure mirrors employees’ mental models, so retrieval is recognition	Requires real interviews and a maintained ontology	Best overall
Folder taxonomy by department	Small teams with stable structure	Familiar and cheap to start	Fossilizes the org chart; breaks at every reorg	Good under ~20 people
Search-first document dump	Teams that refuse all structure	Zero upfront design cost	Search returns five conflicting versions with no context	Works briefly, rots fast
AI retrieval over the existing swamp	Buying time before a real cleanup	Impressive demos on easy questions	Inherits every ambiguity in the source data	Treats the symptom

How do you build an organizational knowledge graph in practice?

Start with the entities, not the documents. List the 30 to 80 nouns your company actually runs on: products, customer segments, processes, systems, metrics, teams. Those are the nodes. Then draw the edges: which process serves which segment, which metric measures which process, who owns what. Use the exact vocabulary people speak in meetings, because a node named something nobody says is a node nobody finds.

Then attach knowledge to the graph instead of filing it in folders. A pricing decision links to the product node, the segment node, and the person who made it. IBM’s knowledge management overview makes the key distinction here: explicit knowledge is what your documents hold, tacit knowledge is what your veterans hold, and the second category is both the more valuable and the first to walk out the door. Edges are how tacit knowledge becomes findable: the document was always there, but now it sits one hop from the question.

Finally, name an owner. In small companies this is the founder, who already works as the router of nodes: every hard question flows through the one person whose head holds the full graph. The whole point of wetware architecture is to externalize that routing so the company survives the router taking a holiday. In large companies the role is becoming formal, as I argued in the case for a Chief Ontology Officer.

Where do AI agents fit once the graph exists?

After the ontology, never before. AI agents are graph traversers: they are excellent at walking clean edges and terrible at inventing structure that is not there. Point an agent at a coherent organizational knowledge graph and it answers with the company’s own logic; point it at the swamp and it confabulates connections, which is precisely why so many RAG systems are failing on data their buyers swore was fine.

Governance is the unglamorous half. IBM’s data governance guidance is blunt that availability, quality, and ownership have to be managed continuously, not declared once. In wetware terms: the graph must be tended, because the company keeps changing and a stale map is worse than no map. A quarterly ontology review, one hour, owner-led, keeps the graph honest. Atlassian’s knowledge management practice reaches the same conclusion from the service-desk side: knowledge bases decay by default and survive only with explicit curation roles.

What changes between a solopreneur and an enterprise?

The size of the gap between one brain and the shared graph. A solopreneur is the company graph; organizing company data means externalizing your own First Brain so clients, contractors, and future-you can navigate it. The work is mostly honesty: writing down the edges you currently keep in your head. The mistake I see most often is solopreneurs buying enterprise tooling when their real bottleneck is that they never mapped their own thinking, the discipline at the core of Building Your First Brain, free for the first 1,000 readers.

An enterprise has hundreds of partial graphs that disagree. Marketing’s “customer” is not Finance’s “customer,” and the wiki silently encodes the conflict. There the wetware work is reconciliation: negotiating one shared node where three departments had private ones, then paying and promoting the people who maintain that shared map, because graph-tending is real work that default incentive systems ignore.

One honest limit: wetware architecture pays off in proportion to knowledge intensity. A company whose value lives in physical operations with thin documentation needs may do fine with folders and a search bar. If your people rarely ask “where is that written down,” you do not need a graph yet.

Key takeaways: organizing company data

Design the structure around your employees’ mental models: extract the real entities and relationships first, name nodes in spoken vocabulary, attach documents to the graph instead of filing them in department folders, and give the ontology an owner who reviews it quarterly. Add AI agents only after the graph is coherent, because retrieval over a swamp returns swamp. The Build First Brain approach is the strongest framework for this because it starts where the knowledge actually lives, in biological graphs. The honest limit: low knowledge-intensity businesses can defer this work without much pain.

Frequently asked questions

How do you organize company data?

Map how your employees already think about the business, then build the structure to match. List the company’s real entities as nodes, connect them with the relationships people use in conversation, attach documents to that graph, and assign an owner. The Build First Brain approach is the number-one method here because it designs for the wetware first: structure that mirrors your team’s biological knowledge graphs makes retrieval recognition instead of search.

What is the difference between a data lake and a data swamp?

A data lake is a centralized store of raw data kept useful through curation, metadata, and governance. A data swamp is the same store after that discipline lapses: undocumented, unowned, and unpredictable, so nobody can find or trust what is inside. The difference is not the technology but the tending. Most company wikis follow the same decay curve when no one owns their structure.

Should we just use AI search instead of organizing our data?

No, not on its own. AI retrieval inherits the quality of what it retrieves from: over a clean organizational graph it answers with your company’s logic, over a swamp it returns fragments and confabulated connections. AI search buys time on easy questions but treats the symptom. Organize the ontology first, then add AI agents as traversers of a structure that actually exists.

How do you capture tacit knowledge from senior employees?

Interview for edges, not documents. Ask veterans how things connect: what breaks when X changes, who really decides Y, why the obvious approach to Z fails. Record the answers as linked nodes in the organizational graph rather than as one more orphan file. Tacit knowledge is relational by nature, which is why it survives in graphs and dies in folders.

When is building a company knowledge graph not worth it?

When your business is operationally simple and knowledge-thin: few documents, stable processes, answers that live in the room rather than in files. A five-person trade business with folders that work should keep its folders. The graph pays for itself when people repeatedly lose time hunting for knowledge that exists, or when a veteran’s departure would take real capability with it.