Connections, backlinks and the knowledge graph
How the “Article connections” block is built, what each group means, and how an editor links two articles without a second content store.
🎯 For Editors and readers who follow a topic across several pages
- Read the three connection groups correctly
- Understand why the page never depends on JavaScript for navigation
- Link two articles from the Django admin
Every article ends with a connections block. It answers one question: where should I go next if this page was not enough? The block is built from the database, not from a hand-maintained index, and it is readable without JavaScript.
🔗 The three groups
| Group | What it means | Where it comes from |
|---|---|---|
| Linked articles | An editor explicitly pointed this article at them | related_articles on the article |
| Linked from | Those articles point here | The same field, read backwards |
| Same topic | Neighbours in the same category | The article's category |
Order matters: explicit links first, then backlinks, then neighbours. The page shows at most eight connections — a graph with forty edges is decoration, not navigation.
🧭 Why a list and a map
The block contains two things at once:
- A plain list with real links. It works with JavaScript disabled, on a screen reader, and when the map fails to draw.
- A mini-map drawn by the page script from the same data. It gives the shape of the neighbourhood at a glance: the current article in the centre, its connections around it.
The map is progressive enhancement. It never contains information the list does not have, and it is hidden from assistive technology because it duplicates the list.
For the full picture there is the knowledge graph in the main product
(/kb): all published articles, not one neighbourhood.
📚 What a connection is not
- It is not an automatic embedding similarity. Nothing links two articles just because a model thinks they look alike.
- It is not a promise of freshness. A linked page can be older than the link.
- It is not a ranking signal. The wiki does not chase link counts; it tries to answer the next question.
✍️ How an editor links articles
- Open the article in the Django admin.
- Find Related articles and add the target.
- Save. The change is recorded as a revision like any other content edit.
There is one rule: link to a page that exists and is published. A link to a draft is invisible on the public page, and the editor will not notice the mistake until someone reports a dead end.
🚧 When this does NOT work
- You want a cluster of twenty related pages. Eight is the cap; nobody reads the ninth.
- You expect cross-language links. Each language has its own page; the connection block follows the current language and falls back to English titles for pages that are not translated.
- You need an external graph database. The wiki reads the two fields it already has. A separate graph store would be a second source of truth for the same edges.
➡️ Next
- How this wiki is edited and published — the rest of the editorial workflow.
- Sources and verification — what a linked page must prove.
- Open the article index: /wiki/articles.json.
Sources
Each source was opened by a human on the date shown. Product behaviour is described from this deployment, not from marketing material.
🔗 Article connections
Open the full knowledge graph ↗Next steps
Related reading
Models and routing: what the composer control changes
You pick a route, not a vendor. The receipt is the source of truth for which model answered and what it cost.
Workspace and agentsAI judging: why “it says it is done” is not acceptance
Deterministic checks decide. A model's self-report is a claim, and a separate read-only check is cheaper than shipping the failure.
Workspace and agentsSplitting work across agents — and when not to
A swarm in Tvijo is several bounded tasks in separate working copies, each with its own budget and receipt. Coordination cost is real; here is how to decide.
💬 Comments