[[Obsidian]] is built for one person — the question for an organisation is what has to be assembled around it (git, permissions, review flows) for the vault to work collectively, and whether the result is worth the assembly. ## [[Obsidian]] ![[Obsidian#^definition]] Built around individual workflows; multi-user collaboration relies on git or external infrastructure. ## [[Collective knowledge management]] fit Each requirement below gets a verdict against [[Obsidian]] in an organisational context. Each sub-section transcludes the underlying pain question and follows with Obsidian's actual fit. ### [[Discoverability]] ![[Knowledge problems#^discoverability]] Strong. Backlinks, graph view, and plugin-extended search ([[Obsidian Dataview]], [[Obsidian Bases]]) make findability first-class. Relationship structure is visible by default through the graph view; backlinks surface incoming connections without anyone curating them. ^discoverability ### [[Maintainability]] ![[Knowledge problems#^maintainability]] Mixed. Markdown on disk is cheap to update; plugins automate routine changes. But concurrent multi-user editing produces merge conflicts that have to be resolved manually. Manageable through git, but the editing experience is not collaborative - and routine multi-author edits incur a workflow overhead beyond the writing itself. ^maintainability ### [[Connectivity]] ![[Knowledge problems#^connectivity]] Strong. Wikilinks are first-class; backlinks panel surfaces incoming connections; the graph view exposes the relationship structure for inspection. Every connection is explicit and queryable - no inference layer, no confidence tier, just authored edges between artefacts. ^connectivity ### [[Survivability]] ![[Knowledge problems#^survivability]] Strong. Plain Markdown on disk; no vendor lock. The vault remains readable in any text editor today and in fifty years. [[File over app]] is the operating principle - the knowledge is in the files, not in the tool. ^survivability ### [[Securability]] ![[Collective knowledge problems#^securability]] Weak. No native permissions model. A vault is all-or-nothing for everyone with access. Granular per-folder or per-note access requires git permissions, filesystem ACLs, or separate vaults - external tooling, not Obsidian features. ^securability ### [[Ownership clarity]] ![[Collective knowledge problems#^ownership-clarity]] Not addressed natively. No built-in owner field that drives review cycles. Ownership can be added via frontmatter convention but is not enforced by the platform; git history surfaces who last changed what but not who is responsible for keeping a note true. ^ownership-clarity ### [[Agent-readiness]] ![[Collective knowledge problems#^agent-readiness]] Strong. Markdown is parseable. YAML frontmatter carries typed fields predictably. Wikilinks are extractable as graph edges. Many community tools, CLIs, and MCP servers already work directly with Obsidian vaults - no Obsidian-specific adapter required. ^agent-readiness ## Verdict - [x] [[#Discoverability]] - [/] [[#Maintainability]] - [x] [[#Connectivity]] - [x] [[#Survivability]] - [-] [[#Securability]] - [-] [[#Ownership clarity]] - [x] [[#Agent-readiness]] ^verdict Adopt where data ownership, durable formats, relationship-rich modelling, and agent-readability matter - and concurrent multi-user editing is rare or handled via git. Avoid where granular [[Securability|access control]], audit-bound [[Ownership clarity|attribution]], or seat-managed permissions are required without assembling external tooling. ^answer The conclusion lives in none of the requirements on its own. Obsidian's strengths cluster on the discovery / connectivity / survivability / agent-readiness side; its weaknesses cluster on the access-control / ownership / real-time-collaboration side. Whether to adopt depends on which cluster matters more for the organisation's pain.