Documents or databases? Structured knowledge management ends a false choice
Most team knowledge lives either in free-form documents (wikis, pages, Word files) or in rigid databases and spreadsheets. Documents are easy to write but impossible to query. Databases are queryable but nobody writes context into them. Structured knowledge management combines both: documents built from blocks, plus typed objects with properties and relations. The same knowledge reads as a page and queries like a database.
Why wikis rot
A wiki fails in a predictable way. The same fact, say a supplier’s contact, a pump’s maintenance interval or a server’s owner, gets written into five different pages. One page gets updated after a change. The other four keep the old value with full confidence. There is no single source of truth, because prose has no notion of “this is the same fact”.
Why databases don’t replace them
The reflex answer is “put it in a database”. But a row in a table carries no narrative. Why is the interval six months and not twelve? What went wrong last time? Which exceptions apply? People stop consulting a system that holds facts without context, and stop updating a system they don’t consult. Spreadsheets inherit both problems and add silent formula drift.
Typed objects: facts with a shape
The structured approach gives important things an identity. A machine, a procedure, a client or a server becomes an object with a type, properties and relations. Objects are embedded in documents where the story is told, but the fact lives once, on the object. Update the maintenance interval there and every document referencing it is current.
The knowledge graph: relations you can walk
Once knowledge has objects and relations, it forms a graph you can navigate and question. Which procedures involve this equipment? What depends on this server? Which clients are affected if this component changes? That impact analysis is exactly what free-text search cannot answer.
Branching: engineering discipline for documentation
Code teams solved “how do we change something important safely” long ago: draft on a branch, review, merge. Applied to knowledge, the same flow lets you rework a critical procedure calmly while the current version stays authoritative. Then you merge the change with a trace of who reviewed it. For regulated or safety-relevant operations, that trace is the difference between documentation and documentation you can trust.
Who actually needs this
Teams whose knowledge is dense with interconnected facts: engineering and operations, asset and infrastructure management, anyone maintaining procedures that reference equipment, systems and people. If your team’s wiki keeps drifting out of date while the “real” data hides in spreadsheets, you are the audience.
Written by Yuma Idrissa