Building a public wiki
Simple systems matter. Not simple as in underbuilt, or simple because the problem was easy, but simple in the sense that the pieces are visible and the system can be understood after time away. The best kind of simplicity is not a lack of ambition; it is a refusal to add machinery before the shape of the problem demands it.
That lens is useful for a private wiki. Reading can easily vanish into chats, saved links, and half-remembered notes. Work across product, founders, markets, AI, payments, defence, and operating craft often arrives as transcripts, essays, interviews, screenshots, and fragments. Each source may be valuable on its own, but the value compounds only when it can connect to ideas already understood.
The common workflow breaks at exactly that point. Save a source, ask an LLM about it, get a decent explanation, and then leave the answer inside a chat where it slowly becomes hard to find. A week later, the same question appears again, the same tax gets paid again, and another disposable answer lands beside the first one.
The project was to implement the LLM wiki pattern inside Hermes without turning Hermes into a heavy knowledge-base product. Importing someone else's whole set of skills, templates, workflows, or knowledge-base operating system would have solved the wrong problem. Those systems can be useful, but they often arrive with a lot of taste embedded inside them. The useful version here had to stay smaller and closer to the reading workflow.
The starting point was Andrej Karpathy's LLM Wiki note. The pattern is simple and already familiar to a lot of people building personal wikis: keep markdown pages between the reader and the sources, then let the model help maintain those pages over time. That original idea becomes more useful when narrowed into a smaller Hermes workflow.
There are four parts to the setup: raw sources, a private wiki, an exporter, and the public website. Raw sources are the material that should not be lost, the private wiki is the working space where Hermes helps maintain markdown pages, and the exporter is a small script that turns approved private pages into public HTML and JSON. The website is the static output that readers see.
The private wiki
The private wiki starts with folders and markdown files. Raw sources stay in one place, durable ideas live under concepts, and people, companies, books, products, and institutions live under entities. That split is not clever, but it is easy to remember, and it gives Hermes enough structure to decide where a new claim belongs.
wiki/
raw/
sources/
concepts/
software-moats.md
founder-mode.md
entities/
stripe.md
brian-chesky.mdConcepts are things like software moats, founder mode, product delight, monopoly theory, doing things that do not scale, and agent-maintained notes. Entities are the actors and artefacts around those ideas: Stripe, Airbnb, Peter Thiel, Keith Rabois, Brian Chesky, a book, a podcast episode, or a company memo. The point is modest: give the wiki stable objects that can be updated across many sources.
That distinction matters because a transcript rarely contains only one useful thing. A founder interview might mention Airbnb, product craft, hiring, trust, marketplace liquidity, and founder mode in the same conversation. If the transcript stays as one blob, it can only answer questions about that blob; if the claims land in concept and entity pages, the next source can attach to the same ideas.
The ingest loop is deliberately repetitive. Add the source, preserve the raw text, read carefully, extract durable claims, update concept pages, update entity pages, rebuild links, and record what changed. The wiki is not a dump of chat history; it is a curated layer between raw sources and future questions. The critical step is preserving the raw text.
An agent should not summarise a source and throw the source away. That gives the summary too much authority and makes it hard to check where a claim came from later. The wiki page is the interpretation layer built on top, while the original material stays immutable and available for audit, down to a source hash when the body needs to be checked for changes.
The shape of a page
A folder of markdown pages is easy to start and easy to ruin. Without a schema, pages drift into essays, quote banks, unfinished notes, and whatever structure the model invents on that run. The system needed just enough shape to keep pages comparable while still leaving room for normal prose.
The answer was frontmatter and a few repeated sections. Frontmatter tells Hermes and the exporter what the page is, whether it can be public, when it changed, and how search should treat it. It also gives Hermes a stable format when it creates or edits a page.
---
title: Software Moats
type: concept
public: true
created: 2026-05-28
updated: 2026-05-29
tags: [software, strategy, startups]
sources: [raw/articles/software-moats.md]
confidence: medium
contested: false
contradictions: []
aliases: [moats, startup moats]
---The body of the page stays readable. A concept usually starts with a short definition, then explains how the idea works, where it appears in the source material, what tensions or caveats matter, and which other pages it links to. An entity page carries the actor, the chronology, the important claims, and the links back to the ideas.
Wikilinks are the connective tissue. If a page mentions [[Brian Chesky]] or [[Founder Mode]], that link has meaning inside the private wiki, and it gives the agent a structure to maintain. Over time, the wiki improves by editing existing objects rather than creating a fresh pile of summaries every time a source is added.
This is where Hermes becomes useful. A good ingest means reading carefully, spotting durable claims, deciding where they belong, updating existing pages, creating missing ones, and checking links. Human judgment still decides what belongs, what should stay private, which concepts matter, and when a page feels wrong; the agent handles the grind between those decisions.
The public layer
The private wiki has an obvious use: it supports thinking, gives Hermes more context, and lets future work inherit memory. Publishing creates a different kind of pressure because public pages need cleaner language, fewer private shortcuts, and links that make sense to someone arriving cold from a browser. That pressure is useful, but it is still just an extension of ordinary note-taking discipline.
Learning in public works only when the public layer is careful. The point is to publish shaped concepts, company notes, people notes, market ideas, and operating frameworks while keeping the messy workbench private. That meant the public site had to be an export rather than the primary workspace.
The exporter is the boundary between those worlds. It reads the private wiki, looks only at concepts and entities, checks frontmatter, skips pages marked private, strips personal sections, converts safe wikilinks into public links, and writes static HTML into the website repo. The public site is disposable output; the private markdown remains the thing to protect.
wiki/
index.html
concepts/
index.html
software-moats.html
entities/
index.html
stripe.html
search.jsonThe formats are intentionally classic. Markdown is the private editing format because it is readable in any editor and easy for Hermes to patch. HTML is the public reading format because the web already knows how to serve it. JSON is the search format because a small static index is enough for the current size of the wiki.
That choice keeps the system lean. There is no app server, no database, no hosted search service, and no build step for the reader to care about. GitHub Pages can serve the result because the result is just files: markdown going in, HTML and JSON coming out.
Search without machinery
Search was the part most likely to pull the project into unnecessary machinery. A knowledge base wants search, and the usual route is an index, a backend, a hosted service, or a framework. The right target was the smallest version that would still work on a static site.
The answer was one JSON file. The exporter writes search.json beside the wiki HTML, with each record containing the title, type, URL, summary, tags, aliases, headings, and cleaned body text. The wiki homepage fetches that file and ranks records in the browser.
fetch('search.json')
.then((response) => response.json())
.then((data) => {
index = Array.isArray(data) ? data : [];
ready = true;
render();
});The ranking is basic, but it fits the scale of the site. Exact title matches score highest, title prefixes come next, and aliases, tags, headings, summaries, and body text follow. Seventy eight pages do not need industrial search; they need fast local filtering and sensible results.
The search file also has to respect the same privacy boundary as the HTML. Search often leaks more than pages because a site can hide a paragraph in the rendered page while still exposing it in an index, feed, sitemap, or API. The exporter avoids that by deriving HTML and search from the same cleaned page object.
The boundary
The hardest part of the project is deciding what public means. Some material is obviously public, such as notes on founder mode, software moats, product craft, and company strategy. Some is obviously private, such as personal plans, job search context, raw source files, unfinished thoughts, and notes written for a private operating system.
The awkward material sits between those categories. A concept may be public while one section inside it is personal; an entity page may be fine while a source link should stay private; a useful insight may need rewriting before it belongs on the internet. The exporter can enforce rules, but it cannot decide taste, discretion, or context.
Validation gives the filter teeth. The loop is ordinary: run the exporter, read the report, check page counts, check stripped sections, check remaining Jay mentions, check broken or unpublished wikilinks, parse search.json, and serve the site locally. A public wiki needs to be read as a real page before it deserves to be linked from the homepage.
The first public version still looked too generated. It had too much scaffolding, some pages carried private-ish sections, listing pages had back links in the wrong place, search needed tightening, and the width did not match the main site. Those details sound small, but they decide whether the system feels cared for.
The styling is now deliberately quiet: one root stylesheet, restrained black-and-white surfaces, sans-serif type, and enough spacing for the pages to breathe without leaning on dividers. It should feel like a set of notes rather than a SaaS dashboard.
What survives
A second pass would keep the first version even smaller. Start with a private markdown wiki, create concepts and entities, add a raw folder for sources, and decide the frontmatter before ingesting too much material. Make public/private status explicit from the beginning, because it is much harder to bolt that judgement on later.
Then write the ingest rule. Preserve the raw source, extract durable claims, update existing pages before creating new ones, link concepts and entities with wikilinks, add dates and confidence, and record changed files. After that, write the exporter as a boundary rather than a publishing system.
The minimum useful public export is more workflow than platform: filter public pages, strip private sections, render HTML, build one search file, write a report, and serve the result as static files. Add richer search when the JSON file stops being good enough, add a better markdown parser when the narrow converter blocks useful writing, and add a database only when files become the bottleneck.
The base feels useful because it is easy to understand after time away. The private wiki can absorb raw material, Hermes can help turn it into durable pages, the exporter can publish the safe layer, and the public site can be searched and browsed without a backend. The simple version can keep carrying more weight as long as each change makes the workflow clearer rather than merely larger. You can visit the public wiki at jsosa.xyz/wiki.