Series and Tags in Time

By John Hardy
January 11, 2026 | Series: indexing

I treat the archive as an ordering problem once articles exist as files with frontmatter. The same set of entries groups in different ways depending on what a reader wants. Two of those groupings matter here: series and tags.

A series describes a narrative and carries the idea that one entry follows another, so reading in order carries meaning. Series pages group all articles with the same series value and sort them by date ascending. The first article sets context and each one extends it, so the list grows forward in time.

Tag pages describe subject matter and collect material that shares a topic without implying sequence. A reader who clicks a tag expects to see what is most recent first, since recency tends to track relevance. Tag pages group by tag and sort by date descending. Older entries remain available, but they do not define the view.

Both groupings come from the same frontmatter table. Each article contributes a row with its date plus tags and series. The build applies different sorts to that same data. I need no extra structure in the files themselves. What changes is how I shape the list.

This distinction lets the archive behave in two different ways at once. A series behaves like a log or a chaptered notebook, where order carries weight. A tag behaves like a topical index, where breadth and freshness matter more than sequence. The same article can sit inside both without conflict, because one describes its place in a story and the other describes what it is about.

Follow a series when you want the story in order and the earlier posts matter. Use tags when you want the latest work on a topic and you are checking what changed.

Tags: series, tags

Indexing as Queries

By John Hardy
January 11, 2026 | Series: indexing

I treat indexing as a query problem, not a rendering problem. Every list on the site comes from a named query that selects a set of articles and a sort order. That keeps selection declarative and repeatable, and it keeps logic out of templates.

Queries live in JSON, not inside templates. A template names the query and provides a slot. Then the build fills that slot with either summaries or full article bodies. The template never decides what exists, and it never learns how selection works.

This separation keeps indexing logic small and inspectable. If a list looks wrong, I can read the query and see exactly why those items appear. The build avoids inference and guesswork, which prevents hidden selection and keeps the lists predictable.

The constraint is intentional because queries are plain objects, not a DSL. They cannot grow into a second programming language. That limit is a feature: it prevents hidden logic and keeps the system declarative, not imperative.

This keeps the lists debuggable because every entry maps back to a named filter.

Feeds follow the same rule, and the global feed plus tag or series feeds come from named queries that avoid scraped HTML. That keeps discovery aligned with the rest of the site and makes the outputs small and deterministic.

I can change a template without changing the data, or refine a query without touching markup. Indexes remain mechanical outputs of named inputs. The result is no surprise lists and no invisible filters.

Tags: indexing, queries