Get AI summaries of any video or article — Sign up free
Tana Build-Along: Build a Note-Taking System with Me thumbnail

Tana Build-Along: Build a Note-Taking System with Me

CortexFutura Tools·
6 min read

Based on CortexFutura Tools's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Build the system around a traceable chain: Source → Highlight → Fleeting Note, so every insight ties back to a specific piece of evidence.

Briefing

A note-taking system built in Tana from a blank workspace can be assembled around a simple chain of objects—sources → highlights → notes—then made powerful with live searches, dashboards, and optional AI-assisted topic extraction. The core idea is to treat the “source” (a book, video, podcast, or other reference) as the anchor for everything that follows: extracted highlights belong to a source, topics organize those highlights, and personal “fleeting notes” capture reactions tied to what was read or watched. That structure matters because it keeps every insight traceable back to where it came from, while still supporting fast retrieval later.

The build starts by creating a daily tag for the workspace, then defining three bare-bones super tags: a Source super tag for what information is being consumed, a Highlight super tag for the extracted text from that source, and a Fleeting Note super tag for the writer’s immediate thoughts about a highlight. Each super tag is created by converting ordinary nodes into super tags, which automatically places them into a shared schema view.

For the Source super tag, the system adds fields that make it usable in practice: a status field (read/watch/listen) implemented as options, plus a topic field that links sources to subject areas. To make status visually scannable, the status options get per-option emoji icons, and the node title is built from fields so the icon appears directly in the source entries. The status field is intentionally named “Source status” rather than just “status” to avoid confusion when other statuses (like project status) appear elsewhere.

Topics are implemented as an instance field that points to a Topic super tag. A live search inside the Topic super tag then acts like a “material view,” pulling in every source whose topic matches. Concepts are layered on top of topics: a Concept super tag extends Topic, and a recursive “part of” relationship lets one concept contain another. Live searches for “contains” use semantic functions so indirect relationships still surface—for example, a concept can appear as containing another through intermediate “part of” links.

Highlights are wired so each highlight belongs to exactly one source (instance field), and highlights reuse the same topics field for consistent categorization. Additional fields like location (e.g., page number) and optional author inheritance from the source help preserve citation-grade context.

From there, the system becomes navigable. A “bookshelf” dashboard is built using live searches that filter sources by status (to read / to watch / to listen / done) and can be placed in the day node for quick access. Another day-level setup adds live searches for recently created fleeting notes and highlights, so recent work is always one click away.

Finally, the system adds an AI-enhanced topics field on highlights. An AI command extracts 1–3 topics from the highlight text and returns them in a strict format (markdown code block with double-square-bracket topic names). Tana then links those names to existing topic nodes or creates new ones, enabling one-click topic tagging without manual typing.

The session ends by showing how to package the build as a shareable template: super tags and live searches must be nested under the published workspace’s nodes, and templates must be published from a separate read-only workspace for safety. The result is a “minimum viable” but extensible knowledge system that can later grow into richer source types (book/movie/podcast), author tracking, and more advanced synthesis workflows.

Cornell Notes

The build creates a traceable note-taking workflow in Tana by anchoring everything to a Source. Extracted text becomes a Highlight tied to one Source, and personal reactions become Fleeting Notes connected to what was highlighted. Topics organize sources and highlights, while Concepts extend Topics using a recursive “part of” relationship so higher-level ideas can contain lower-level ones through semantic linking. Live searches power dashboards like a “bookshelf” filtered by Source status (read/watch/listen/done) and day-level views for recently created notes and highlights. An AI-enhanced topics field can extract 1–3 topics from highlight text and automatically link or create Topic nodes using a strict double-square-bracket format.

Why start with “Source” as the fundamental unit instead of jumping straight to notes?

The system treats the source (book/video/podcast/etc.) as the nexus that connects everything else. Highlights are extracted from a specific source and therefore inherit citation context like where the quote came from (e.g., page location). When later writing or researching, topics and concepts can be traced back to the exact sources that produced the evidence, making retrieval and verification easier than if notes were stored without a source anchor.

How does the system make Source status both searchable and visually scannable?

Source status is implemented as an options field with values like read/watch/listen. For each option, an “icon” field stores an emoji, and the node title is built from fields so the icon appears in the Source entry itself. A default status (set to “to read”/read-equivalent) prevents missing icons when the status field is empty.

What’s the difference between Topics and Concepts in this setup?

Topics represent broader subject areas, while Concepts represent more specific ideas that can be related to other concepts. Concepts extend Topics, but not every Topic is a Concept. A recursive instance field like “part of” enables hierarchical relationships, and a live search (“contains”) uses semantic function logic so indirect relationships still show up in results.

How do live searches turn the data model into dashboards?

Live searches act as dynamic queries over the graph. The “bookshelf” dashboard uses multiple live searches that filter Sources by Source status (e.g., to read / to watch / to listen / done) and can be placed under the day node for quick access. Another day-level setup adds live searches for recently created Fleeting Notes and Highlights (e.g., created in the last 3 days), so recent work is always visible.

How does AI topic extraction integrate with Tana’s linking instead of staying as plain text?

The AI-enhanced topics field prompts the model to return 1–3 topics in a markdown code block, with each topic surrounded by double square brackets. Tana interprets those bracketed names as node references: if a Topic node with that exact name exists, it links; if not, it creates the node. This avoids manual tagging and keeps topic relationships consistent.

What’s required to share the system as a template?

Super tags and related nodes (like live searches) must be nested under the node that will be published; otherwise they won’t be included correctly in the template. Templates must be published from a separate read-only workspace for security, and there’s a practical caution: when selecting nodes to “ring reference” into the published structure, already-existing items may not show expected selection behavior.

Review Questions

  1. If a highlight is linked to a source and that source has a topic, how would you retrieve all highlights related to a topic using the system’s structure?
  2. What role do per-option emoji icons play in the Source status field, and why is a default status important?
  3. How does the “part of” relationship between Concepts enable the “contains” live search to surface indirect relationships?

Key Points

  1. 1

    Build the system around a traceable chain: Source → Highlight → Fleeting Note, so every insight ties back to a specific piece of evidence.

  2. 2

    Use a Source status options field (read/watch/listen) and generate per-option emoji icons to make progress scannable at a glance.

  3. 3

    Implement Topics as an instance field and use a live search inside the Topic super tag to pull in all matching sources.

  4. 4

    Model Concepts as a layer over Topics with a recursive “part of” relationship, then use a semantic “contains” live search to surface indirect relationships.

  5. 5

    Create dashboards with live searches (e.g., a bookshelf filtered by Source status) and place them in the day node for fast navigation.

  6. 6

    Add AI-enhanced topic extraction by returning topics in a strict double-square-bracket format so Tana can link or create Topic nodes automatically.

  7. 7

    When publishing as a template, nest the relevant super tags and live searches under the published workspace’s nodes and publish from a separate read-only workspace for safety.

Highlights

The minimum viable structure is three super tags: Source, Highlight, and Fleeting Note—everything else (topics, concepts, dashboards) builds on that spine.
Source status becomes both a queryable field and a visual cue by pairing options with emoji icons and using field-based title construction.
Concept relationships work through recursion: “part of” links plus a semantic “contains” live search can reveal indirect connections.
AI topic tagging can be made graph-native by forcing the model to output double-square-bracket topic names inside a markdown code block.
Template sharing requires careful nesting under the published node and publishing from a separate read-only workspace to avoid accidental disclosure.

Topics