#>knowledge_bases topic hub

Knowledge Bases

This hub is for tools and methods that treat notes as working memory rather than as a single final document. The useful distinction is not just "editor" versus "not editor." It is whether the system supports retrieval, cross-reference, staged drafting, and long-lived accumulation in a way that changes how you think and write.

Obsidian is one current product example because it keeps local files, links, metadata, and plugins in view. But the category is broader than one company: wiki-like systems, linked-note software, research archives, and other local-first authoring tools belong here too.

This site is itself a public knowledge surface: routes carry data-spw-* semantics, the runtime can snapshot topical payloads for handoff, and Spw plain text stays readable beside HTML. Compare private notes in your vault with how this field guide exposes inspectable contracts.

^value_model knowledge base value

Knowledge Base Value Model

Knowledge bases matter when they reduce rediscovery cost. A good one turns scattered work into durable recall, gives future collaborators a route into the material, and keeps private notes close enough to become public artifacts when the time is right.

Retrieval

Search, backlinks, tags, and stable file names help a thought survive beyond the week it was written.

Publication

Notes become useful outside the notebook when they can project into guides, service pages, books, documentation, or route maps.

Codebase curriculum

The same habit applies to software: events, page data, component rationales, and architecture notes should make a codebase easier to learn.

?utility why this matters here

What this page should help answer

Use this route when the question is practical: what makes a tool a knowledge base, which kinds of structure matter, and where the category overlaps with writing, research, and publication. The point is not generic productivity advice. It is to understand which properties actually change author workflow. Returning learners can treat this as the junction point between note-taking, Markdown, and publication surfaces.

Move in when

you want to compare note systems by the work they make easier to return to.

Keep in view

local files, links, tags, metadata, search, and the shape of the later export.

Can become

an essay workflow, a book outline, documentation, or a worldbuilding surface with better recall.

~refs starting references

Starting references

Obsidian Help

A clear current reference for how one popular product describes the overlap between Markdown editing and knowledge-base behavior. Useful when you want to compare the site’s own file-and-link habits with a larger tool ecosystem.

CommonMark

Useful when the question becomes "what exactly is the Markdown substrate?" rather than "what does this app add on top?" Returning learners can use this as the substrate check before comparing tools.

Markdown

The original Markdown project page is still a helpful anchor for the older, lighter-weight file-format side of the ecosystem. It pairs well with the local file routes when you want to separate syntax from product behavior.

Text editing

Use the adjacent text-editing route when you need the broader editor lineage rather than only the knowledge-base category. Returning learners can move between the two routes without losing the distinction between editing and knowledge-base behavior.