It is not entirely finished, but the site is live (and unadvertised). You can view the current state at www.toponymia.org. I’ll update this post along with the site.

History

In 2019, I took a three-month full-stack programming bootcamp. Eight hours a day of instruction and programming. The final month or so was largely devoted to a capstone project, which we would present in front of the school. This program was my capstone. It was fully functional at the end, but not too pretty and kind of clunky.

About four years later, I was back in school taking a course called “Code Review” - essentially software engineering with extra emphasis on style and convention to make clean, organized, and legible code. We had to pick some large, existing codebase and throughout the course incrementally refactor it into TypeScript. So I took my old bootcamp capstone and used that. I always thought it was a good idea for a website, and wanted to keep working on it. But all this work didn’t really change any of the functionality of the program, it just taught me Typescript (along with better programming).

I think I bought the domain name back in 2019, and I held on to it in the hopes that I’d eventually get around to finishing the site. I finally got around to it in 2026 thanks to Anthropic: they ran a special where they opened up Fable to Pro users for a few weeks. I wanted to test out Fable, and I thought refreshing Toponymia would be a great project for it. So I just used Claude Code to help make all necessary edits for a more polished and usable site.

The overall design really didn’t change much, but it looks and works much better than before. You can have a look at the README if you want, but here’s a quick technical overview:

Details

It’s built on a Django 6 + Django REST Framework backend with PostgreSQL/PostGIS for geospatial storage, and a React + TypeScript + Vite frontend rendering the map with MapLibre GL JS. There are no API keys or paid services anywhere: map tiles come from OpenStreetMap via OpenFreeMap, the Overpass API resolves clicked map features to real-world OSM elements, Wikidata IDs anchor stable identities, and Photon handles geocoding search. In production Django serves the built React app directly out of web/dist/, adding server-rendered SEO metadata, a sitemap, and robots.txt; in development the two run separately, with Vite proxying API calls to Django.

My original program used pins on the map, but now it uses the labels themselves (a huge improvement IMO). Every rendered label on the basemap is clickable, and a server-side lookup resolves that click to a stable entity, then serves the matching article. Articles aren’t tied to coordinates; they’re anchored to a Wikidata ID when one exists, falling back to an OpenStreetMap element or a name-plus-location match.

On top of that sits a pretty conventional wiki stack: accounts via django-allauth, full revision history with diffs and revert, threaded talk pages, and moderation for admins (report queues, soft-delete, per-article protection levels, report review, account banning).

What turned out to be of the main lessons in developing this: creating a site where people can log in and publish their own content is a completely different category of project. I feel like half of the overall work revolved around this. Things like email notifications, account management, moderation dashboards, licensing/copyright considerations, etc., had to be thoroughly planned out and tested from every possible angle. I don’t feel so bad serving myself up a bug, but I really don’t want to disappoint or confuse a user who’s contributing to my site. And I need to prevent misbehaving users from doing any damage.

I also wrote a bot to crawl the map for article-less labels, search for etymologies on sources with a friendly license (e.g., Wikipedia and Wiktionary) and automatically write articles. For legal reasons I need to manually review every post, so it’s not fully automated but it does help a lot. That’s a project for another post.

The source code for Toponymia can be found here on GitHub.

The word Kammer is German for “chamber”, as in a secret room. I’m not entirely sold on the name, but I can’t think of anything better. This is one of the more complex programs I’ve ever made, so there’s still a good amount of testing and tweaking to do. I created a website at www.keykammer.com. If that website is up, then the program is in a pretty good state.

The next step (after it’s fully functional) is turning this into a phone app. A simple messaging/chat GUI where you open/join a room by selecting a file. I imagine it won’t be too hard after the CLI/backend side is completely done.

Details

Here’s how it works:

Say Alice runs the program with a picture of her dog as the keyfile: keykammer fluffy.jpg. The file is hashed to a room ID, and that same file derives the key that encrypts every message. Her client asks a discovery server whether that room exists yet; it doesn’t, so the room is listed - meaning the server now holds exactly one fact, that this room ID is at this address. Bob runs the program with the same file, derives the same room ID, and the discovery server hands back Alice’s address so his client can connect directly to her. Once the room hits capacity (two users by default) the listing is deleted, so if anyone else goes looking for the room there’s no evidence it existed. The discovery server is optional anyway - you can bypass it with a direct address, or run your own.

It’s written in Go, and the same binary is the chat server, the client, and the discovery server depending on the flags. Peers talk over gRPC; rooms live only in RAM, only while users are connected, and nothing is ever written to disk. Messages are encrypted before they leave the sender, so the discovery server only ever sees room IDs and addresses. There’s a terminal UI and UPnP port forwarding to get through home routers.

Room IDs are SHA-256; the encryption key comes from HKDF-SHA256 over the file contents, and messages use AES-256-GCM. HKDF rather than another hash because keyfile entropy varies so wildly - a JPEG and a short text file are very different inputs - and HKDF is built to produce uniformly random key material from uneven input. GCM because it authenticates as well as encrypts, so tampering makes decryption fail outright and there’s no separate MAC to get wrong. It’s all Go standard library plus x/crypto/hkdf.

The obvious limitation is that there’s no forward secrecy - the key comes from the file, so it’s the same every session, and anyone who gets the file can read recorded past traffic. The file is the identity, which is the whole design, but it means keyfile hygiene is essentially the entire threat model.

The code and prebuilt binaries are here on GitHub. Again, it mostly works, but it isn’t finished - I’m not really used to all this networking… work.

GEDCOM 5.5.1 is the standard interchange format for genealogy software, but it’s a machine format, not something anyone would want to write by hand. Here’s an example from the Genmark README:

0 @I_mary_smith@ INDI
1 NAME Mary Ellen /Smith/
1 SEX F
1 BIRT
2 DATE MAR 1895
2 PLAC Portland, Oregon
1 DEAT
2 DATE 28 FEB 1978
2 PLAC Portland, Oregon
1 FAMS @F1@

That same data represented in Genmark is:

Mary Ellen Smith [mary_smith]
  sex: F
  b: 1895-03 @ Portland, Oregon
  d: 1978-02-28 @ Portland, Oregon

So Genmark exists basically to put a readable layer on top of that: you write a person as one block of plain text, and the compiler produces valid GEDCOM. And really, if you don’t need to use GEDCOM, Genmark is a great format by itself. The idea is that the .gmd file is the actual research archive - not an import/export intermediate - so it can be read, diffed, grepped, and edited directly. The repo includes configuration files for Emacs, Vim, and VS Code to make editing there even more convenient.

The Genmark program is written in Go and ships as a single static binary via go install or prebuilt cross-platform releases (Linux, macOS Intel/ARM, Windows). The compilation process follows the following pipeline: a lexer tokenizes the source, a parser builds an AST, and a compiler walks it to emit GEDCOM, with a first pass to register every record’s ID before a second pass resolves references - so forward references (citing a person before their record appears) will work fine.

I didn’t include absolutely everything available in GEDCOM, but I tried to cover most of what people would need for real genealogical research. Life events - birth, death, christening, burial, immigration, naturalization, residence, census, occupation, military service, education, arbitrary custom events - all take a common description/date/place shape:

occ: Factory Foreman (1921..1945) @ Portland, Oregon

There’s a wide range of options for how you might want to organize your genealogical data, largely based on how much data you’re storing on how many people. You could keep it all in one file if you want to, but Genmark compiles across multiple files and even whole directory trees, resolving every [id] reference globally. You can organize the data however makes sense: one file per person, one per branch of the tree, one per surname or region, etc. A combine subcommand concatenates multiple .gmd files back into one, preserving comments and formatting, for when you want a single reviewable document without producing GEDCOM.

Sharing a tree usually means redacting any living people, so compile --privatize strips anyone not demonstrably (or assumed, by configuration) dead. Media files can be attached to a person via a media: field and can live in per-person or per-branch directories alongside the .gmd files; --copy-media gathers everything actually referenced in the compiled output into a single bundle beside the GEDCOM (skipping media orphaned by privatization) so the tree is portable without manually collecting/reorganizing files.

Beyond compiling, there’s a small set of analysis subcommands aimed at research itself rather than output: check validates a set of files for undefined references and conflicting facts without producing a GEDCOM, and shows every maybe: as a running list of things to verify; places tallies where events happened, with a --by-region mode that rolls up to state or country and an --at YEAR mode that infers each living person’s approximate location at a given point in time from their most recent dated event; and names tallies given, middle, and surnames across the dataset, useful for spotting naming patterns or picking a name that runs in the family.

You can see the code and download the binary here on GitHub. Again, I’m using this for my own work without really needing the GEDCOM compilation at all (so far), so the most important details are in the documentation/specs, not the code (although the program’s other subcommands are also useful). For a very thorough description of the syntax see SYNTAX.md, and for more examples you can look at EXAMPLES.gmd.

The name comes from MULtilingual NER API.

How it works

You supply a list of URLs to check. The program scrapes the content, works out what language it’s in, pulls out the named entities and any security-relevant indicators, flags anything on a watchlist, and optionally translates the results into English. It was built with OSINT work in mind, but there’s nothing security-specific about the core of it. It could be used to monitor for any keywords using any list of URLs.

Content language is detected automatically, then mapped to a spaCy model by language code. English and German are configured out of the box (just for testing, really), and anything else falls back to spaCy’s multilingual model, which is less accurate but means unsupported languages still get processed rather than rejected. Adding a language is just a few lines of YAML and a model download. You can also register a transformer-based model as its own option if you’d rather have the accuracy than the speed, which is roughly a twenty-fold tradeoff.

Alongside the NER, it pattern-matches IOCs - IPv4 and IPv6 addresses, URLs, domains, email addresses, MD5/SHA-1/SHA-256 hashes, and CVE identifiers - and checks the text against configurable watchlists, which ship with the usual threat actors and malware families but are just a YAML map of category to terms. One thing worth knowing: the watchlists are matched against the original text, before any translation, so terms need to be written the way they’d actually appear in the source language.

Translation runs through the Google Translate API and is entirely optional; without credentials everything else still works. Results are cached in Redis, mostly to keep from paying to translate the same entity repeatedly. I guess we could put a translation step on both sides of the pipeline, so your keywords/IOCs could stay in English and be run against foreign sites. Maybe someday.

You can find the code here on GitHub.

Once again, I’ve built in a default workflow that incorporates Emacs' Org mode file format. While I’m out in the garden can hit the Orgzly widget on my phone to quickly save a note. That syncs to my laptop with Syncthing, and when I have the chance I separate out (org-refile) my garden notes into their own file. later I can ask the LLM to import my notes, and it calls sync_notes to parse the Org file and interpret the entries.

Underneath it’s a SQLite database of plants, locations, and activity history. The client does all the natural language work; the server only does structured storage and retrieval. It exposes tools for the writes (registering a plant, recording a planting, logging activities, updating a location) plus a read-only SQL escape hatch, and a handful of resources that give the AI ambient context without it having to ask.

An important point in the schema: a plant is registered once, and each instance/group of it growing somewhere is a separate planting. So peppers started in a seed tray and then split between a raised bed and some pots are three plantings of one plant, tracked independently. When a planting is finished, or a bed gets torn out, it’s marked inactive rather than deleted, so the history stays intact.

* Transplanted tomatoes outdoors
:PROPERTIES:
:CREATED:  [2026-04-21 Tue 15:32]
:END:
Put them in pots 3, 4, and 5.

From that the model can check which of those pots already exist, create the missing ones, add a planting for each, and log the transplant. Re-importing the same file is safe; entries are deduplicated by timestamp and content.

Nothing about the design (aside from the prompts and database schema) is really specific to gardening. It’s a structured, persistent memory an LLM can read and write, and it wouldn’t take much to point it at something else entirely. Though, if that’s all you want, I’m sure other programs do it better.

The code is here on GitHub.

The extension and source code are available here.

“Smak” means taste in Norwegian, Swedish, Polish, and Middle English. I considered “Geschmackdown” or “Schmackdown” as the German option, but… it just sounds worse to me.

I don’t know if this is a common sentiment, but I’m usually annoyed by modern food blogs. It’s like they’re intentionally designed to be inefficient, to keep you on the site longer. You need to browse through the history of the food, and the history of the author’s relationship to the food, before getting to the recipe. I know it doesn’t bother everyone - my wife likes the extra context and doesn’t really understand why it bothers me. I considered - actually, I’m still considering - designing a food blog at the extreme end of this context spectrum, where the reader is likely to never even find the recipe…

In any case, I built Smakdown partially to get around this “feature” of modern recipe websites. But that’s really only half of the motivation. Even if you don’t mind all the reading, if you’re someone who prefers to work in plain text (as I do) and likes to keep organized markdown or Org-mode notes (as I do), then I’m sure you can see the benefit in using this.

The “native-messaging helper” I mentioned earlier is a real weak point of this program’s design, but it seemed like the most reliable way to write to arbitrary files on the user’s system. This means you can’t just download the extension from the extension store, you need to download/install the .xpi file directly, and then run the Python install script.

HTML is the standard export format for bookmarks, but I like to keep things in an editable plain text format. I picked Org because I use Emacs, but it’s better than HTML no matter which editor you use (but way better in Emacs). Bookmarks look like this in the file:

* Bookmarks Toolbar
** Wikipedia                                 :reference:
[[https://wikipedia.org/]]

** Development
*** GitHub
[[https://github.com]]
Code hosting platform

Tags come across as org tags, Firefox’s keyword shortcuts become properties, and any text under a link is kept as a description. Nested folders of any depth survive the round trip. Timestamps don’t - I decided ADD_DATE stamps on every entry were more clutter than they’re worth, and I doubt anyone is nostalgic about when exactly they bookmarked something.

Once bookmarks are plain text, the usual benefits follow: they diff, they can go in git, and you can edit them the way you edit anything else in Emacs. The specific thing I wanted was org-refile - dumping a messy browser export into one file and then filing bookmarks one at a time into a clean one, without leaving the editor. The README includes the Elisp bit of init.el I use for that, which restricts refile targets to folders within the bookmarks file.

It’ll also merge multiple inputs into a single Org file, combining folders with matching names, and --deduplicate drops repeated URLs (keeping whichever came first, so listing your organized file ahead of a fresh browser export does the sensible thing). Your browser won’t do that for you.

This turned out to be one of my programs that I actually use regulary. It’s a Go CLI, with binaries for Linux, macOS, and Windows. The code is here on GitHub.

Stations show up as Group / Name - Jazz / KMHD - and selecting one calls radiotray-ng’s play_station over D-Bus. If radiotray-ng isn’t running yet the script starts it in the background and waits for it to appear on the session bus, so the keybinding works from a cold start rather than failing the first time you press it. There’s also a --standalone mode that drops radiotray-ng entirely and plays through mpv --no-video, driven over mpv’s JSON IPC socket; if an mpv instance is already listening there, the new station is sent to it instead of spawning a second player.

Station data comes from radiotray-ng’s own bookmarks file, but an optional bookmarks.org takes priority, which is much nicer to edit. Those play through play_url, so they don’t have to exist in radiotray-ng’s bookmarks at all.

The remaining flags are conveniences for the dwm setup: --toggle for a single-key play/stop binding, and --status, which prints the current Artist - Title (or the station name, if the stream sends no metadata) and nothing when stopped, so it drops straight into slstatus as a run_command. It’s one Python script, standard library only.

The code is here on GitHub.

sitella f (genitive sitellae); first declension

1. an urn for holding ballots

Sitella is a prototype of an end-to-end verifiable voting system - one where anybody can check that the announced result is the correct count of the ballots actually cast, without anybody being able to learn how a given person voted. It’s a single Rust binary that plays every role: election server, voter client, organizer tooling, and public auditor.

I’ve heard people saying that the relatively recent development of blockchain technology could bu used to solve issues of election security. I started this project out as an exploration of that idea, but ended up dropping the blockchain aspect entirely. All of the specific requirements I had for the final result were satisfied by cryptography alone.

An election runs in five steps:

1. Voters register once, and the important detail is that the secret is generated on the voter’s own device - the organizer only ever receives a public commitment to it, and must never generate the secret itself.
2. At the registration deadline the roll of commitments is frozen and published as a plain text file, with its Merkle root pinned in the first record of the transcript.
3. To vote, the device encrypts the choice, proves the ciphertext is well-formed (exactly one candidate), proves in zero knowledge that it belongs to some holder of a secret on that frozen roll, and derives a nullifier that spends that identity’s single vote. No name and no commitment travel with the ballot. The server re-checks everything, appends it to a hash-chained public transcript, and hands back a signed receipt pointing at the ballot’s position.
4. After close, the encrypted ballots are summed while still encrypted, and only the totals get decrypted - by the trustees together, each proving its decryption share is honest, so no individual ballot is ever decrypted and no complete decryption key ever exists.
5. Then anyone can run sitella verify against the transcript and re-check all of it offline: the hash chain, every membership and ballot proof, every nullifier, the voting window, the sums, the decryption proofs. A voter can additionally point it at their receipt and see their own ballot sitting in the count.

But if you wanted to verify that your ballot was actually cast for a particular candidate/proposal/etc., that is not possible. Before looking into this whole “voting” topic, I knew we’d need to handle attacks from bad actors, but hadn’t really considered legitimate voters misbehaving. You don’t want to give someone the ability to confirm what they voted for - they could show that verification to someone who is either paying them for the vote, or who is coercing them to vote for something against their will.

This system could (theoretically) scale from a national election down to an office lunch poll. Although, it is very much a prototype and not something you’d want to run a real election on (yet). I still have a few improvements planned, and I’ll keep this post updated along with the code.

Get the program here on GitHub.

I haven’t actually deployed this anywhere yet. I was thinking it would be funny to collect a massive amount of individual instances of one meme, and then run a site that serves them up randomly, one at a time.

The whole thing is a Lua block inside the Nginx config. On each request it scans the image directory with LuaFS, picks a random file from what it finds, and emits a small HTML page displaying it centered on a black background, with a cache-busting query parameter so the browser doesn’t just hand back the previous image. There’s no application behind Nginx, and no index or database of the images - adding a picture to the directory is the entire deployment step.

Using LuaFS instead of shelling out to ls is the main reason it stays reasonable to expose: nothing user-controlled ever reaches a shell. Beyond that it runs as the unprivileged nobody user, rate limits by IP (30 requests a minute by default), sanitizes paths so nothing outside the image directory can be reached, only serves a whitelist of image extensions, and sets the usual security headers.

It deploys either with Docker Compose or with an install script that handles the Nginx and Lua packages directly on Debian- or Fedora-based systems. Dimensions, port, rate limit, and hostname all come from .env. There’s a small attribution tooltip in the corner, which you could remove or point at something else.

The code is here on GitHub.

If you have an image that includes text, you can feed it into this program and it tells you which font that text most likely is. More accurately, it tells you which of the fonts in the training set are most similar to the image text.

It works in three stages. First it builds its own training data: it walks a directory of .ttf files and renders every letter and digit of every font to a 200x200 grayscale image, so each font becomes a folder of labelled glyphs. Then it trains a CNN (TensorFlow/Keras) on those images, with one class per font. Finally, given a real image, it uses OpenCV to pull the individual characters out - CLAHE to even out the contrast, Otsu thresholding to get a clean black-and-white image, contour detection to find the character boundaries - classifies each character separately, and aggregates those per-character scores into a single prediction for the image as a whole.

See it here on GitHub.

1. How can we incorporate LLMs into security applications?
2. How can we break the security of LLMs?

This program addresses that first question. It’s a Chrome extension for automated security analysis of web pages, servers, and code. It checks SSL/TLS certificates, DNS records, and HTTP security headers, evaluates Content-Security-Policy, queries the VirusTotal API, and integrates multiple LLM providers (OpenAI, Anthropic, Google). The backend is Python/Flask.

This project was my first time creating a browser extension. It’s also, to be honest, probably the last program I wrote without the help of AI. I took this class during the final term of my master’s; everything after this has been a personal project. This was the final project for the course, and my son was born during that finals week of the final term of my master’s. I even made a commit from the delivery room.

See it here on GitHub.

I built this because I tried letting Claude Code organize a few ebooks, and it destroyed my entire system. I didn’t lose any data, but I had to reinstall Linux. Somewhere in the process I’d given Claude permission to `mv` files into the parent directory, and after letting it run a while I realized it had backed out a few times too many and moved my entire `home/` directory to some other directory in root. At that point it’s not really safe to simply move things back. But at least all my data was still there, I just saved what I needed and reinstalled.

So then, the design is deliberately not an agent wandering around your filesystem. It’s a fixed pipeline, and most of the work went into giving the model as little room as possible to be creative. First it gathers metadata - from the filename, from whatever is embedded in the file, and from an Open Library lookup, which usually supplies subjects and a Dewey number - so the model rarely has to fall back on its own knowledge of a book. Then it classifies, in two small multiple-choice steps: pick a top-level section, then pick a leaf directory inside it. The options are enums built from your actual directory tree and enforced by the structured output grammar, so the model can’t invent a category or a path. Dewey numbers map to a section hint in plain code, not by asking the model. And since my ebooks directory is constructed using my drewy-decimal script, DDC numbers are actually very helpful in this organization.

Every decision is sent to a JSON manifest with a confidence score, and nothing touches the library until you’ve been through them. The confidence number is really just the model’s own self-report, uncalibrated. So it’s a more of a key for review, not a guarantee. You approve, reject, or edit each proposal (or bulk-approve above a confidence threshold) and only then does execute copy the approved books in, renamed Title - Author (Year).ext.

It copies, never moves; the tree is treated as read-only, so directories are never created. If a book fits nowhere, that’s a needs_review outcome and it’s your call whether to add a directory and run it again. Re-runs are idempotent and classify is resumable, so you can interrupt a long run without losing work.

And the runs are… long. Speed is entirely about prompt prefill - the model reading a long list of candidate directories - which on a CPU means minutes per book. A GPU is worth 10-50x here and needs no configuration, so classify prints the model placement at startup to tell you whether you’re actually getting one. If your machine is CPU-only you can point --ollama-url at Ollama running on a rented GPU box over an SSH tunnel; only metadata and directory names go over the wire, so the ebooks themselves never leave your machine.

The code is here on GitHub.

The script has saved me a lot of time through multiple Linux installs, but I’m not sure how useful it would be for anyone else. Years of customization are included in this, and you’d really only want to use it to end up with my exact OS setup. I don’t expect there are many people using anything remotely near my setup, although I guess someone out there may want to try it out. Surely the combination of just dwm and Colemak-DH puts me in an extreme minority.

However, you could start with my script as a base and edit it to create your own Linux setup script. The overall design of the script would make a good starting point for any Linux user.

The workflow is: install Fedora from the netinstall ISO with ‘Basic Desktop’ and nothing else selected, clone this repo into the new home directory, drop .fonts/ there alongside the script, and .ssh and .gnupg into secrets/, then run it and answer the prompts. That’s the whole thing. I can go from a bare install to a fully configured machine without touching anything else.

Here’s an overview of what it does:

1. Copies SSH and GPG keys in from secrets/
2. Creates my standard home directory structure
3. Updates the system with dnf
4. Installs and configures LightDM, and puts a custom background on the LUKS unlock screen at boot
5. Installs the development packages I want and removes the ones I don’t
6. Clones and builds my own versions of dwm, st, and dmenu, and sets up an xinitrc for the dwm session
7. Stows my dotfiles with GNU Stow
8. Sets zsh as the default shell
9. Sets up my KMonad configuration
10. Clones whatever other repos I’ve listed into their target locations

Every step except the package update asks for confirmation first, so you can pick what you actually want at runtime rather than editing the script beforehand.

The KMonad piece is probably where this gets least portable. On top of Colemak-DH, it puts modifiers on the bottom row as hold-keys: in qwerty terms, hold z for ctrl, x for alt, c for super, v for a numpad under the right hand, with the mirror image on /, ., ,, and m; hold space for vim-style direction keys; caps lock is backspace. Mod + grave switches layout, but colemak_dh_ortho is my default and dwm is configured around it. Which is roughly the point at which I realized how few people are going to want to run this unmodified. I’ll make a separate blog post about my keyboard setup.

The script is here on GitHub.

I couldn’t decide how to organize my ebooks, and eventually decided to just use DDC. This would help me become more familiar with the system, and also I can just look up a book’s official DDC number when I can’t decide where it belongs in my library.

It isn’t strict DDC, though. The 000s, which in real DDC are a mix of “general works” and computing, have been completely redesigned for modern computing topics. Everything from 100 up follows the standard divisions: philosophy, religion, social sciences, language, science, arts, literature by original language, history by region.

The other deliberate departure is that the numbers only go two levels deep. Below that, directories are named, not numbered:

Library/000_Information_Technology/001_Foundations/Algorithms_Data_Structures
Library/000_Information_Technology/006_Security/Cryptography
Library/900_History/940_Europe/Scandinavia

That keeps the top of the tree principled and the bottom of it flexible - I can add, rename, or delete leaf directories freely without worrying about whether the numbering still makes sense.

The whole thing is one bash script that creates the tree, and it’s meant to be edited rather than run as-is. It reflects the books I have and expect to have; you’d want to delete the branches you’ll never use and add your own.

It also pairs with llm-librarian which uses a tree like this one as the fixed set of destinations it’s allowed to file books into.

The script is here on GitHub.

That mostly meant fine-tuning bert-base-uncased for five-class sequence classification: tokenizing reviews to a fixed length, attaching a classification head, and training with a low learning rate. It was a lot of practice with the mechanics of adapting a pretrained model to a specific task, as opposed to training something from scratch.

I also added a second metric alongside plain accuracy: predictions within one star of the true rating. Star ratings are ordinal, and treating them as five unrelated classes makes a 4-for-5 mistake look as bad as a 1-for-5 mistake, which doesn’t reflect how wrong the model actually is.

Again this was just a school project, but if you’re interested the code is here on GitHub.

The A* version is the more straightforward strategy. Each node is a word, its neighbors are every word in the dictionary one letter away, and the heuristic is Hamming distance to the target: how many letters still differ, which never overestimates the steps remaining, since a step can only fix one letter at a time. Filtering the dictionary down to words of the right length first keeps the branching manageable.

The genetic algorithm approach is more interesting (I think). A chromosome is an entire candidate ladder, start word to end word, with random junk in between; fitness scores each adjacent pair by how close the two words are, rewarding single-letter steps heavily, penalizing repeats, and docking points for length so ladders don’t sprawl. Then the usual operators, plus a few specific to the shape of this problem: growth and shrink mutations that insert or remove a word mid-ladder, seeding the initial population with words one letter off the endpoints, and targeted mutation of whichever link in the chain is the weakest. Most of those are toggles, which is what the comparison scripts exist to test.

The code is here on GitHub.

Questions come from four categories - distance, weight, temperature, volume - in both directions, and you can practice any combination of them by typing the category letters together. Stats persist between sessions so you can see which category you’re worst at. It’s a small C program with no dependencies.

The code is here on GitHub.