← Blog
2026-10-22· Updated: Oct 22, 2026

Obsidian for teams. Organising projects, decisions and versions

Obsidian for teams. Organising projects, decisions and versions

A practical vault structure, decision template and migration method for knowledge that a team can retrieve and maintain.

Start with a question the team needs to answer

Before creating folders, ask which past decision you need to recover and what evidence would make it trustworthy. My approach comes from building and using Superbrain. A useful system returns an answer, its source and the difference between a historical decision and the current state.

This article proposes a starting structure. It is not a claim that I have delivered this exact implementation for a client. Obsidian provides the linking tools; the team still needs shared working conventions.

Make the project note the entry point

Use one project note to link the brief, decisions and deliverables. Keep large drawings and photographs in their established repository when that workflow already works. Record the current version rather than duplicating every file.

Start with an index, projects, decisions, shared resources and an archive. Each project needs an owner, status, review date and related links. The index tells you where to look; the project note explains the current situation; a decision note explains why.

Record the reasoning while it is still available

A decision record should contain the date, context, alternatives, choice, reason, owner and supporting evidence. Mark proposals explicitly. Do not allow an unapproved idea to look like the final decision.

Native templates can make that structure repeatable. Test the required fields on real work before adding plugins. Agree on naming conventions so that two people do not create separate records for the same project.

Pilot before migrating the archive

Choose one finished project and one active project. Try to locate a current deliverable, explain a past decision and identify its owner without asking in chat. The finished project tests retrieval; the active project tests whether the process fits everyday work.

Inventory first, then migrate a representative sample and review it before importing more. Keep a backup and a migration log. Moving files into a new application does not make an unreviewed archive reliable.

Measure retrieval and maintenance

Track the time required to recover a decision, broken links and records without owners or review dates. These observations tell you whether the structure works without inventing a percentage improvement.

An AI assistant can become a retrieval layer later. Establish access, sources and maintenance first. See the related guide on separating assistant memory from the model for that next step.