Projects

Research Wikis

Over the course of a research career, it is easy to accumulate thousands of published papers organized loosely into folders by topic, methodology, or source — a system that works for storage but fails for retrieval. What if you could query that collection to get precise answers to specific questions, trace connections across literatures, or identify gaps that point toward future research? That is the problem these wikis are designed to solve. The researcher acts as curator: deciding which papers to ingest and which conceptual threads to develop relative to the existing knowledge structure. Everything is written and maintained by the LLM, but the researcher retains full authority — correcting errors, steering the wiki toward their own research interests, and shaping the schema that governs how knowledge is organized.

The two wikis below are personal knowledge bases built using the LLM Wiki pattern — a design introduced by Andrej Karpathy in which a large language model (LLM) agent maintains a persistent, interlinked set of markdown files as the primary layer of a knowledge base. Rather than retrieving from raw documents at query time, as in Retrieval-Augmented Generation (RAG), the LLM pre-compiles source material into structured, cross-referenced concept pages. Knowledge accumulates and compounds across sessions instead of being re-derived from scratch each time.

The contrast with RAG is architectural. RAG indexes raw text chunks into a vector database and retrieves the most semantically similar passages at query time — fast to set up and effective for lookup tasks, but stateless. Each query starts from zero: no understanding carries over between sessions, and the expensive work of cross-document synthesis is repeated on every question. The LLM Wiki inverts this: ingestion is the expensive step, and it is done once per source. Each new paper is not just summarized — it is cross-linked into the existing structure, updating related concept and entity pages with new connections. A paper on manufacturing decline, for example, propagates into existing pages on mortality, marriage markets, intergenerational mobility, and labor supply — not just into its own summary page. This is where compounding happens.

Karpathy's framing captures the roles concisely: "Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase." The user curates inputs and reviews outputs. All structural maintenance — cross-referencing, tagging, backlink management, logging — is delegated to the LLM, governed by a schema file (CLAUDE.md) that defines page formats, naming conventions, and ingestion and query protocols. The architecture is locally owned and fully human-readable: every page can be opened, verified, and corrected, with no proprietary lock-in or black-box retrieval pipeline.

Below are two wikis I plan to continually develop.

Software & Code

These are applications of a range of Bayesian statistical and econometric models, with code in both Python and R. The focus is on traditional MCMC methods — Gibbs and Metropolis–Hastings samplers built from scratch — alongside gradient-based Hamiltonian Monte Carlo via NUTS (PyMC / Stan). Many examples replicate the results of seminal papers, and a recurring theme is the contrast between from-scratch implementations — which expose the estimation machinery — and the off-the-shelf packages that reproduce the same posteriors, typically cross-checked across two or three engines.