Managing 900+ Obsidian Notes with a Knowledge Graph

Too Many Notes, Search Isn't Enough

A consultant accumulated over 900 Markdown files in Obsidian—meeting notes, client conversations, research reports—all stored in a self-built structure. The problem wasn't finding files; it was that the folder structure couldn't answer the questions that really mattered: who owns the data contract for a given client?

According to the author, searching for "Northwind" returns every note mentioning that client, but it can't tell you who owns the contract. The answer was actually buried in a sentence in a quarterly review note—referring to Dana Whitfield. He wanted the ability to ask questions in his own words, get direct answers, and have them backed by source notes.

Four-Layer Architecture: From Notes to Queryable Knowledge

The author's approach breaks down into four layers: a fixed folder structure, Markdown notes with OKF metadata, a Graphiti knowledge graph built on a custom ontology, and a daily-running Cowork task plus an MCP server.

The key insight is that he considers "building" to be the easiest part. What's truly hard is maintaining the data over time, and this constraint shaped every design choice that followed.

Structural Consistency Is the Foundation

The entire system relies on a simple principle: the folder structure must be fixed and consistent. The author's vault is organized by client folders, each with a subdirectory for people, plus a top-level People folder. He used a fictional client to show the rough shape:

Obsidian Vault/
  Clients/
    northwind/
      Northwind.md
      2026-09-14 quarterly review.md
      people/
        Dana Whitfield/
          Dana Whitfield.md
  People/
  Blog Posts/
  Strategy/

He emphasizes that the structure should match your own way of speaking, because you'll be querying it using your own terms and aliases—someone else's structure may not suit you. But whatever structure you choose, you must follow it consistently—everything downstream depends on this.

OKF Adds Metadata to Every Note

Markdown is the foundation: LLMs are familiar with it, any text tool can read it, and notes aren't locked into a single application. But plain Markdown lacks state information—nothing has validated it, and there isn't enough metadata to build a graph.

The author chose Google Cloud's Open Knowledge Format (OKF). What appealed to him was its lightness: it only requires a frontmatter block at the top of the note—a set of key-value pairs; and it's extensible, so new keys can be added over time. An example:

---
type: Meeting Notes
title: "Northwind quarterly review"
description: "Migration scope, timeline pressure, and who owns the data contract."
tags: [meeting, northwind, migration]
generated: { by: claude/haiku-4-5, at: 2026-09-14T11:10:37Z }
---

OKF's design goals align with this need: the context agents need should exist in open formats, not in proprietary services or unstructured text. It's deliberately minimal—type is the only required field, everything else is optional, and custom keys are preserved. This means you can invent keys like expires_after to mark when a note expires, and both LLMs and deterministic scripts can read and act on it.

Metadata also changes the cost of an agent reading a note. Scripts can fetch a single property without touching the body; most of the time an agent only needs to judge relevance, and the title, description, and tags are enough. The author's approach is to instruct the agent in the system's persistent instructions to check the frontmatter first and only open the body of notes that look relevant, while rebuilding an index for each top-level folder with one line per note.

The relationship between OKF and frontmatter: frontmatter is the YAML block wrapped in --- at the top of a Markdown file, widely used in static site generators (like Hugo, Jekyll) and note-taking tools to declare metadata such as title, date, and tags. OKF is not a new file format—it defines a minimal, extensible key-value specification on top of the frontmatter convention, with the goal of letting agents and automation scripts understand document state in a unified way. It's in line with metadata standards like schema.org and OpenGraph, but lighter, and deliberately avoids over-specifying field semantics to avoid binding to a particular toolchain. Understanding this helps grasp why the author chose OKF over a custom metadata format: an open format means notes remain portable long-term and won't break if an application shuts down.

Metadata Is Maintained by Scripts

Metadata is only useful if every note has it, so the author uses scripts for regular sweeps: wait for the vault to go quiet, check each note, fill in missing metadata, fix mechanically fixable issues, link known names, rebuild indexes, scan for secrets, and commit. The only step that needs a model is classification—reading new notes and writing out type, title, description, and tags; everything else is plain code.

He gave the classifier an approved type list of about 30 values, but the classifier only selects 8 of them. The reason is practical: give a model an open list and it will invent a plausible new type for any note that doesn't match, and no query knows that type exists. Non-matching notes are flagged for human review.

The Ontology Makes Relationships Queryable

Notes are fundamentally about relationships—between notes, and between the things they describe. Obsidian's wikilinks are themselves a kind of knowledge graph. In the graph view the author shared, small dots at the edges represent knowledge not yet connected to the main body; larger dots mean more links, revealing who is truly at the center of his work.

But a graph view can't query relationships. The value of consulting work lies precisely in relationships: companies, clients, people, organizations, agreements, standards. So the author introduced an ontology to describe what types of things exist and how they relate.

The process of turning a note into a fact works like this: extract two entities and the relationship between them from a quarterly review note:

Dana Whitfield (Person)  --ACCOUNTABLE_FOR-->  Northwind data contract (Contract)
  fact:   "Dana Whitfield owns the Northwind data contract and signs off changes to it."
  source: Clients/northwind/2026-09-14 quarterly review.md

Relationships carry a natural-language fact and the source note path, so every answer the graph provides can be traced back to its source. This also reflects the consistency emphasized earlier: entity identity is determined by type and name, with no fuzzy matching. If two notes both say Northwind, they merge into one node without a model call; if one says Northwind Trading, it creates a second node until someone manually maps it.

Why Graphiti

The author chose Graphiti as the graph framework because it lets you define entity and edge types in Python, and comes with schemas, typed edges, and hybrid search. The bigger reason is speed—building graphs and underlying database technology is time-consuming, and Graphiti let him iterate quickly and focus his energy on the ontology, data structure, and taxonomy. Under the hood it runs FalkorDB in a single container, with embeddings from the local model nomic-embed-text, and the only two places in the graph pipeline that call external models are Claude Haiku 4.5, chosen because it's cheap enough to run over all changed notes every day.

Knowledge graphs and ontologies: A knowledge graph organizes information as "entity-relationship-entity" triples, where entities are nodes and relationships are directed edges. An ontology is a "meta-description" of the graph—it specifies which entity types are allowed (like Person, Contract), which relationship types are allowed (like ACCOUNTABLE_FOR), and the constraints between types. Without an ontology, a graph can only store arbitrary triples, and queries can't distinguish semantically similar but distinct edges like "reports to" and "is responsible for"; with an ontology, the system can do precise retrieval and validation by type. The author emphasizes that entity identity is strictly determined by type and name—precisely the consistency constraint an ontology provides, in contrast to fuzzy-matching entity disambiguation strategies—which also explains why Northwind and Northwind Trading are treated as two nodes.

FalkorDB and local embedding models: FalkorDB is a graph database based on sparse matrices, delivered as a Redis module, deployable as a single container, supporting Cypher queries, and suited to running lightweight graph workloads on a personal laptop. Compared to Neo4j, which requires a separate cluster, it lowers the operational barrier. nomic-embed-text is an open-source text embedding model released by Nomic that runs locally, turning note text into vectors for semantic search. The author does embeddings locally, meaning raw note content stays on the machine during retrieval, and only model steps like relation extraction and classification call cloud-based Claude Haiku 4.5. Understanding the division of labor between these two components makes clear what the author's data boundary design actually means: vectorization and storage stay local, while semantic understanding is outsourced to the cloud.

Daily Automated Graph Maintenance

Data changes constantly, so a daily process is needed: import new notes, discover relationships that don't yet have names in the ontology. The author uses a Claude Cowork scheduled task for this, running daily at 17:00, sending only what changed since the last run to the model—a quiet day produces no model calls at all.

Naming relationships matters. If "Dana reports to the Northwind data owner" and "escalate to another person when the contract has issues" are given the same relationship name, the LLM can't tell them apart and might name the wrong person. So new relationship names need to "earn their place": the same name must appear in three different notes before it's automatically promoted into the ontology.

The same task also handles cleanup. Back to the expires_after key: the scheduled task reads the date and handles expired notes differently—retiring their facts from the graph, or flagging them for review. The author sees this idea as extending far beyond ontology: any document that tells a model "the current situation" will become outdated, and the document itself won't tell the model it's outdated—precisely the problem metadata is meant to solve.

An MCP Server Brings the Graph into Daily Work

The final piece is a small Python MCP server communicating over stdio, requiring no API key, with search going through local embeddings and queries hitting FalkorDB directly. It gives Claude seven read-only tools, of which entity_profile returns a summary of a named entity, and find_relations helps Claude figure out which relationship matches a question when it doesn't know the relationship name.

The server also carries instructions that Claude reads when connecting. The author's instructions require: when a question touches his own notes, check the graph before searching Slack or the web; when Slack and the graph conflict, name both sources. This matters—the graph only knows what the notes record, and if Claude fills a gap from the web without saying so, the answer reads as if it came from the notes, and the author will repeat it with the same confidence.

The practical result: ask "Who owns the Northwind data contract?" and Claude returns Dana Whitfield, based on the September 14 quarterly review, with a link to the note.

Data Boundaries Need to Be Thought Through in Advance

The author candidly notes: the graph, database, and embeddings are all on his local laptop, but every model step in the graph pipeline sends note text to Claude Haiku 4.5, the scheduled task itself runs in Cowork, and answers go to the Claude app posing the question. Much of his work is in regulated environments, so he reminds readers to confirm these data flows are acceptable before connecting their notes. The server only runs on the laptop; web or mobile sessions can only use it indirectly through the desktop app.

Next Step: Local Models Take Over

The author has already tested a local 14B 4-bit quantized version of Qwen 3 on Apple's MLX framework, aiming to see whether local models can take over the model steps. Currently every model step sends note text to the cloud; local models would keep the text on the laptop, which is significant for people whose notes come from regulated work.

What's worth borrowing from this whole approach isn't any particular tool, but its layered thinking: structural consistency provides predictability, lightweight metadata provides machine-readable state, the ontology provides semantics, scheduled tasks provide continuity, and MCP provides everyday usability. Each layer alone isn't novel; together they turn 900 notes from "searchable" into "askable."

One-line Summary

Using a fixed structure, OKF metadata, a knowledge graph, and MCP to turn 900 notes into an askable knowledge base

Paragraph Summary

The article describes how a consultant upgraded over 900 Obsidian notes from "searchable" to "askable." The approach has four layers: a fixed and consistent folder structure provides predictability; OKF frontmatter attaches machine-readable metadata to every note, filled in by regular script sweeps; a Graphiti knowledge graph built on a custom ontology extracts relationships from notes into typed, sourced fact edges; and a small MCP server exposes the graph to Claude's daily conversations through seven read-only tools. A daily Cowork scheduled task processes only what changed, new relationships must appear in three notes before being promoted into the ontology, and expired facts are cleaned up based on expires_after. The author also notes that model steps send note text to the cloud, so regulated environments should confirm data flows first, and he is testing local Qwen 3 as a replacement for cloud models.