How I Plan to Make Obsidian Truly Alive: Inbox Auto-Processing + GBrain Knowledge Flywheel

Recently, I completed a major restructuring of my Obsidian knowledge base.

I took the previously jumbled mix of X articles, ideas, learning materials, Git tutorials, and content drafts, and reorganized them into a clear pipeline:

Inbox → Sources → Notes → Maps → Projects / Output → Archive

After cleaning up the directory structure, the next question naturally arose:

Do I have to manually judge, move, fill in YAML, split notes, and update MOCs every time I save an article from now on?

If every step relies on manual effort, the knowledge base may be tidy, but it remains static.

What I truly want is not an “Obsidian that stores a lot of information,” but a personal knowledge system that continuously absorbs, connects, retrieves, and feeds back.

So I started designing the next phase: let Codex automatically handle the Inbox, and let GBrain become the retrieval and thinking layer above Obsidian.

A Tidy Knowledge Base ≠ A Living Knowledge Base

A static knowledge base typically has three characteristics:

• Lots of input, but most content stays in a “saved” state;
• Search relies on keywords and memory — it doesn’t know what you’ve already written;
• Notes rarely make it into projects, decisions, or public output.

Directory structure only solves part of the first problem.

It can tell me where a file should go, but it cannot automatically tell me:

• How does this new article relate to old ideas?
• Does it conflict with my existing judgments?
• What evidence is my knowledge system still missing?
• Which permanent notes are already sufficient to form an output?
• Has a conclusion become outdated due to new information?

A truly “living” knowledge base needs four loops simultaneously:

Continuous input ↓ Automatic processing and linking ↓ Being invoked in questions and projects ↓ Writing the practical results back into the knowledge base

If you only do the first three steps, the system becomes a better search engine.

Only when the last step is established does it start accumulating its own experience.

I Split Automation into Two Systems

I didn’t plan to have GBrain handle all the work directly.

A more reasonable approach is to let two systems take on different responsibilities.

Codex: Knowledge Processing Layer

Codex is responsible for understanding files and modifying Obsidian:

• Scan new content in the Inbox;
• Determine whether it’s an external source, personal idea, project material, or output draft;
• Unify YAML;
• Move high-confidence content to the correct directory;
• Extract permanent notes;
• Update MOCs and the knowledge base home page;
• Determine if content is sufficient to form an Output;
• Check Wiki links and attachments.

GBrain: Knowledge Retrieval and Synthesis Layer

GBrain is not responsible for file management on my behalf; it’s responsible for making the entire knowledge base queryable, connectable, and synthesizable:

• Index Markdown and YAML;
• Establish keyword and semantic search over content;
• Build a knowledge graph based on Wiki links;
• Answer questions across multiple notes;
• Point out outdated, contradictory, or missing evidence;
• Run nightly maintenance, integration, and pattern discovery.

Think of them as:

Codex takes care of processing knowledge. GBrain makes knowledge findable and recombinable. Obsidian continues to store the final files.

Obsidian remains the single source of truth. Even if GBrain is replaced later, all Markdown, YAML, and Wiki links still exist — they won’t be locked inside some database.

How Inbox Auto-Processing Should Run

I plan to have the automated task scan once a day:

00_Inbox/

But it won’t immediately move files upon encountering them. It will go through a judgment process first.

New file ↓ Check for duplicates, content completeness, and source ↓ Identify content type ├─ External material → 01_Sources ├─ Mature idea → 02_Notes ├─ Project material → 04_Projects ├─ Writing draft → 06_Output/Drafts └─ Cannot determine → stay in Inbox

For a complete external article, the automated task should:

• Identify the source, author, and publication date;
• Fill in unified YAML;
• Check if the same source already exists in the knowledge base;
• Analyze whether it’s worth keeping long-term;
• Extract 1–5 independently reusable insights;
• Connect those insights to existing MOCs;
• Determine if it can form a new Output with old notes;
• Validate YAML, Wiki links, and attachments;
• Output a processing report for this run.

I walked through the complete process once with addyosmani’s article “Own the Outer Loop” collected from X.

One Inbox article eventually became:

• A traceable source note;
• Five permanent notes;
• Three MOC nodes: Agent, Loop, Software Engineering;
• One Chinese output article: “Agents Can Write Code, But Engineers Must Own the Outer Loop.”

This is the minimal closed loop I want automation to repeatedly complete.

A Final Thought

The real value of an Obsidian knowledge base is not tidy folders, but the ability for content to flow. AI (Codex + GBrain) dramatically reduces processing cost, but ultimately, “what to believe, what to publish, and to take responsibility for it” is still my own decision — and that’s precisely the meaning of the Outer Loop. A personal IP is not about continuously producing content, but about continuously making your judgment process public.