Zettelkasten With an LLM: Keep Every Claim Traceable

To use a Zettelkasten with an LLM, give the language model a small set of identified sources, ask for focused draft notes, and verify each claim against its source before saving it. Keep quotations, your interpretation, and suggested connections distinct. fenbs can hold the research tasks and reviewed project context that result, while the linked notes remain in your research collection.

What should you give the model first?

1. Choose a specific research question and a small packet of relevant sources.
2. Assign a stable identifier to each source and retain its title, author, version, and location.
3. Include the passages needed to evaluate the question, with page or section references.
4. Ask for draft claims supported only by those passages, with unsupported ideas listed as questions.
5. Review the output against the originals before adding any note or connection to your collection.

An LLM, or large language model, generates language from patterns rather than serving as a source of record. The LLM introduction explains the technology; this workflow focuses on keeping research traceable. A clear source packet makes it easier to identify where a plausible sentence exceeds the evidence you actually supplied.

Include only material you are permitted to share with the chosen service. For a long document, select a relevant passage with enough surrounding context to preserve conditions and qualifications. Keep a reference to the complete original so a later reader can inspect what your selection left out.

How should a draft note separate evidence from interpretation?

Ask for one claim per draft note, expressed in plain language. Require a source identifier and a precise location for each claim. An identifier such as S03 is useful only if your source register resolves it to a real document; it should never be a citation the model invented.

Use only sources S01 and S02 below.
Research question: What makes the instruction sequence unclear?
For each candidate note, return:
- One claim in plain language
- Source ID and page or section
- Exact supporting passage, clearly marked as a quotation
- Interpretation, separately labeled
- Limitation or unanswered question
Do not invent a source, locator, quotation, or note ID.
If the material does not support a claim, say so.

Treat the labels as a review aid, not proof that the model followed them. A sentence may contain both a supported observation and an unsupported explanation. Split it before saving. For example, a document may place a warning after a procedure without establishing that users failed because of that placement.

Rewrite the accepted note in your own words and preserve the checked source location. Keep any quotation visibly separate. Your future self should be able to tell whether a statement came from the author, your reasoning, or an untested model suggestion without reopening the original chat.

What changes when you use a source-based notebook tool?

A source-based notebook provides a place to select documents and ask questions about them. Google’s Gemini Notebook source guide↗ (opens in a new tab) explains adding sources and selecting relevant ones. That can make a bounded research session easier to manage than repeatedly pasting extracts into an ordinary conversation.

Google’s chat documentation↗ (opens in a new tab) describes source citations you can select to inspect the supporting passage. Open those citations before accepting a note. A clickable reference helps you check the evidence; it does not establish that your eventual interpretation follows from it.

Keep your own source identifiers and locators in notes you intend to retain elsewhere. Test whether someone outside the current notebook can understand and access the reference. For imported material, also check which version the notebook holds, especially when the original document may change.

How do you check a claim before accepting it?

Read the cited passage in its original context, then compare it with the proposed claim. Look for changed scope, missing conditions, stronger causal wording, and certainty the author did not express. Check numbers, names, and quotations directly rather than asking the same model whether it is confident.

• Existence: does the cited source and location actually exist?
• Accuracy: does the quotation match the source, including any omitted wording?
• Support: does the passage establish the whole claim, or only part of it?
• Scope: does the note preserve the population, setting, and limits of the source?
• Status: is this accepted evidence, your interpretation, or a question for further work?

NIST’s Generative AI Profile↗ (opens in a new tab) identifies confidently presented false content as a risk and recommends reviewing sources and citations. Use that as a reason to inspect evidence, not as a reason to abandon useful drafting help. A model’s clear prose can make an unsupported extension harder to notice.

When an unchecked statement affects active work, create a research task instead of recording it as a rule. fenbs keeps the open question and current context available for the assistant that investigates next.

When is a proposed connection worth saving?

A proposed connection should identify two existing notes and explain the relationship. Shared vocabulary is only a starting point. Decide whether the relationship is support, contradiction, a prerequisite, an example, or an analogy, then inspect the evidence needed for that specific relationship.

Say one note concerns museum instructions and another concerns software setup. They may suggest a useful comparison about sequencing. They do not prove that the same change will produce the same result in both settings. Label the comparison as an analogy and retain the differences that might matter.

Keep only connections you can explain independently. Broader habits for questioning and connecting existing notes belong in the Zettelkasten AI workflow; here the extra requirement is preserving the evidence behind each claim that crosses between notes.

What happens when a source or conclusion changes?

Identify the affected note, preserve the source version you used, and write what changed in the conclusion. Then check notes that relied on it. A source correction may require changing an argument; a changed webpage location may require only repairing a reference.

Review the active project separately. A research correction does not silently replace a person’s decision. Record the new evidence, identify the earlier choice it may affect, and ask the person to reconsider it when needed. Keep the pending review visible so the next assistant does not mistake a suggestion for approval.

How to do this with fenbs

1. Create a free account, free for one person with no credit card, and add the research project.
2. Add selected source references to Links and listings and put your checked conclusion, scope, and note identifiers in AI context notes.
3. Create tasks for missing evidence. Record a person’s accepted direction in Decisions and rules, keeping model suggestions separate.
4. Connect a supported assistant through Integrations, ask it to read project context before working, and save its checks and next step before stopping.

fenbs does not import your notebook or read its private documents from a saved link. It is not the right fit for full-text research analysis or hosting a model. If you need a model you can operate yourself, the open-source LLM guide covers that separate choice.

For more ways to keep research usable, visit the second-brain topic hub. A source reference should let a person retrace the reasoning, while the project record should explain what to do next.