systems diagram

How Knowledge OS works

Knowledge OS is the public interface for Patrick Suzuki’s compounding research system: a way to turn recurring AI research, industry analysis, and synthesized field notes into memory other people can browse, cite, and ask questions against.

01 · What Knowledge OS is

Knowledge OS is not a blog engine with some AI sprinkled on top. The job is to make judgment compound: private reading, market research, AI-news monitoring, and agent work should leave behind public artifacts that get easier to search, connect, and reuse over time.

The website is deliberately downstream of the working system. Obsidian remains the source of truth; Hermes jobs and local workflows write durable notes; the site publishes the subset worth exposing. That separation keeps the vault useful privately while letting the public layer become a queryable map of what Patrick is learning and building.

The “why” is simple: most research disappears into chat logs, browser tabs, and one-off documents. Knowledge OS turns that exhaust into a public memory surface — part portfolio, part research notebook, part AI-readable context layer.

Knowledge OS flow live system
Capture
  • Obsidian vault
  • AI news CRON
  • Industry analysis CRON
Compile
  • pnpm sync
  • build manifest
  • Next.js build
Deploy
  • GitHub main
  • Vercel build
  • public site
Query
  • Homepage Ask
  • GBrain if live
  • manifest fallback

02 · The pipeline

The high-level path is intentionally small: selected Obsidian folders sync into the repo, the build creates static pages plus a search manifest, GitHub records the change, and Vercel deploys the public site.

Obsidian
private source of truth
Hermes
agent workflows + CRON jobs
GBrain
semantic retrieval when configured
GitHub
versioned deploy trigger
Vercel
public Next.js surface

The current configured sources are Investment analysis, AI news, and Knowledge. Those become blog posts and concise knowledge notes; the Projects section is curated separately so it stays focused on the operating systems behind the site.

03 · Sync + auto-tagging

scripts/sync.ts walks every source in brain.config.ts, reads Markdown, backfills frontmatter, and writes the public copy under content/. The sync layer is intentionally boring: explicit source folders, generated _source markers, and cleanup only for files it knows it created.

Frontmatter backfill

  • title — inferred from the filename when missing
  • date — the published date, from frontmatter, filename prefix, or file mtime
  • updated — the last updated date when the public artifact changes; falls back to the published date
  • version — a visible version number for changed blog/project artifacts
  • publish — defaults to true; use publish: false to keep drafts out
  • type — determines whether the page lands in blog, projects, or knowledge
  • _source — ties the synced copy back to the vault source for safe cleanup

Auto-tagging

Sources can define baseTags and autoTag: true. Investment analyses always get #investing, AI news always gets #ai, and Claude can infer narrower content tags. Tag inference is cached by SHA-256 so unchanged notes do not get re-labeled on every sync.

04 · Ask: implemented homepage + API, GBrain when available

Ask is implemented on the homepage. The input calls /api/ask, retrieves relevant public notes, and asks Claude Haiku to answer using only that retrieved context. The standalone /ask route is intentionally not a public page right now; it returns a 404 so the homepage stays the single Ask surface.

The API has two retrieval paths. When GBRAIN_URL is configured, it calls GBrain semantic search first. When GBrain is missing, unreachable, or errors, it falls back to the static public/search-manifest.json token-intersection search built at deploy time. See What is GBrain? for the deeper explanation of GBrain as the local semantic-memory layer.

Ask status
Homepage Ask UI
Implemented
/api/ask
Implemented
Standalone /ask page
Not implemented by design

Practically: semantic search quality depends on the GBrain tunnel/env being live in production; the fallback keeps the feature usable even when the local semantic layer is offline.

05 · Weekly knowledge synthesis

The Knowledge section is generated by a Hermes cron job, not by manually stuffing tags into cards. Every Monday, the knowledge-synthesis workflow drafts candidate improvements across multiple models, then GPT-5.5 adjudicates the final public field notes.

The output goes back to the vault as Knowledge/<slug>.md, with prior versions archived under Knowledge/_history/. Each public note is constrained to be short, source-grounded, and useful without exposing raw private-note text.

06 · Knowledge graph

The /knowledge page has a graph mode powered by react-force-graph-2d. Published items become nodes; shared tags and content relationships become edges; clicking a node jumps to the underlying page.

The graph is capped for usability and hidden on small screens where force-directed canvases are more frustrating than helpful. Synthesis pages participate as first-class knowledge nodes alongside published essays and projects.

07 · Hermes automations

Knowledge OS is maintained by Hermes workflows around the vault and repo. The important distinction: agents write durable source notes into Obsidian first; the site consumes the synced public layer after local verification.

AI news CRON

A recurring AI-news workflow compares model-generated briefings over the same source packet, then uses agreement and disagreement as editorial signal before publishing the durable public version.

Industry analysis CRON

A recurring industry/business-analysis workflow produces deeper company and industry research, extracts reusable mental models, blogifies the useful public version, and deploys through the same GitHub/Vercel path.

Knowledge OS project loop

The site itself is also a project in the system: implementation decisions, Ask/GBrain integration status, and synthesis contracts are documented as public project content and mirrored in GStack plan artifacts when the operating model changes.