Building out your Knowledge Graph in Markdown

Last Updated on 2026-04-19 by James Croft

Part 3 in my AI-Augmented Second Brain series

In Part 2, Designing a Machine-Readable Knowledge Base with Obsidian, we built the foundation for your knowledge base. You’ve now got a well-organized Second Brain, but it’s still just a collection of files. What transforms a collection of notes into a connected system is the knowledge graph, that we’ll define with Markdown.

A knowledge graph is the web of relationship between notes that let you (and your AI) traverse from one idea to the next, discover connections you didn’t explicitly create, and detect gaps where knowledge work remains incomplete.

In Obsidian, you don’t need a separate graph database or community plugin, just the knowledge of the [[wikilink]].

Making knowledge graph edges with Markdown Wikilinks

When you write [[Second Brain]] inside a note, you’re doing two things. For the human reader, you’re creating a clickable link to the Second Brain Area note. For the knowledge graph, you’re creating a directed edge, a relationship that explains this note connects to that note.

This is the atomic operation of the entire system. Every [[wikilink]] is a graph edge. And because Obsidian parses these natively, every edge is immediately traversable by you clicking through notes, by Obsidian rendering the graph view, and by an AI understanding the connections.

Here’s what this looks like in practice:

---
tags:
  - Project
  - Knowledge-Management
last updated: 2026-04-01T09:54:00
---

## Objective

- Set up a working [[Building a Second Brain]] vault using CODE/PARA and [[Obsidian]]. Complete when the vault has a functioning folder structure, templates for each note type, at least 10 Area notes covering my key knowledge domains, and a journal habit established.

In this Project example, it is not connected to the Building a Second Brain and Obsidian Area notes. And because this structure exists in the text (or frontmatter), and AI can understand this syntax, it can programmatically understand which knowledge domains this Project belong to.

What you’ve created here is an outgoing link. But what about the reverse?

Automatically creating Knowledge Graph backlinks

When the Project example above links to [[Building a Second Brain]], the Area note gains a backlink, a record that something references it. We didn’t need to touch the Area note directly, but Obsidian knows this link exists between the two.

Let’s think about that at scale for a moment. I have an Area note for Building a Second Brain. Over months, I create journals that mention it, Techniques that build on it, Resources that reference it, and Projects that depend on it. No need to maintain a central index of “things related to Building a Second Brain”. The backlinks are that list, and they’re always current because they’re derived from the content of every note in your Obsidian vault.

Again, for a human, backlinks are a discovery tool in Obsidian. You can click into an Area and see everything that references it. For AI, it has the capabilities, using the [[wikilink]] syntax to traverse the graph from any note.

Dynamic Relationship Tables using Obsidian Base Queries

This ones more for you than AI. Backlinks are powerful, but raw, and Obsidian displays these as a flat list in a sidebar panel. To make relationships structured and visible, I use Obsidian’s Base query blocks embedded directly in templates. This builds on your introduction to Bases in Part 2 of this series where we briefly touched on this.

Here’s the pattern that I use in every Area template where I want to highlight its related Techniques:

```base
filters:
  and:
    - file.inFolder("Techniques")
views:
  - type: table
    name: Techniques
    filters:
      and:
        - file.hasLink(this.file)
    order:
      - file.name
      - last updated
      - tags
```

As we previously covered, that file.hasLink(this.file) is the crucial part. It ensures that what is displayed to you in Obsidian is every note from the Techniques folder that has a link pointing to this Area note.

So when I open the [[Building a Second Brain]] Area note, I would see a list that contains the linked [[Progressive Summarization]] Technique. And when I create a new Technique and link [[Building a Second Brain]] to it, that Technique instantly appears in this table without manually updating.

Temporal Date Range Queries

A tip from working with Journals in my Second Brain. Relationships can be based on any criteria you set, including time-based. My Weekly journal template uses the following base query pattern:

```base
filters:
  and:
    - file.inFolder("Journal")
views:
  - type: table
    name: Journals
    filters:
      and:
        - date >= this.date_from
        - date <= this.date_to
```

Here, this.date_from and this.date_to reference the weekly journal’s own frontmatter dates. The query gathers every journal entry who date falls within that week’s range. Open a weekly journal and you see every meeting, 1:1, and daily note from that week.

Equally, this pattern is applied across my round-up journal entries, and the result is a temporal hierarchy. Daily entries feed into weekly views, which feed into monthly views. Each level provides a natural progressive summarization point, exactly what AI can use to synthesize reflections at progressively higher levels of abstraction.

Detecting gaps in the Knowledge Graph Markdown

Here’s something I learned when I started to apply AI to my Second Brain, the graph encodes where knowledge work is missing.

Consider what the absence of a relationship can tell you:

• An Area without Techniques means distillation hasn’t happened yet. You’ve captured knowledge about a domain, but you haven’t synthesized it into anything actionable (or you didn’t capture it!). So you miss the Distill stage of CODE.
• A Technique without Outputs means expression hasn’t happened. You’ve distilled your insights, but you haven’t shared that with your network or community. The Express stage is incomplete.
• A Person note with no Journals means you’re not building a meaningful network with your colleagues and peers. Either the relationship is dormant or you’re not connecting enough.

These gaps aren’t mistakes, but rather workflow signals that you and AI can complete together. Plus, with the use of Bases, they’re visible without any special tooling, just open up a note and look at the tables.

For AI, it can systematically scan the note Markdown for missing links and flag them for further work. The Knowledge Graph structure itself becomes an input to the AI’s prioritization logic.

Bidirectional linking strategies for Knowledge Graphs

Where you place a link affects how it’s discovered, queried, and traversed. I use two specific strategies:

Links in Frontmatter for structured relationships

areas:
  - "[[GitHub Copilot]]"
  - "[[MCP]]"
techniques:
  - "[[Augmenting a Second Brain with AI Agent Skills and Knowledge Graphs]]"

Links in frontmatter build machine-readable relationships. AI can parse the areas property and know exactly which knowledge domains it belongs to, without needing to parse the note body. Plus, Base queries can filter on these properties providing the primary mechanism for typed, queryable relationships.

Use frontmatter links for: categorical relationships, attribution.

Contextual Knowledge Graph connections inline

## Key Discussion Points

- Discussed the migration timeline for [[Azure Container Apps]] with [[Joe Bloggs]] and [[Jane Doe]]
- The [[WAF]] review identified three critical gaps in our [[Azure Networking]] configuration

Links in the body are contextual connections. They capture that two concepts came together in a specific context. While they might not appear easily queryable, leveraging the [[wikilink]] syntax, AI can still discover these and understand the context around the narrative that surrounds it.

Use inline links for: people mentioned in journals, technologies discussed in context, project referenced. These create the connections that make the graph valuable for recall.

The Compound Effect

The power is in using both together. Over hundreds of notes, this dual strategy builds a graph that’s both precisely structured (frontmatter) and richly connected (inline). AI gets reliable typed relationships for navigation, and contextual links for understanding.

Leveraging the Archive

In this system, archiving is hibernation. An archived note preserves all its wikilinks and backlinks. The [[wikilink]] syntax explictly isn’t a direct link to a given file, it’s a way for Obsidian to resolve to a named note regardless of where it exists in the structure. As such, your Knowledge Graph connections survive the move from active to archived.

This matters for AI. When an AI skill is about to create a new note on a topic, its first step should be searching the Archive. If an archived note exists on the same topic, it’s almost always better to reactivate it (move it back to the active folder and update it) than to create a duplicate. The reactivated note brings its backlinks with it.

Without archive-aware graph traversal, you get fragmentation. Two notes on the same topic, one archived with rich historical context and backlinks, one new and isolated. With it, you get continuity with knowledge restored.

This is one of the most valuable patterns I’ve built into my AI skills, and we’ll explore it in detail next when we look at writing skills.

What you’ve built and what’s next for your Second Brain

By combining the vault structure with the knowledge graph patterns in this post, you now have:

• Wikilinks creating directed graph edges between every note,
• Backlinks surfacing implicit relationships you didn’t manually create,
• Base queries rendering live relationship tables that maintain themselves,
• Temporal queries creating date-based hierarchies for journals,
• Gap detection using the graph to identify incomplete knowledge workflows,
• Bidirectional linking strategies for both structured and contextual connections,
• Archive continuity preserving graph connections across the knowledge lifecycle.

This is a fully connected knowledge system, one that serves both you and AI.

Next, we’ll put this knowledge graph to work on itself. You’ll build your first AI skill, focused on traversing the graph structures to discover, connect, and synthesize knowledge from across the vault.

What this series will build

Over the following articles in this series, I’ll walk you through building this system. Together, we’ll focus on:

• Why Your Second Brain Needs an AI Companion
• Designing a Machine-Readable Knowledge Base with Obsidian
• Building out your Knowledge Graph in Markdown (you’re here!)
• Your First AI Skill for Knowledge Management
• Leveraging the AI-Augmented CODE Workflow
• Making the AI-Augmented Second Brain Your Own

By the end, you’ll have a working Obsidian vault with your own AI skills that actively participate in your knowledge lifecycle.

And I’m sharing a companion base repository, obsidian-ai-second-brain on GitHub, for you to get started with your own Obsidian vault.

Found this article useful?

Thank you for taking the time to read this article. I’m committing to sharing more of my knowledge through my blog and open-source projects! You’ll also catch me in casual conversation on Bluesky and LinkedIn too.

If you enjoy what you see, please consider subscribing to get a notification when new articles go live!

---

This article is part of my AI-Augmented Second Brain series.

Next up: Your First AI Skill for Knowledge Management.

You can find the companion template repository for an Obsidian vault at obsidian-ai-second-brain on GitHub.