I now have comprehensive material across all fronts: the Karpathy LLM Wiki pattern (raw/wiki split, page types, index.md, log.md, wiki-lint freshness), PARA/Zettelkasten/Johnny Decimal taxonomies, Diátaxis, MOC pattern, Dataview staleness dashboards, frontmatter conventions, and the tooling comparison (including the key 2025 fact that MkDocs Material entered maintenance mode). I have enough to synthesize a concrete, tailored recommendation. Compiling the final report.

LLM-Reference Wiki: Structure & Maintenance Best Practices

Research synthesis with a concrete recommended structure for a fast-moving, markdown-based LLM reference wiki (Obsidian-native, optionally publishable).

1. The one pattern that fits this exact use case: Karpathy's "LLM Wiki"

The most directly relevant prior art is Andrej Karpathy's LLM Wiki pattern, since it was designed for precisely this — a markdown "second brain" that an agent (and a human) maintains. Its core insight is a hard split between immutable source material and derived knowledge:

/raw — immutable source material (web clips, transcripts, papers, API docs). Nothing is edited after it lands. This is your provenance/citation layer.
/wiki — the curated, human/AI-written pages. Four canonical page types: concept pages, entity pages (a specific model, tool, company, person), synthesis pages (something you concluded across sources), and comparison pages (X vs Y).
index.md — the catalog/MOC. Every wiki page gets an entry.
log.md — a timestamped audit trail of every ingestion and update (the freshness backbone).
agents.md — the operational spec if an agent maintains the wiki.

The community framework built on this (Ar9av/obsidian-wiki) adds the maintenance machinery that matters most for a fast-moving reference: a wiki-lint step that flags stale content, contradictions, and missing frontmatter, a .manifest.json delta-tracker (only re-process sources that changed), controlled-vocabulary tags in _meta/taxonomy.md, and a provenance frontmatter field marking each claim as extracted / inferred / ambiguous. Adopt the raw/wiki split and the provenance idea even if you never run an agent — for an LLM reference where facts expire, "where did this claim come from and when" is the whole ballgame.

2. Taxonomy: fold Diátaxis into the wiki, don't reinvent it

Three taxonomy systems dominate; pick per axis rather than adopting one wholesale:

PARA (Projects / Areas / Resources / Archive) — good for work, wrong primary axis for a reference wiki. A reference has almost no "Projects."
Johnny Decimal / Zettelkasten numeric prefixes — systematic but heavy; the numeric IDs fight against descriptive, linkable titles.
Diátaxis (Tutorials / How-to / Reference / Explanation) — the right mental model for the content of a technical wiki. Split "what you know" (reference, explanation) from "what you do" (how-to, tutorials).

For an LLM reference, organize the top level by domain, and let Diátaxis be the note type (a frontmatter field), not the folder. This keeps the tree shallow (the universal advice is 3–4 levels max) while preserving the Diátaxis discipline.

3. Folders vs. links vs. tags — the settled guidance

Folders answer "where does this live?" — coarse domain buckets only. Keep them broad and shallow. Every source consulted warns against deep nesting because "links replace folders" in a wiki.
wikilinks answer "how does this connect?" — this is the primary structure. A note reachable from many places is the point; folders can only file it once, links and MOCs cannot.
Tags answer "what is this about / what state is it in?" — cross-cutting properties (#model, #prompting, #needs-review) that span folders. Keep them a controlled vocabulary in one _meta/taxonomy.md file, or they rot.
MOCs answer "where do I start on topic X?" — a hand-curated index note per major topic, plus one Home/Index MOC that is a "MOC of MOCs." MOCs beat folders because one note can appear in many MOCs.

4. Keeping a fast-moving reference from going stale — the maintenance layer

This is the make-or-break part for an LLM reference (model names, prices, API params, and best practices change monthly). Combine four mechanisms:

Dated frontmatter on every page — created, updated, and critically last_verified: YYYY-MM-DD. updated tracks edits; last_verified tracks the last time a human confirmed the facts still hold. These are different and both matter.
A status field — verified / stale / draft / deprecated. Deprecated pages stay (for link integrity) but are visibly marked.
A review_by cadence — set an explicit review interval by volatility. Suggested tiers: fast-moving facts (prices, model IDs, limits) → 30 days; conventions/patterns → 90 days; stable concepts → 180–365 days. Store as review_every: 30d or compute a review_by date.
A staleness dashboard — a Dataview query surfaces what's overdue. This turns "stay current" from a vibe into a worklist. Example:

markdown ```dataview TABLE last_verified, status, review_every FROM "wiki" WHERE last_verified < date(today) - dur(review_every) SORT last_verified ASC ```

Put this in a _review.md dashboard note. (Consistency of field types matters — if last_verified is a date on some notes and a string on others, sorting/filtering silently breaks.)

Additionally: keep the log.md audit trail (append-only, timestamped) and, if an agent maintains the vault, a wiki-lint-style pass that flags missing frontmatter, contradictions between pages, and claims that drifted from their cited source.

5. File naming conventions

Title-case, human-readable, descriptive filenames that match the concept: Anthropic Messages API.md, Prompt Caching.md, RAG vs Long Context.md. The filename is the wikilink target, so make it the thing you'd naturally type inside ….
One core idea per note (evergreen-note principle) — notes should improve over time, not accumulate junk. If a note needs "vs" in the title it's probably a comparison page, which is fine as a deliberate type.
Don't encode volatile facts in the filename (no GPT-Prices-Jan2026.md) — dates and versions belong in frontmatter/body so links don't break when you rename.
Reserved prefixes for infrastructure notes: _ prefix for meta/system notes (_index.md, _review.md, _meta/taxonomy.md) so they sort to the top and are easy to exclude from queries.
Rely on Obsidian's automatic link-updating (Settings → Files & Links → "Automatically update internal links") so renames don't break …. This is what makes descriptive-title naming safe.
Raw captures can be dated since they're immutable: raw/2026-07-23-anthropic-pricing-page.md.

6. Frontmatter template (the load-bearing convention)

---
title: Prompt Caching
type: reference          # reference | explanation | how-to | tutorial | concept | entity | synthesis | comparison
tags: [anthropic, prompting, cost-optimization]
status: verified         # verified | stale | draft | deprecated
created: 2026-01-10
updated: 2026-07-23
last_verified: 2026-07-23
review_every: 30d        # volatility tier
provenance: extracted    # extracted | inferred | ambiguous
sources:
  - "<span class="broken" title="아직 없는 노트">raw/2026-07-23-anthropic-pricing-page</span>"
---

7. Tooling: plain markdown → Obsidian → (later) static site

Author in Obsidian on plain markdown files. It's local-first, you own the files, wikilinks and backlinks are native, and Dataview gives you the staleness dashboards for free. This is the consensus base for a personal/team PKM wiki and it's what the Karpathy pattern assumes.
Keep the vault publish-agnostic. Plain .md + YAML frontmatter is portable to any SSG, so you're not locked in.
When you publish, the current-as-of-2025 landscape:
MkDocs Material — simplest setup, excellent search, great for a reference site. Caveat (Nov 2025): it entered maintenance mode — bug/security fixes continue but no new features. Still a fine, stable choice; just know it's frozen.
Docusaurus — React-based, best when you need versioning and i18n and heavy customization; more setup overhead.
Obsidian Publish — zero-friction, preserves wikilinks/graph natively, paid, least portable.
For a wiki that must "stay current," MkDocs Material or Docusaurus both support building from the same markdown; the freshness lives in your frontmatter + Dataview workflow regardless of publisher.
Don't over-tool early. The senior-engineer test: plain markdown + Obsidian + one Dataview review dashboard solves the actual problem. Add an SSG only when you actually need to publish to people who won't open the vault.

RECOMMENDED FOLDER STRUCTURE

llm-wiki/
├── _index.md                      # Home MOC — the "MOC of MOCs", entry point
├── _review.md                     # Dataview staleness dashboard (overdue pages)
├── log.md                         # append-only, timestamped audit trail
├── agents.md                      # (optional) operational spec if an agent maintains the vault
│
├── _meta/
│   ├── taxonomy.md                # controlled tag vocabulary + page-type definitions
│   ├── templates/                 # frontmatter templates per note type
│   └── conventions.md             # naming + linking rules (this doc, distilled)
│
├── raw/                           # IMMUTABLE source material — never edited after landing
│   ├── 2026-07-23-anthropic-pricing.md
│   ├── 2026-07-20-openai-responses-api.md
│   └── transcripts/
│
├── wiki/                          # curated, evergreen pages (the actual reference)
│   ├── models/                    # entity pages: one model / model family each
│   │   ├── Claude Opus.md
│   │   └── _models-moc.md         # topic MOC for this folder
│   ├── apis/                      # entity/reference pages per API surface
│   │   ├── Anthropic Messages API.md
│   │   └── _apis-moc.md
│   ├── techniques/                # concept + how-to pages
│   │   ├── Prompt Caching.md
│   │   ├── RAG.md
│   │   └── _techniques-moc.md
│   ├── comparisons/               # comparison pages (X vs Y)
│   │   └── RAG vs Long Context.md
│   ├── concepts/                  # explanation pages (the "why")
│   │   └── Context Windows.md
│   └── playbooks/                 # how-to / tutorial pages (the "do")
│       └── Set Up Tool Use.md
│
└── attachments/                   # images, diagrams (binary assets)

Why this shape: two load-bearing folders (raw/ immutable, wiki/ curated) as in the Karpathy pattern; domain sub-folders inside wiki/ kept to a single level (3–4 total depth max); Diátaxis lives in the type: frontmatter field, not the tree; every domain folder carries a _*-moc.md topic map, all reachable from _index.md; _review.md + dated frontmatter is the anti-staleness engine; _-prefixed infra notes sort to the top and are trivially excluded from Dataview queries.

Key conventions, one screen

Concern	Rule
Folders	Broad domain buckets, ≤3–4 levels, "where does this live" only
Links	`<span class="broken" title="아직 없는 노트">Descriptive Title</span>` is primary structure; enable auto-update on rename
Tags	Controlled vocabulary in `_meta/taxonomy.md`; describe aboutness + state
MOCs	One `_*-moc.md` per domain; `_index.md` links them all
Filenames	Human title-case, one idea per note, no dates/versions in name
Note type	Diátaxis + Karpathy types in `type:` frontmatter, not folders
Freshness	`last_verified` + `status` + `review_every` frontmatter, surfaced by `_review.md` Dataview
Provenance	`sources:` → `<code>[[raw/...]]</code>`; `provenance: extracted/inferred/ambiguous`
Immutability	`raw/` is append-only; all edits happen in `wiki/`
Tooling	Author in Obsidian on plain md; publish later via MkDocs Material (note: maintenance mode as of Nov 2025) or Docusaurus