Zettelkasten vs. Wiki: Linked Notes or Shared Reference?

The useful distinction between Zettelkasten and a wiki is developing ideas versus maintaining reference answers. A Zettelkasten connects focused notes so you can build understanding; a reference wiki organizes pages so readers can find a clear, current explanation. They overlap: wiki software can also hold a personal Zettelkasten.

If a team and its AI assistants need to know which conclusions are approved for active work, fenbs can keep that project context and its decisions alongside either arrangement. Personal exploration, shared reference, and current project direction can support each other without being treated as the same kind of record.

What are you choosing between in practice?

This is not a strict separation between private and shared, or between short and long. A personal wiki can contain exploratory writing. Shared idea notes can support collaborative research. The comparison concerns the job you ask the collection to do, not a rule about who is allowed to use it.

You can find related approaches in the second-brain library. For this decision, choose a representative question. “What might explain this pattern?” favors exploration. “What is our current procedure?” favors a maintained answer with a clear owner.

Why do two collections of linked pages behave differently?

Links alone do not define the method. The Zettelkasten introduction↗ (opens in a new tab) emphasizes connections between individually addressable ideas. A link should help explain how one thought supports, qualifies, contradicts, or applies another. The collection grows as you work through questions and make those relationships useful.

A reference wiki asks a different question of each page: what should a reader understand or do after reading it? For a team preparing a museum exhibit, an exploratory note might ask whether a chronological layout changes the story. A reference page might explain the team’s current process for checking object labels.

Both can change. The idea note changes when your understanding improves; the reference page changes when its answer needs correction or the process changes. Trouble begins when readers cannot tell whether they are looking at a possibility, an accepted explanation, or an instruction they are expected to follow.

Write that distinction in the content. “Working explanation” tells a colleague to examine the reasoning. “Current labeling process, maintained by the exhibit editor” sets a different expectation. You do not need a complicated system to make those purposes visible.

How should you shape an idea note and a reference page?

An idea note should make its claim understandable without requiring you to reconstruct the original reading session. State the point, give the reason or evidence, identify its limits, and explain important connections. A focused title lets you recognize the thought later. Do not split an argument until its pieces stop making sense.

A reference page should start with the answer or procedure its reader came for. Use descriptive headings, name the audience, and place exceptions close to the step they affect. A long page can be perfectly appropriate if its structure helps someone reach the part they need.

• Idea note: what is the claim, why might it hold, and what other idea changes it?
• Reference page: what is the current answer, who uses it, and what should they do?
• Either: where did the information come from, what remains uncertain, and how will a future reader check it?
• Project record: which choice did a person make, what does it affect, and what happens next?

For the exhibit example, do not make a new contributor follow a chain of personal reflections to discover the label review process. Give them the maintained procedure. Link to the reasoning when it helps, and keep the current exhibit’s approved departures from that procedure in its project decisions.

How do sources, revisions, and approval fit together?

Preserve the source behind a material claim in either collection. Identify the relevant passage rather than saving a bare homepage. Separate an exact quotation, a source’s claim, and your interpretation. An idea can be interesting while its support remains incomplete; a maintained page should say when an answer is provisional.

Some wiki software gives you useful editing and revision features. MediaWiki’s editing guide↗ (opens in a new tab) describes changing and saving pages, while its history guide↗ (opens in a new tab) explains viewing older revisions and comparing them. Those features help a team inspect how text changed.

Revision history and approval answer different questions. Knowing who edited a sentence does not tell you whether the right person approved the policy it describes. Set a convention for proposed changes and accepted changes. Name who maintains a reference page, and keep decisions about active work explicit.

In the exhibit project, an assistant may suggest shortening labels. That is an option until the responsible person chooses it. Keeping the choice in fenbs’s Decisions and rules gives the project a clear record while the research and reference pages retain their own purposes.

What does a team need that personal notes may leave implicit?

Personal notes can rely on your memory of the situation. A teammate lacks that background. Explain unfamiliar terms, the scope of a conclusion, and why the source matters. If you share a link to a note that only makes sense to you, you have shared storage without necessarily sharing understanding.

A team also needs ownership. Someone should know when a reference answer needs review and who can settle a disagreement. That does not mean one person writes every page. It means readers have a dependable route from “this seems wrong” to a corrected answer, instead of quietly maintaining private workarounds.

Access needs an explicit choice as well. Check the actual tool’s permissions and the material’s audience before sharing it or making it available to an assistant. A personal note can contain assumptions or sensitive working material that should not become a general team reference merely because it is relevant to the same topic.

For AI work, keep the current project direction separate from the entire shared library. The team AI memory guide covers that shared work layer. fenbs project context gives a connected assistant the present goal and progress alongside the reviewed conclusions.

Can you use both without publishing all your rough thinking?

Yes. Treat publication into a shared reference as a deliberate review step. An exploratory note can remain personal while you extract a conclusion for others. Preserve the relevant source and the limits of the conclusion. You do not have to expose every abandoned interpretation to give the team a well-supported answer.

1. Explore the question in your notes, keeping claims and source references distinct.
2. Write a short answer for the intended reader and check it against the evidence.
3. Ask the appropriate person to resolve choices that need approval.
4. Publish the maintained answer in the shared reference, with ownership and scope clear.
5. Record any project-specific choice and the next action in the project’s work record.

The flow can go the other way too. A question from a reference reader may reveal an exception worth investigating in your idea notes. Update the maintained answer when the investigation changes what readers should know. Link to detailed reasoning where useful, while preserving a direct route to the current answer.

A shared AI brain complements this arrangement by keeping the work record accessible to the right members and their connected assistants. It does not require everyone to adopt the same personal thinking method. fenbs’s team workflow keeps their project choices and next steps together.

How to do this with fenbs

1. Create a free account and add a project that needs a reviewed answer from your notes or wiki. One person can begin free, with no credit card.
2. Write a concise context note with the accepted finding, its uncertainty, and the references that support it. Keep long reference documents in their existing home.
3. Record the person’s project choices in Decisions and rules. Add the task that applies the choice, including what still needs checking.
4. When colleagues need access, use a team kanban board and give members suitable roles. Connect supported AI apps through the integration guides.
5. Ask the assistant to read Rules and Where we left off before working, then save progress at the end. Check that the next session can name the decision and the unfinished work.

fenbs is not the right fit as a replacement for a general-purpose wiki or a personal collection of long essays. Use it when reviewed knowledge needs to guide active tasks and AI-assisted handoffs. It keeps the work, while your note or reference tool keeps the fuller explanation.

Which arrangement should you start with?

Start with a few focused linked notes when the hard part is developing your own understanding. Start with maintained reference pages when readers repeatedly need the same answer. You can use one tool for both, provided the difference between exploration and reference stays visible.

Test with a real handoff. Ask someone who was not part of the original discussion to find the answer, explain its source, and identify what remains uncertain. Then ask a connected assistant to explain the current project choice. Any mismatch tells you which record needs clarification before you expand the collection.