Building a Small Recommendation Engine in the Open

Most publishing sites place “related articles” beneath a post. The relationship may come from shared tags, an editor’s selection or a system trained on what earlier readers clicked. The result looks simple: three cards and an invitation to continue.

I want to try a different question. Could a recommendation help a reader change perspective rather than remain within the same pattern?

The smallest version requires no machine learning. Every article already has one primary lens—Direction, Interdependence, Possibility or Reality—and one or more subject tags. A reader finishing a technology article through the Reality lens could be offered another technology article through Possibility. Alternatively, the system might keep the lens and change the subject, moving from real production systems to sustainable practice.

The first prototype will use a tiny rule set. Choose one article that shares the subject but changes the lens. Choose one that shares the lens but changes the subject. If several qualify, rotate them rather than rank them by predicted engagement. Each card will include a short explanation such as “Another view of technology, focused on what might emerge” or “A practical encounter with a different subject.”

This is intentionally unsophisticated. A rule-based system can be inspected, tested and explained. It does not need a reader profile, a third-party service or enough traffic to infer patterns. For a small independent publication, those are not temporary limitations. They may be features.

Building it in public makes the design choices visible. The goal is not maximum pages per session. That metric would encourage suggestions that resemble what already held attention. The intended outcome is a meaningful next step: a connection the reader understands and might not have chosen unaided. Measuring that outcome is harder.

Click-through rate can tell me whether the cards attract interest, but not whether they expand understanding. A short optional prompt—“Was this a useful connection?”—might provide a signal, though prompts add friction and self-selection. Occasional reader conversations may teach more than a dashboard. For now, the prototype can be evaluated by editorial review: do the explanations feel truthful, and do the paths create variety without becoming random?

The labels themselves introduce tension. A lens is an editorial perspective, not an objective property discovered by an algorithm. If the recommendation treats it as a fixed fact, the system may give a neat taxonomy more authority than it deserves. The interface should therefore use ordinary language and let the writing lead. Metadata supports discovery; it should not become the main event.

There is also a cold-start problem in miniature. With only a few posts, some combinations do not exist. A rigid rule will return the same items repeatedly. I could solve this by adding more fallback logic, but complexity might conceal the editorial gap. Perhaps an empty route is useful information: it shows which pairings have not yet been explored and could inspire the next article.

Later experiments could use text embeddings to discover less obvious relationships. That possibility is attractive because two posts may share an idea without sharing a tag. Yet embeddings would add computation, opacity and maintenance. Before adding them, I want evidence that the simple model fails in a way semantic comparison can genuinely improve.

Privacy provides another boundary. A recommendation system does not need to remember an individual reader to be useful. Session context could prevent immediate repetition without building a lasting profile. Aggregate counts could show whether routes are used. Beginning without personalisation keeps the experiment focused on the quality of editorial relationships.

I will also keep an editorial override. If a rule produces a connection that is technically valid and plainly unhelpful, the publisher should be able to replace it without changing the taxonomy. Recording those overrides may reveal a better future rule—or show that judgement is the feature the automation should support rather than imitate.

The code will be the easy part: a few arrays, filters and fallback rules. The difficult work is defining what the recommendation is for. By publishing the rules and the changes, I can make that purpose open to inspection.

Perhaps the experiment will show that hand-picked links are better. Perhaps it will become a quiet feature that sends readers sideways through the archive. Either result is useful. The prototype turns a familiar design pattern into a visible question: when a publication suggests what comes next, what kind of curiosity is it trying to cultivate?