# Action-Ready Second Brain: A Practitioner Dossier

**Research snapshot: October 3, 2026**

The central finding is straightforward: **the useful unit of a Second Brain is not the note; it is the future work situation that the information must support.** Personal-information-management research has long treated keeping, organizing, finding, and reusing information as separate activities, and research on project fragmentation shows that tool design can either reunify or scatter information belonging to the same project. citeturn11search0turn20view0

The best practical architecture therefore has three durable layers:

**Evidence** preserves what happened or what a source actually said: meeting records, transcripts, emails, source documents, clips.

**Working memory** preserves the compressed context needed to operate: projects, decisions, people/companies, reusable notes, procedures, research syntheses.

**Execution** preserves commitments: tasks, owners, due/follow-up dates, recurring work.

Capture is merely the temporary entrance to those layers. It should not become a fourth permanent warehouse.

This distinction matters because modern full-text search, backlinks, database views, and AI reduce the need to pre-classify every piece of reference material, but they do **not** eliminate the need to represent operational state explicitly. Search may find the sentence “Alice will send the proposal,” but a `Waiting on Alice` view requires the commitment, owner, state, and usually follow-up date to have been recorded as such. Unified-search research provides evidence that cross-format search can support refinding; the operational schema is what turns refinding into action. citeturn13search1turn3view2

My practitioner recommendation is therefore:

> **Capture broadly, structure selectively, promote state explicitly, preserve provenance, and maintain only information whose freshness changes what somebody should do.**

A system following that rule can remain useful for years without becoming a hobby that masquerades as work.

## Operating model and real-work lifecycle

### Practical operating model

The most effective mental model is **promotion, not filing**.

An incoming item starts life in its cheapest possible form. It becomes more structured only when future work justifies the cost. A passing idea can remain one line. A project affecting three people and four decisions deserves structure. A meeting transcript should not become thirty meticulously tagged atomic notes merely because it can.

That model is consistent with evidence that project context becomes harder to manage when related information is fragmented across format-specific collections. In a study of 20 computer users, Bergman, Beyth-Marom, and Nachmias found that interfaces encouraging project-oriented grouping led users to keep project material together, whereas interfaces organized around formats encouraged fragmentation. citeturn20view0

A practical lifecycle is:

**capture → recognize significance → promote if necessary → connect to active work → retrieve in context → update state → archive without destroying history**

The following is what that means in ordinary work.

| Real-work moment | What should happen immediately | What deserves promotion | What should be retrievable later |
|---|---|---|---|
| **An idea arrives** | Capture one sentence, optionally why it matters now. | Nothing unless it survives contact with reality; later it may become a project, research question, task, or reusable idea. | “What ideas did I have around this problem?” |
| **A meeting happens** | Preserve date, participants, notes/transcript and enough context to identify the meeting. | Decisions, actions, commitments, unresolved project questions, durable client/person context. | What happened; what was decided; who owes what; evidence for the summary. |
| **You research a topic** | Keep useful sources and provenance. Avoid writing a mini-essay about every source. | A synthesis when you expect to use the research; source records where provenance matters. | What has already been researched; which sources support which claims. |
| **A project starts** | Create one canonical project record. | Outcome, current status, next action, people, open questions, key sources. | “Where are we, and what should happen next?” |
| **A decision is made** | Record it when forgetting its rationale would later be expensive. | Decision, rationale/context, assumptions, status, source, follow-up. | What was decided, why, by whom, and whether it was superseded. |
| **Someone commits to something** | Put the commitment into the authoritative execution system. | Owner, project, due/follow-up date if meaningful. | “What am I waiting for?” |
| **You learn something reusable** | Keep the insight near the work that produced it first. | Promote it to reference/procedure only when reuse is plausible. | “Have we learned this before?” |
| **A project pauses** | Update the project’s resume block before context disappears. | Pause reason, last meaningful state, next restart action/condition, unresolved questions. | “What was I doing when I stopped?” |
| **Old work resumes** | Begin from the project summary, not the complete archive. | Update status and next action after reorientation. | Current state plus key historical decisions and sources. |
| **You prepare for a meeting** | Pull the person/company, project, prior meetings, waiting items and recent decisions. | Usually nothing yet. | A meeting brief, not a pile of search results. |
| **Work is handed off** | Give the recipient the canonical project record plus authoritative task/source links. | Clarify owner, next action, open risks/questions. | Enough context to act without a forensic reconstruction. |
| **A project completes** | Record outcome and final state. | Reusable learning, important decisions, final deliverables. | Why the project ended as it did and what may be reused. |
| **Work repeats** | Store the trigger in the execution system and the know-how separately. | Procedure/checklist and recurring task. | “What do I do?” versus “When must I do it?” |

This avoids a common error: **forcing every work event through the same note template**. A source, meeting, project and commitment have different lifecycles and therefore need different representations.

### Minimal Second-Brain design

The smallest system I would deploy for an individual consists of only:

| Component | Purpose |
|---|---|
| **Quick Capture** | Temporary landing point for things that cannot immediately be dealt with. |
| **Projects** | One page/file per meaningful active project, each with a resume block. |
| **Decisions** | Lightweight records for consequential decisions only. |
| **Reference / Sources** | Searchable notes and source material; minimal compulsory categorization. |
| **Tasks** | One authoritative execution system, inside or outside the knowledge tool. |
| **Archive** | Completed projects and historical material excluded from normal operational views. |

For a small team, add **People/Companies** only where relationship history matters and **Procedures** where recurring work must be consistently transferable. A universal Contacts database containing everyone whose name ever appeared in a meeting is usually bureaucracy disguised as structure.

A **Meeting database is optional**. You need searchable meeting records; you do not necessarily need meetings to be a richly structured entity unless you repeatedly query them by client, project, attendee or date. Notion makes database pages and properties natural, while Obsidian’s Properties and Bases now make similarly structured views possible over Markdown files without turning the underlying files into a proprietary database. citeturn14search24turn3view0turn4search3

The test for adding any new object type is:

> **Will its lifecycle, state, ownership, relationships or repeated query patterns be materially easier to manage if it is structured?**

If no, leave it a note.

## Capture, processing, and information shape

### Capture and processing flow

The right capture architecture is usually **many convenient input surfaces feeding one logical processing queue**, with direct-to-destination capture whenever the destination is obvious.

A literal single inbox is not mandatory. On mobile, voice may be fastest; on desktop, a hotkey; in the browser, a clipper; during meetings, the meeting record; from email, forwarding or a connector. Obsidian supports mobile apps, browser clipping into local Markdown, and URI actions capable of opening, creating or appending to notes; Notion offers mobile capture and a web clipper into workspace pages/databases. citeturn2search9turn5search1turn2search4turn5search21

What matters is whether these surfaces converge operationally.

| Capture method | Main advantage | Main failure mode | Recommended use |
|---|---|---|---|
| **One universal inbox** | You never ask “where should I put this?” while capturing. | A giant undifferentiated queue becomes a second job. | Good default for manual thoughts and ambiguous inputs. |
| **Several capture surfaces** | Each surface matches context: phone, browser, meeting, email. | Inputs become invisible because each has its own backlog. | Fine if they feed one review/search model. |
| **Direct to destination** | No later processing when project/entity is obvious. | Adds thinking friction at capture and invites misclassification. | Prefer for clear project notes, known meetings and explicit tasks. |
| **Voice** | Excellent when hands/attention are occupied. | Transcript lacks context and creates rambling material. | Capture thought + short intent; summarize later only if retained. |
| **Mobile** | Captures at point of thought. | Complex templates make capture unpleasant. | Optimize for text/voice first, metadata later. |
| **Email forwarding** | Saves source material without copying. | Near-zero friction can turn every email into “knowledge.” | Forward only when it becomes evidence/reference outside email. |
| **Web clipping** | Preserves source and original context. | “Read later” landfill; whole-page clips swamp retrieval. | Prefer selected passages plus a reason for keeping them. |
| **Meeting capture** | Preserves high-volume evidence automatically. | Every call becomes another isolated document. | Capture broadly, then promote actions/decisions/context. |
| **AI-assisted capture** | Can label, summarize and extract candidates. | False structure looks authoritative. | Let AI propose promotion; human confirms state changes. |

Notion’s Web Clipper can save web pages to selected workspace destinations, while Obsidian’s Web Clipper writes captured material into local Markdown. The capability is valuable precisely because it lowers friction, but **low friction also changes the economics of hoarding**: it becomes easier to collect material than to determine why it matters. citeturn5search21turn5search1

That is why I would deliberately make friction **asymmetric**:

**Human-generated thoughts:** extremely cheap to capture.

**Machine-generated volume, web clips and forwarded email:** require one tiny act of intent, ideally a highlight or a one-line “kept because …”.

**Operational commitments:** immediately become tasks/waiting items.

**Reference material:** may remain unprocessed and searchable unless it becomes useful.

This replaces the unrealistic goal of “inbox zero” with a more important distinction: **operational debt versus library backlog**. A hundred unread references can be harmless. Three unprocessed commitments can be disastrous.

After capture, every item should face only the decisions it actually needs:

| Question | Result |
|---|---|
| Is this noise or obsolete before it even enters the system? | Delete or ignore. |
| Is immediate completion cheaper than creating/maintaining a record? | Do it now. |
| Does somebody owe an action? | Create/update the canonical task or waiting item. |
| Does it change an active project? | Attach or summarize it in project memory. |
| Is it a consequential decision? | Promote to a decision record. |
| Does it change durable person/company context? | Update that entity. |
| Is it reusable evidence/reference? | Preserve with provenance. |
| Is its value uncertain and temporary? | Leave in capture/scratch; let it age out of attention. |
| Is the work finished but history still useful? | Archive. |

### Does explicit processing still matter when search is good?

**Less than it used to for reference; just as much for state.**

The *Stuff I’ve Seen* research explored a unified index across heterogeneous personal information precisely to support reuse and refinding. Current Obsidian search can query content, paths, tags, tasks and properties; Notion likewise treats the workspace as a searchable archive, while its current AI search layer can search Notion plus enabled connected applications. citeturn13search1turn3view2turn5search2turn6view1

That makes several old habits less necessary:

Topic-folder micromanagement can often be reduced.

Every source need not receive a taxonomy.

Every captured thought need not become an “atomic note.”

Every possible relationship need not be manually linked.

But search cannot reliably infer canonical state that was never recorded. **Search answers “where is that information?” Structured state answers “what is true operationally now?”**

Therefore:

> **Use search to replace filing. Do not use search to replace commitments, status, ownership, provenance or decisions.**

### Notes versus structured objects

A free-form note should remain the default. Promote it to an object when at least one of these is true:

**State changes over time.** Projects, tasks and decisions have statuses.

**The same question must be asked across many records.** “All waiting items,” “all active client projects,” “decisions this quarter.”

**Ownership matters.** Someone is accountable.

**Dates have operational meaning.** A due date, review date or decision date matters.

**Relationships are themselves useful.** Which meetings belong to this client? Which decisions constrain this project?

**A team needs a canonical answer.** Free-form ambiguity becomes coordination cost.

Notion’s database model makes this conversion easy because database rows are pages with properties, and relations can connect pages in different databases; rollups can then aggregate related information. citeturn14search24turn1search0

Obsidian remains file/note-centric, but the practical gap has narrowed: Properties provide typed YAML-backed metadata, while the core Bases plugin can create filtered, sorted and grouped database-like views while keeping each record as a local Markdown file. citeturn3view0turn4search3turn4search9

The trade-off is not “databases good versus files good.” It is:

**Notion:** structure is relatively cheap to create and query, so the temptation is to structure too much.

**Obsidian:** notes are cheap and portable, so the temptation is to leave operational state too implicit.

### Minimum useful metadata

Metadata earns its keep only when it powers a real retrieval question, view, automation, handoff or review.

A practical minimum is:

| Object | Metadata worth maintaining | Usually unnecessary |
|---|---|---|
| **Idea / ordinary note** | Creation date automatically; source if derived externally. | Status, owner, confidence, many tags. |
| **Project** | Status; owner in a team; next action; optionally review/restart date. | Dozens of lifecycle properties never queried. |
| **Task / commitment** | Status, owner, project, due or follow-up date where real. | Topic tags already implied by project. |
| **Decision** | Date, status, project, source, supersedes; owner/approver when relevant. | Generic “priority.” |
| **Meeting** | Date, participants, project/client where useful. | Elaborate categorization of meeting type unless queried. |
| **Person / company** | Relationship context; relevant organization; perhaps last contact if it is useful. | Hobby/profile CRM fields that nobody uses. |
| **Research/source** | Provenance; publication/access date where relevant; project/topic relation when actively used. | Review date for every article ever clipped. |
| **Procedure** | Owner if team-based; trigger/context; last verified when errors would matter. | Constant review schedules for low-risk procedures. |

Notion layouts can deliberately surface only the properties that matter on each database type, which is useful precisely because large schemas otherwise create visual and maintenance clutter. Obsidian’s own documentation describes Properties as appropriate for small, atomic structured data rather than rich content; Markdown itself belongs in the note body. citeturn14search16turn3view0

**Confidence** is useful for uncertain research claims, forecasts and hypotheses. It is usually pointless on ordinary meeting notes or project records.

**Tags** should exist only where you can name the future query they support. A tag created merely because a term appears in a note is usually an inferior full-text index maintained by a human.

### Folders, tags, links, backlinks and relations

| Mechanism | Best use | Poor use |
|---|---|---|
| **Folders** | Coarse boundaries: project, lifecycle, ownership, permissions, archive; particularly natural in file-centric systems. | Building a deep ontology where every note must have exactly one conceptual home. |
| **Tags** | Stable cross-cutting facets such as `waiting`, content format, or a small number of workflow classifications. | Hundreds of topical labels with few repeated queries. |
| **Manual links** | When the connection itself carries meaning: project ↔ decision, claim ↔ source, person ↔ meeting. | Linking every noun because linking feels productive. |
| **Backlinks** | Discovering which notes explicitly refer to the current item; impact/context discovery. | Treating backlink count as a proxy for knowledge quality. |
| **Database relations** | Canonical, repeatable entity relationships that drive views, filters, rollups and handoffs. | One-off connections better expressed as a normal link. |
| **Maps of content / index pages** | Curated entry points into stable, important domains. | Hand-maintained dashboards that merely duplicate search results. |

Obsidian backlinks show linked and unlinked mentions of an active note, so they can reveal context beyond ordinary forward navigation. That remains useful even with search because backlinks answer a different question: not merely “where does this term occur?” but “what has explicitly referred to this thing?” citeturn3view1

Notion relations are stronger where you want the relationship itself to participate in database logic. citeturn1search0

The practical stance I would adopt is **deliberate for high-value relationships, opportunistic for everything else**. Create a project-to-decision relation deliberately. Link a useful neighboring concept when you encounter it. Do not spend Friday afternoons “improving the graph.”

## Project memory, decisions, meetings, and tasks

### Project memory pattern

Every active project needs a tiny surface that can answer, without reading its historical archive:

> **What are we trying to achieve, what is true now, and what should happen next?**

I would keep this at the top of the project page/file:

```text
Outcome
What must be true when this is done?

Status
Active / Waiting / Paused / Done

Next action
The next concrete move.

Waiting on
Who or what is blocking progress?

Key decisions
Only decisions that constrain current/future work.

Open questions
Unknowns that could change direction.

People
Who matters and why.

Recent change
The last material change in state.

Sources / working documents
Canonical evidence and deliverables.

Restart note
Required when paused: why paused, restart condition, where to begin.
```

The rule should be **one-screen resumability**, not “comprehensive documentation.” That is a practitioner design recommendation rather than a measured universal threshold, but it follows directly from the fragmentation problem: the project page should reduce the number of separate artifacts one must reconstruct before acting. citeturn20view0

When pausing a project for weeks, update only four things:

**why it stopped; what the current state is; what remains unresolved; what the first restart action is.**

When completing it, convert the resume surface into a historical synopsis: outcome, major decisions, final deliverables and reusable learning. Archive the rest rather than polishing it.

### Decision-log pattern

A decision record is worth creating when a decision:

affects more than one person,

is expensive to reverse,

will constrain later work,

was controversial,

depends on assumptions likely to change,

or is sufficiently important that someone will later ask, “Why did we do this?”

Michael Nygard’s Architecture Decision Record pattern is useful far beyond architecture because it deliberately keeps the record lightweight: context, decision, status and consequences, with superseded decisions retained rather than silently rewritten. citeturn21view0turn21view1

For general work, I would adapt that to:

| Field | Minimum content |
|---|---|
| **Decision** | “We will …” or an equally unambiguous outcome. |
| **Status** | Proposed / Decided / Superseded. |
| **Date** | When the decision became authoritative. |
| **Rationale / context** | Why this option won; relevant constraints. |
| **Assumptions** | What had to be believed for it to make sense. |
| **Owner / approver** | Only where authority matters. |
| **Follow-up** | Anything the decision requires. |
| **Source** | Meeting, research, email or document containing evidence/discussion. |
| **Supersedes** | Previous decision if replacing one. |

The critical distinction is:

**Discussion** stays in the meeting/research record.

**Proposal** is explicitly `Proposed`.

**Decision** is authoritative and has a date/status.

**Rationale** says why.

**Assumptions** expose what may later invalidate it.

**Supersession** creates a new record and preserves the old one.

Do **not** update the old decision until it appears to have always said the new thing. Historical rationale is precisely the value of the log. Nygard explicitly recommends retaining reversed decisions and marking them superseded. citeturn21view1

### Meeting-to-memory pattern

A meeting record should be treated as an **evidence bundle**, not as the final home of everything that happened in the meeting.

Current Notion AI Meeting Notes illustrates what mainstream capture can now do: it can transcribe calls, identify key points and action items, create summaries with citations that jump back to transcript lines, and use configurable summary instructions. Notion also explicitly documents that transcripts can misread speech or contain words that were not said, especially with poor or limited audio. citeturn21view3turn21view4

A robust flow is:

| Information produced in meeting | Where it ultimately belongs |
|---|---|
| Raw transcript / recording evidence | Meeting record, subject to retention/security policy. |
| Human/AI summary | Meeting record. |
| Confirmed decision | Decision log, linked back to meeting. |
| Personal/team action | Canonical task system. |
| Someone else’s commitment | Waiting/commitment system. |
| Open project question | Project memory. |
| Durable client/person fact | Person/company context. |
| Reusable insight | Reference/research note if it deserves future reuse. |
| Speculation/discussion | Leave in meeting record unless promoted later. |

The meeting page can display links to the promoted items, but should not maintain a second independent copy of their state. Otherwise the task gets completed in the task manager while the meeting note still says “TODO,” creating two competing realities.

Notion now allows meeting notes to be placed in a default database, and the notes can be tied to calendar context. The same conceptual pattern works in Obsidian with a meeting template plus links/properties. citeturn21view2turn3view0

For AI recording, consent is not optional process trivia. Notion’s current documentation explicitly reminds users to disclose AI Meeting Notes and obtain consent, provides consent mechanisms, and notes that recording/transcription laws vary by jurisdiction; it recommends obtaining consent from all participants. citeturn21view2

### Task / knowledge boundary

The strongest operational rule in this entire dossier is:

> **A commitment should have exactly one authoritative state.**

Tasks may live in the Second Brain **or** outside it. What should not happen is having one task copied into a daily note, meeting note, project checklist and task manager, with nobody knowing which checkbox counts.

Notion can credibly act as both knowledge and execution system: its current task features include a centralized `My tasks` experience, sub-items and task dependencies, including dependency-driven date shifting. citeturn6view3

Obsidian can represent and search tasks in notes, and its Search supports task-specific queries, but its core knowledge model remains Markdown/files rather than a purpose-built team task lifecycle. More advanced task recurrence, notifications or workflow behavior often implies adding plugins or keeping execution elsewhere. citeturn3view2

I would choose as follows:

**Individual with light task needs:** either integrated or separate is fine; choose the tool you will actually check.

**Individual with heavy recurring/date/reminder needs:** usually keep a dedicated task manager as the execution authority and link tasks back to project memory where useful.

**Small team already operating in Notion:** a shared Notion task database is viable if ownership, status and due dates are consistently maintained. citeturn6view3

**Team whose execution already lives in another operational system:** do not duplicate it merely to make the Second Brain look complete. Link to it.

**Daily notes:** good capture/log surfaces, poor authoritative task stores unless the workflow explicitly moves unfinished commitments forward. Obsidian itself describes Daily Notes as date-based notes suitable for journals, daily logs and to-dos; that is a capability, not evidence that every task should stay there. citeturn3view4

A recurring piece of work should therefore be split:

**Task:** “Run monthly billing reconciliation” — recurring trigger, date, owner.

**Procedure:** “How billing reconciliation works” — knowledge, exceptions, links, checks.

That separation prevents procedural knowledge from disappearing when the task is completed and prevents the knowledge base from having to simulate a scheduler.

## Retrieval, maintenance, decay, and migration

### Retrieval patterns

A useful Second Brain should be designed backwards from the questions users actually ask.

| User question | Primary retrieval mechanism | Why |
|---|---|---|
| **What did we decide?** | Decision view filtered by project/person/date. | Decision is a stateful object, not just text mentioning “decide.” |
| **Why did we decide it?** | Decision rationale + linked source meeting/research. | Preserves motivation rather than only outcome. |
| **Where did this claim come from?** | Explicit source/provenance link. | AI/search similarity is not provenance. |
| **What have I already researched?** | Search across source/reference material, optionally narrowed by project; AI synthesis with citations. | Topic classification can remain light. |
| **What do I know about this client?** | Company/person context plus linked meetings, active projects, decisions and commitments. | Entity-centric aggregation. |
| **What am I waiting for?** | Saved `Waiting` view by owner/person and follow-up date. | Requires explicit operational metadata. |
| **What changed?** | Chronological activity/recent-change log, updated decisions/status. | Temporal question, not primarily a link question. |
| **What should I do next?** | Task view plus project `Next action`. | Execution question. |
| **What was I doing before this paused?** | Project resume/restart block. | Avoids rereading history. |
| **What should I know before meeting this person?** | Entity context + recent meetings + open waiting items + active projects + decisions. | Cross-object brief. |
| **Where else does this idea matter?** | Backlinks, links, search, AI-related-note discovery. | Associative question. |

This is why no single retrieval mechanism should dominate.

**Search** is strongest for remembered words/topics and broad discovery.

**Saved views** are strongest for operational subsets such as waiting, active, overdue or unowned.

**Properties** are strongest for exact state.

**Backlinks** are strongest for inbound context.

**Chronological logs** answer temporal questions.

**Explicit source links** answer provenance.

**AI** is useful when the answer requires synthesis across several records, provided the underlying state/provenance is trustworthy.

Notion AI Connectors currently search across the workspace plus supported connected sources and return source citations; current supported connectors include products such as Slack, Google Drive, GitHub, Linear, Gmail and Google Calendar, among others. However, Notion says initial connector ingestion can take up to 36 hours, newly created content may take up to roughly three hours to index, and highly aggregative questions across large amounts of information can be difficult. That makes AI search valuable for discovery but a poor substitute for authoritative live task state. citeturn6view1

### Daily and weekly maintenance

There is substantially stronger evidence for the general need to support keeping/refinding than for any specific ritual such as a Sunday weekly review or daily-note routine. Treat framework routines as interventions to test, not laws of nature. Personal-information-management research documents the difficulty of keeping and refinding material; it does not establish that every knowledge worker needs the same review cadence. citeturn11search0turn13search36

The lowest-maintenance approach is **event-driven updating plus bounded operational review**.

Update project memory when:

a consequential meeting ends,

a decision is made,

a meaningful status change occurs,

the project is paused,

ownership changes,

the project finishes.

Those moments are better maintenance triggers than “garden the knowledge base because Friday has arrived.”

A daily check is useful only for time-sensitive operational state: new commitments, today’s tasks, waiting items or capture that could cause something to be dropped. It should not involve rereading reference notes.

A weekly review is useful when you have enough concurrent work that projects and waiting commitments otherwise disappear from attention. Restrict it to:

**active projects → waiting items → stale next actions → unprocessed action-bearing capture → paused items whose restart date arrived.**

Do not review the entire library.

**Inbox zero:** optional.

**Operational inbox control:** important.

**Knowledge gardening:** best done on touch—improve a note when you retrieve it and discover the improvement would save future work.

**Periodic archival:** useful when completed material is polluting active views; not otherwise a virtue.

### Knowledge decay and archival

Not all knowledge “decays” in the same way.

| Content class | Correct decay strategy |
|---|---|
| **Historical evidence** — meeting transcript, original source | Preserve rather than “update.” It records what was true/said then. |
| **Decision history** | Preserve and supersede; never silently rewrite history. |
| **Operational state** — project/task/waiting item | Must remain current while active. Archive when finished. |
| **External factual reference** | Keep source/date; revalidate on reuse when freshness matters. |
| **Procedure** | Review after failures/changes and periodically only where stale instructions create real risk. |
| **Personal thought/idea** | Usually leave untouched until reused. |
| **Old project material** | Archive out of active views while remaining searchable. |

A recent PIM study specifically examining deletion found small negative correlations between deletion and reported retrieval success/satisfaction and argues for reversible demotion/archiving rather than aggressive deletion. It is a recent preprint rather than a mature consensus result, so its conclusion should be treated as suggestive rather than definitive, but it aligns with the practical economics: deciding what is permanently worthless can cost more than cheaply retaining it out of view. citeturn20view2

This suggests a useful design principle:

> **Demote before you delete.**

An archive can disappear from everyday navigation without disappearing from search.

“Last reviewed” dates deserve particular skepticism. They are useful for high-volatility or high-risk material—compliance procedures, pricing assumptions, operational runbooks, externally sourced facts that matter to decisions. A `Last reviewed` property on every idea and book note mainly manufactures maintenance work.

### Migration from existing archives

The default migration strategy should be:

> **Start the new operating model now; preserve the old system as a searchable legacy archive; migrate information when it becomes active.**

Do **not** start by reorganizing eight years of history.

Obsidian’s official import tooling currently supports migration from Notion, Microsoft OneNote, Evernote, Apple Notes, Apple Journal, Google Keep, Bear, Craft, Roam, Logseq, HTML, CSV, Markdown and several other formats. Because Obsidian stores its native notes locally as Markdown, old material can also remain ordinary files. citeturn17view1

Notion can export pages/workspaces as HTML or Markdown, and databases as CSV with Markdown subpages. Its documentation importantly warns that a full workspace export cannot simply be re-uploaded to recreate the workspace exactly, illustrating why “portable content” is not the same thing as “portable application behavior.” citeturn17view4

For each legacy source:

| Legacy material | Recommended treatment |
|---|---|
| **Old Notion workspace** | Export for safety; migrate active projects, current client context, unresolved decisions and procedures. Leave old completed work as legacy. |
| **Old Obsidian vault** | Keep readable as-is; bring active files forward selectively unless there is a compelling reason for one merged vault. |
| **Google Docs** | Leave searchable where they are unless actively reused; link or migrate on demand. |
| **Apple Notes** | Move only active/reusable material; Obsidian has a supported importer if that becomes the destination. citeturn17view1 |
| **Folders/files** | Preserve structure initially; index/link active material rather than redesigning every folder. |
| **Bookmarks** | Assume most are reference, not knowledge; migrate when reused. |
| **Old task lists** | Manually re-triage live commitments. Never bulk-import stale “open” status and assume it remains true. |

Eugene Yan’s published account of moving from Roam to Obsidian is one practitioner example of selective, pragmatic migration rather than treating migration as a knowledge-refactoring project. It is an anecdote, not empirical evidence, but it illustrates the lower-cost strategy. citeturn10search18

The biggest migration risk is **polluting the new active system with historical ambiguity**: stale tasks look live, old clients look current, superseded procedures surface next to valid ones, and AI/search cannot always know which one the user considers canonical. Separating `Legacy` from `Active` is therefore operationally more important than perfectly converting formatting.

## AI-assisted work and tool trade-offs

### AI-assisted work without custom infrastructure

Mainstream AI is already useful enough to change Second-Brain operations without building a custom retrieval stack.

The best use cases are those where AI **compresses or navigates information while a human retains authority over state**.

| AI use | Suitable autonomy | Required human check |
|---|---|---|
| Summarize a meeting | High for drafting | Check decisions, commitments, omissions. |
| Extract possible actions | High for candidate generation | Confirm task exists, owner and due date. |
| Extract decisions | Candidate only | Confirm it was actually decided, not merely proposed. |
| Prepare meeting brief | High | Check current operational facts and sensitive material. |
| Find related notes | High | Relationship is a suggestion, not truth. |
| Summarize project history | High | Verify important turning points against sources. |
| Draft from stored research | High | Check every material claim/provenance. |
| Find stale commitments | Good where explicit status/dates exist | Confirm that status has not changed elsewhere. |
| Answer workspace questions | Good for discovery/synthesis | Require citations for consequential answers. |
| Modify project/task state | Low without confirmation | Human approval should be the default. |
| Assign another person work | Low | Human confirmation mandatory. |
| Delete/archive canonical material | Very low | Human confirmation mandatory. |

Notion’s integrated AI now operates across pages, docs, tasks and databases, includes meeting transcription/summarization and workspace/connector search, making it a concrete example of this mainstream-AI pattern. citeturn16search7turn6view1

There are five operational failure classes.

**Summary error or omission.** Notion itself documents that meeting transcripts can contain words that were never spoken or mis-transcribe speech. Its transcript-linked citations are therefore valuable because they reduce the distance between generated summary and source evidence. citeturn21view4

**Incorrect action inference.** “We should maybe ask Sam” is not necessarily “Sam owns this task.” This requires human confirmation because models convert linguistic possibility into apparently clean structured output surprisingly easily.

**Staleness.** Connected search is not necessarily instant. Notion documents delays during initial connector ingestion and for new content. citeturn6view1

**Silent document corruption.** A 2026 preprint from Microsoft researchers evaluating 19 models across long document-editing workflows reported that even the tested frontier models corrupted an average of about 25% of document content by the end of the workflows; degradation increased with longer interactions and larger documents. This is not a direct test of Second-Brain tools, but it is strong evidence against treating autonomous AI editing of canonical knowledge as intrinsically trustworthy. citeturn22academia1

**Privacy and access.** Notion states that customer data is not used by Notion or its AI subprocessors for model training by default; its documented LLM-provider retention is zero for Enterprise workspaces by default and up to 30 days or fewer for non-Enterprise workspaces by default, subject to specific feature settings. AI Meeting Notes also uses multiple subprocessors and has explicit consent and transcript/audio-retention behavior. Those are product-specific policies, but they demonstrate the kinds of questions every team should ask before feeding sensitive work into an AI assistant. citeturn21view6turn21view2

The useful safety boundary is:

> **AI may compress evidence and propose state. Humans confirm canonical state.**

Decisions, ownership, due dates, completion, deletion, supersession and external claims should therefore have a visible human-confirmation step.

### Notion, Obsidian and other approaches

There is no universal winner because the maintenance burden moves depending on what the work needs.

| Dimension | Notion | Obsidian | Split-stack approach |
|---|---|---|---|
| **Free-form writing** | Strong. | Very strong; plain Markdown is the native substrate. citeturn2search0 | Depends on document tool. |
| **Structured data** | Excellent: databases, typed properties, relations, views, layouts. citeturn1search0turn14search16 | Increasingly strong through Properties + Bases while remaining file-centric. citeturn3view0turn4search3 | Use structure only in the operational application that needs it. |
| **Collaboration** | Native workspace/page permissions and collaborative databases. citeturn14search20 | Shared vaults through Sync, but currently no fine-grained permissions and no live simultaneous same-file editing; shared vaults support up to 20 collaborators. citeturn17view0 | Strong when each tool matches its collaboration job, at cost of fragmentation. |
| **Local ownership** | Cloud-first; export is available, but exported workspaces do not preserve the complete application structure for instant recreation. citeturn17view4 | Core strength: locally stored non-proprietary Markdown; usable offline. citeturn17view1 | Can be excellent or poor depending on chosen tools. |
| **Offline** | As of the snapshot, desktop/mobile support pages selected for offline use; recent/favorite pages can auto-download depending on plan. citeturn18search9 | Local files make offline operation fundamental. citeturn17view1 | Varies. |
| **Links/backlinks** | Good links plus explicit database relations. | Core strength; backlinks and links are deeply integrated. citeturn3view1 | Usually weaker across application boundaries. |
| **Task system** | Can be a full shared execution layer, including tasks, sub-items and dependencies. citeturn6view3 | Core notes/search can hold tasks; richer task-management behavior usually requires deliberate setup. citeturn3view2 | Dedicated task tool typically gives strong execution behavior. |
| **Integrated AI** | Extensive built-in AI, meeting capture and connected-app search. citeturn16search7turn6view1 | The core official feature set reviewed here emphasizes local files, search, links, properties, Bases and Sync rather than an equivalent built-in workspace-AI layer. | External AI can operate on selected material without making the knowledge tool itself AI-centric. |
| **Maintenance danger** | Schema/view/automation proliferation. | Plugin/configuration/linking proliferation. | Cross-tool duplication and fragmentation. |
| **Best fit** | Shared structured workflows where canonical state and collaboration matter. | Personal or small-scale knowledge work prioritizing local files, portability and flexible writing. | Users whose execution, calendar and knowledge needs differ enough to justify specialized tools. |

A major change in the Obsidian side of this comparison is **Bases**. It lets users filter, sort, group and display note properties in database-like views while the underlying content remains Markdown files. That weakens the old simplistic claim that “Notion has databases, Obsidian only has notes.” citeturn4search3turn4search9

Conversely, Obsidian collaboration is still materially different from Notion collaboration: its current shared-vault documentation says collaborators have effectively the same vault permissions, there is no live same-file editing, and concurrent edits are reconciled through sync/conflict handling. That is perfectly acceptable for some small teams and a serious constraint for others. citeturn17view0

Notion’s offline capability has also changed from older comparisons: current plans explicitly advertise offline desktop/mobile access with pages downloaded for offline use. It is therefore no longer accurate to reduce the choice to “Notion online, Obsidian offline,” although local Markdown ownership remains a more fundamental architectural property of Obsidian. citeturn18search9turn17view1

### Practitioner disagreements

Practitioners disagree sharply because they optimize for different costs.

| Disagreement | One camp | Opposing camp | Dossier position |
|---|---|---|---|
| **One vault/workspace vs segmentation** | Steph Ango describes a personal Obsidian approach favoring one vault, limited folder organization, dates and extensive linking. citeturn10search10 | Teams/privacy contexts benefit from structural boundaries and permissions. | One logical knowledge space is good until privacy, ownership or scale creates a real reason to split. |
| **Everything in Notion vs separate execution** | Notion can technically integrate docs, databases and tasks. citeturn6view3 | Some practitioners report productivity improving after taking task management out of Notion and using Notion as a simpler reference/database layer. citeturn10search3 | One source of truth per function matters more than one application for everything. |
| **Heavy organization vs search-first** | Filing gives predictability and operational views. | Search reduces classification effort; unified refinding has empirical support. citeturn13search1 | Search-first for reference, structure-first for state. |
| **Many links vs opportunistic links** | Dense linking supports associative navigation. | Link maintenance can itself become work. | Deliberate links for provenance/project relationships; opportunistic conceptual links. |
| **Daily notes as home base vs no daily notes** | Daily Notes provide an easy chronological capture/log surface. citeturn3view4 | They become graveyards when important state never leaves them. | Use as an interface, not as the only canonical store. |
| **Migrate everything vs start fresh** | Complete migration preserves one searchable corpus. | Selective/on-demand migration avoids inheriting clutter. | Default to searchable legacy + on-demand promotion. |
| **Automate with AI vs human-controlled AI** | Current tools can summarize, extract and edit at substantial scale. citeturn16search7 | AI can mis-transcribe, infer incorrectly and corrupt documents during long delegated workflows. citeturn21view4turn22academia1 | Automate compression/navigation; confirm canonical state. |

One recurring anti-pattern in practitioner accounts is not a specific tool but **meta-work**: redesigning the productivity system becomes intrinsically rewarding and crowds out the work it was supposed to support. Filip Chrapek describes repeatedly spending time polishing Notion systems that were soon abandoned; a recent r/Notion account similarly reports spending more time tweaking task views than doing the tasks. Those are anecdotes, not population evidence, but they match a recognizable maintenance-risk pattern worth testing explicitly. citeturn10search0turn10search3

## Failure catalogue and evaluation

### Failure-mode catalogue

Evidence strength below refers to the evidence **for the failure mechanism**, not whether every user will experience it.

| Failure | Symptom | Likely cause | Detection | Simpler alternative | Mitigation | Evidence |
|---|---|---|---|---|---|---|
| **Capture landfill** | Hundreds/thousands of unread clips and inbox items. | Capture became effectively free; no distinction between reference and obligations. | Oldest action-bearing inbox item keeps aging; clip volume far exceeds reuse. | Quick capture + only one operational queue; reference can remain searchable. | Add one-line intent to high-volume capture; auto/archive reference out of attention. | **Medium:** PIM research + practitioner pattern. citeturn11search0turn10search0 |
| **Over-engineered Notion** | More time changing schemas/templates/views than using them. | Structured objects are cheap and enjoyable to build. | Frequent schema redesign; many properties rarely populated or queried. | Page + status + next action + source. | Freeze architecture for a trial period; delete every field lacking a retrieval/use case. | **Medium/low:** strong practitioner signal, limited empirical tool-specific evidence. citeturn10search0turn10search3 |
| **Database nobody updates** | Dashboard looks polished but status is wrong. | Properties are not updated at the moment work changes. | Compare reality with database; missing owners/next actions; long-unmodified “active” projects. | Replace manual dashboard fields with fewer canonical states/live views. | Update on events, not during generic “gardening.” | **Medium:** operational inference + practitioner evidence. citeturn10search3 |
| **Daily-note graveyard** | Decisions/tasks exist only in old dated notes. | Chronological capture was mistaken for canonical storage. | Search old daily notes and find unresolved commitments absent from task/project views. | Daily note as capture/log only. | Promote stateful items immediately. | **Medium/low:** capability documented; failure mechanism is practitioner inference. citeturn3view4 |
| **Tag explosion** | Hundreds of tags; many used once; users cannot remember vocabulary. | Classification added “just in case.” | High singleton-tag rate; tags rarely drive retrieval/views. | Search + a handful of workflow facets. | Delete/merge unused tags when encountered, not via a giant cleanup. | **Medium:** consistent with reducing classification burden; exact thresholds are heuristic. citeturn3view2 |
| **Backlink gardening** | Large graph, little improvement in real retrieval. | Linking becomes an end rather than a retrieval mechanism. | Significant linking time but evaluation tasks still rely on search. | Link only relationships with expected future value. | Audit links by real retrieval questions, not link count. | **Low/interpretive:** backlinks’ capability is clear; productivity effect is not established. citeturn3view1 |
| **Everything becomes an object** | Every idea/source has a dozen properties. | Database model applied before a query/lifecycle exists. | Many empty/default fields; object creation feels slower than writing. | Default to plain note. | Promote only when state, ownership, repeated queries or relations justify it. | **Interpretation**, supported by product capability/maintenance trade-off. citeturn14search16turn3view0 |
| **Search-only operational system** | Easy to find documents, hard to answer “what is waiting?” | State exists only in prose. | Waiting/owner/next-action questions require reading multiple records. | Add minimal status/owner/project metadata. | Maintain state only for stateful objects. | **Interpretation**, supported by search-versus-structured capability distinction. citeturn3view2turn1search0 |
| **Duplicate tasks** | Same commitment appears in meeting, daily note, project and task manager with conflicting statuses. | Capture copies became independent records. | Search a sample of commitments and count authoritative copies. | One canonical task; other locations link to it. | Make promotion move responsibility, not duplicate it. | **Medium/interpretive.** |
| **Dashboard rot** | Homepage advertises an obsolete project/status. | Dashboard copies information rather than querying canonical data. | Dashboard disagrees with project/task source. | Saved live views. | Avoid manually mirrored summary state. | **Medium/interpretive;** Notion’s database views make live alternatives possible. citeturn14search24 |
| **Plugin/configuration dependency** | Workflow breaks or behaves differently across devices. | Critical behavior depends on an increasingly elaborate extension stack. | Count plugins required for essential workflow; test a clean/mobile environment. | Core-first workflow; external task tool where appropriate. | Treat plugins as optional enhancement unless their failure mode is acceptable. | **Medium/low:** architectural risk; community reports show real configuration friction. citeturn2search13 |
| **AI phantom certainty** | Generated summary or action becomes “truth” without source check. | Fluent output hides transcript/inference error. | Sample AI-generated decisions/actions against transcript/source. | AI drafts, human confirmation. | Require citations and explicit approval for canonical state. | **High for error possibility:** product docs + 2026 delegated-document study. citeturn21view4turn22academia1 |
| **AI staleness** | Assistant says something outdated although newer information exists. | Connector/indexing delay or conflicting old information. | Compare AI answer against recently changed canonical item. | Direct operational view for live state. | Use AI for synthesis, databases/tasks for current truth. | **High for Notion connector delay.** citeturn6view1 |
| **Migration swamp** | Months spent cleaning years of notes before new system becomes useful. | Treating historical corpus as if every item were active. | Migration work exceeds actual use; active views fill with stale material. | New active system + legacy archive. | Migrate active/on-demand. | **Medium:** practitioner experience + export/import realities. citeturn10search18turn17view4 |
| **Aggressive cleanup** | Useful history disappears in pursuit of tidiness. | Visual clutter treated as equivalent to retrieval cost. | Users cannot recover prior context; deletion decisions consume significant time. | Archive/demote. | Destructive deletion only for security, legal, duplication or clear noise reasons. | **Medium:** recent empirical preprint, needs replication. citeturn20view2 |
| **Permanent redesign** | Taxonomy, templates and tools change every few weeks. | Novelty provides immediate reward; retrieval quality is never measured. | Count structural migrations/schema changes per quarter. | Freeze design and test it against actual retrieval tasks. | Changes require a failed user scenario, not aesthetic dissatisfaction. | **Medium/low:** practitioner evidence. citeturn10search0 |

The most dangerous failure is not disorganization. It is **false confidence**: an elegant system that gives outdated or duplicated answers while looking authoritative.

### Operational evaluation

Do not evaluate a Second Brain by screenshot quality, note count, number of backlinks, database complexity or size of the graph.

Evaluate it with work.

The following ten-task benchmark can be run quarterly or after a major redesign. The suggested time bands are **practitioner starting thresholds, not empirically established standards**; more important than the absolute number is whether performance improves without growing maintenance effort.

| Test | Successful outcome | Measure |
|---|---|---|
| **Retrieve a decision from roughly three months ago** | Correct authoritative decision found. | Success; time; confidence. |
| **Explain why it was made** | Rationale and assumptions recoverable without reconstructing entire discussion. | Time; missing context; confidence. |
| **Find the original source** | Meeting/source evidence reached directly. | Time; provenance errors. |
| **Resume a project paused for weeks** | User can identify current state and first useful action within a few minutes. | Time-to-action; rereading required. |
| **Identify what is waiting on someone else** | Complete current waiting list with owner/person and follow-up context. | Missed/false items; time. |
| **Prepare for a client meeting** | Recent interaction, active work, open commitments and decisions surfaced. | Preparation time; missing critical context. |
| **Find prior research relevant to new work** | Useful prior sources/synthesis recovered without redoing research. | Time; relevance; provenance. |
| **Identify an outdated note** | User can distinguish historical truth from current truth. | Error rate; confidence calibration. |
| **Hand a project to somebody else** | Recipient can state outcome, state, next step, decisions and open questions without oral archaeology. | Questions needed after handoff; preparation time. |
| **Find the next useful action** | Canonical actionable step can be stated quickly. | Time; ambiguity; duplicate-task count. |

Add four system-level measures:

**Retrieval success:** percentage of benchmark questions answered correctly.

**Retrieval time:** median and worst-case time, not just average.

**Confidence calibration:** whether high-confidence answers are actually correct.

**Maintenance effort:** minutes spent purely capturing, processing, organizing and repairing the system rather than doing useful work.

Also track two excellent leading indicators:

**Age of oldest unprocessed action-bearing capture.**

**Number of competing authoritative copies discovered during evaluation.**

Those reveal deterioration much earlier than “I feel overwhelmed.”

### Things that need testing in a real personal or team workflow

Several central questions cannot be settled universally by literature or product specifications. They must be tested against actual work:

| Hypothesis to test | Practical experiment |
|---|---|
| **One capture inbox is better than several.** | Alternate four weeks with a single logical queue and four weeks with current surfaces; compare missed commitments and processing time. |
| **Direct-to-project capture reduces maintenance.** | Route obvious project material directly for a month; measure subsequent processing backlog and misfiling. |
| **A dedicated task manager is better than tasks inside the knowledge tool.** | Compare duplicate-task rate, overdue/stale tasks and weekly maintenance, not feature count. |
| **The resume block is sufficient project memory.** | Pause several projects for two to four weeks, then measure time-to-first-correct-action on return. |
| **Decision records pay for themselves.** | Track how often old rationale is retrieved and how long decisions take to document. |
| **Tags add real retrieval value.** | Record every time a tag, rather than search/project/entity relation, actually found the needed item. Delete unused taxonomy after the trial. |
| **Backlinks improve work.** | Record real cases where a backlink surfaced something search/project navigation would not. |
| **Weekly review catches meaningful failures.** | Track exactly what would have been missed without it. Reduce frequency if the answer is repeatedly “nothing.” |
| **AI meeting summaries are trustworthy enough.** | Randomly sample summaries against transcripts; separately score decision, action, owner and due-date accuracy. |
| **AI-generated project briefs save time.** | Compare brief-preparation time and factual-error rate with manual preparation. |
| **Current metadata is sufficient.** | For every failed retrieval test, ask whether one missing field would have solved it; only then add the field. |
| **Legacy material belongs in the active corpus.** | Compare retrieval quality before and after enabling old archives; watch for stale/duplicate answers. |
| **Mobile/voice capture is useful rather than merely prolific.** | Measure percentage of captures later acted on or reused. |
| **Structured People/Companies objects justify upkeep.** | Count actual meeting-prep/handoff retrievals against time maintaining CRM-like metadata. |
| **Maintenance stays economically reasonable.** | Track maintenance minutes for six to eight weeks and compare with concrete retrieval/rework savings. |

The governing experiment should be brutally simple:

> **After six weeks, is the system helping people restart work, recover decisions, prepare interactions and honor commitments faster than before—and is that benefit larger than the maintenance cost?**

If not, simplify it before adding anything.

## Evidence map and source traceability

### Claim-to-source table

The evidence base is uneven. There is substantial research on personal information management, keeping/refinding and fragmentation, and excellent first-party documentation of current tool capabilities. There is much less controlled empirical research testing specific “Second Brain” configurations in Notion or Obsidian. Consequently, workflow prescriptions in this dossier are explicitly **interpretations synthesized from PIM evidence, current tool constraints, and practitioner failure reports**, rather than claims of laboratory-proven superiority.

| Claim or input used in dossier | Source | Source class | Evidence role / limitation |
|---|---|---|---|
| Related project information can become fragmented by format, and interface design affects how users group it. | Bergman, Beyth-Marom & Nachmias, CHI 2006, 20-user study. citeturn20view0 | **Empirical research** | Strongly relevant to project-centric memory; old and small sample. |
| PIM consists of keeping, organizing, maintaining, finding and using personal information in support of goals/roles. | William Jones and related PIM literature. citeturn11search0turn11search8 | **Empirical/review research** | Foundational framing; not specific to modern PKM apps. |
| Unified indexing/search across heterogeneous personal information can support refinding/reuse. | Dumais et al., *Stuff I’ve Seen*, SIGIR 2003. citeturn13search1 | **Empirical research** | Supports search-first reference retrieval, not search-only task management. |
| Aggressive deletion was negatively associated with retrieval outcomes in analyzed PIM data. | *Deletion Considered Harmful*. citeturn20view2 | **Empirical research — preprint** | Useful but recent; should not be treated as settled consensus. |
| Notion database relations connect structured records and support rollups. | Notion Help. citeturn1search0 | **Product documentation** | Current capability. |
| Notion databases combine pages with properties/views. | Notion Help. citeturn14search24 | **Product documentation** | Current capability. |
| Notion supports offline desktop/mobile use with selectable/offline-downloaded pages as of the snapshot. | Notion pricing/features. citeturn18search9 | **Product documentation** | Current as of Oct. 3, 2026; may change. |
| Notion can export workspace content as HTML/Markdown/CSV but cannot instantly recreate a workspace from the export. | Notion Help. citeturn17view4 | **Product documentation** | Relevant to portability/migration. |
| Notion AI Meeting Notes transcribes, summarizes, identifies actions and supports transcript-linked citations; transcripts can contain errors. | Notion Help. citeturn21view3turn21view4 | **Product documentation** | Current product behavior; vendor-authored. |
| Notion AI Connectors have indexing delays and are better at finding/summarizing than some large-scale aggregation tasks. | Notion Help. citeturn6view1 | **Product documentation** | Directly relevant to staleness/retrieval limits. |
| Notion AI customer data is not used for model training by default; retention varies by plan/settings. | Notion AI security documentation. citeturn21view6 | **Product documentation** | Vendor policy, snapshot-specific. |
| Obsidian keeps notes as local non-proprietary Markdown and supports offline use. | Obsidian Help. citeturn17view1 | **Product documentation** | Core architectural characteristic. |
| Obsidian Properties provide typed structured metadata. | Obsidian Help. citeturn3view0 | **Product documentation** | Current capability. |
| Obsidian Bases provides database-like views over files/properties while retaining Markdown storage. | Obsidian Help. citeturn4search3turn4search9 | **Product documentation** | Important 2026 capability. |
| Obsidian backlinks expose explicit links and mentions. | Obsidian Help. citeturn3view1 | **Product documentation** | Establishes capability, not productivity benefit. |
| Obsidian shared vaults lack fine-grained permissions and live simultaneous same-file editing and have a 20-collaborator limit. | Obsidian Help. citeturn17view0 | **Product documentation** | Snapshot-specific collaboration constraint. |
| Obsidian officially supports importing numerous note systems/formats including Notion and Apple Notes. | Obsidian Help. citeturn17view1 | **Product documentation** | Relevant to migration mechanics, not migration strategy. |
| A lightweight decision record can preserve context, decision, status and consequences while retaining superseded decisions. | Michael Nygard, “Documenting Architecture Decisions.” citeturn21view0turn21view1 | **Framework-author claim / experience report** | Proven influential pattern; not controlled empirical research. |
| One practitioner advocates a single Obsidian vault, minimal folder organization and liberal linking. | Steph Ango, “How I use Obsidian.” citeturn10search10 | **Practitioner experience** | Useful opposing view; author is closely associated with Obsidian. |
| A practitioner reports repeatedly overbuilding and abandoning Notion systems. | Filip Chrapek. citeturn10search0 | **Practitioner experience** | Anecdotal but highly relevant to failure investigation. |
| Some users report better execution after separating tasks from Notion while retaining Notion for reference/data. | r/Notion discussion. citeturn10search3 | **Community discussion** | Anecdotal; demonstrates plausible failure, not prevalence. |
| Selective migration can be dramatically cheaper than redesigning an entire archive. | Eugene Yan migration account. citeturn10search18 | **Practitioner experience** | One-person experience. |
| Long autonomous LLM document-editing workflows can silently corrupt content. | Laban, Schnabel & Neville, *LLMs Corrupt Your Documents When You Delegate*, 2026 preprint. citeturn22academia1 | **Empirical research — preprint** | Strong cautionary evidence; not specifically a Second-Brain test. |
| Structure reference lightly but state heavily; use three layers of evidence, working memory and execution. | Synthesis in this dossier. | **Interpretation** | Practitioner design recommendation derived from the evidence above. |
| Use a one-screen project resume card. | Synthesis in this dossier. | **Interpretation** | Needs validation in individual/team workflows. |
| Maintain information on meaningful work events rather than performing indiscriminate gardening. | Synthesis in this dossier. | **Interpretation** | Designed to minimize maintenance; cadence must be tested. |
| Human confirmation should gate decisions, assignments, due dates, supersession and deletion proposed by AI. | Synthesis based on documented transcription/model errors. citeturn21view4turn22academia1 | **Interpretation** | Conservative operational policy, especially appropriate for consequential state changes. |

### Final practitioner model

The research points toward a Second Brain that is substantially less elaborate than much PKM culture implies.

**Do not build a perfect representation of everything you know. Build enough memory to continue work without reconstructing it.**

Capture should make forgetting unlikely, but not make hoarding effortless.

Reference information should usually remain cheap: searchable text, provenance where needed, occasional links.

Operational information should be explicit: project state, commitments, owners, decisions and next actions.

Meetings should create evidence; consequential information should be promoted out of them.

Tasks should have one authoritative home.

Projects should have a compact resume surface.

Decisions should retain their rationale and their supersession history.

Links should represent useful relationships, not decorate a graph.

Metadata should survive a single question: **“What future query or action does this property enable?”**

Maintenance should happen when work changes and through a bounded review of active obligations—not because the entire archive supposedly needs gardening.

Old information should usually be archived rather than repeatedly curated.

Migration should preferentially move active truth, not historical clutter.

AI should reduce reading and navigation cost while humans retain authority over canonical operational state.

And the system itself should be judged by ten mundane but decisive questions: **Can you find what was decided, understand why, recover the source, restart paused work, see what you are waiting for, prepare for a meeting, reuse past research, detect stale information, hand work to another person, and know what to do next?**

If it can do those things reliably while remaining boring to maintain, it is working. If it cannot, another database, tag, plugin, dashboard or AI agent is unlikely to rescue it.