chemenu/instructions/link-taxonomy.md

---
type: types/instruction.md
name: link-taxonomy
description: The link-label catalogue - every relationship label a page may declare in related:, grouped by register, with the reader need each one names. A palette to authorise from in a COLLECTION.md, never binding on its own.
manual: true
---
# Pick a link label

**This page is a palette, not an enum.** It lists every label this stack ships with and what
each one asserts. What a page may actually *use* is decided by its own collection: each
`kb/<name>/COLLECTION.md` authorises a subset per destination, and `wikitool lint` checks
`related:` against that authorisation rather than against this file. A collection that
authorises six labels has six, however long this list gets.

A label is an **identifier, not prose**. It is written into `related:` as a machine value and
rendered verbatim into the page body, so it is never translated - not in a German wiki, not in
any other. Which words a page is *written* in stays [kb/CONVENTIONS.md](../kb/CONVENTIONS.md)'s;
this is not one of them.

## The invariant every label obeys

Every label completes, with the page carrying the link as the grammatical subject:

> `[source] <label> [target]`

The page containing the link asserts something **about** the target. `Hermes depends-on
PostgreSQL` reads correctly on Hermes' page; the same fact written on PostgreSQL's page is a
different label (`required-by`), not the same one pointing back. Omitted helper verbs ("is",
"a") are fine where they do not reverse the endpoints.

This is Commonplace's ADR-058, adopted wholesale, and it is what makes a label checkable rather
than a matter of taste: read the sentence out loud, and if it says the opposite of what you
meant, the label is wrong.

## Direction is authored, never mirrored

Each direction is a separate decision. A link back from the target is welcome when it
independently helps a reader *there* - and unnecessary when it does not. **Do not add a reverse
edge merely to mirror the first one.** The inbound view is rendered from the graph by
`index rebuild` and `search`, so a reader landing on the target sees what points at it whether
or not anyone wrote a second edge.

That is why most labels below have no inverse. Only two pairs do, because in each the reverse
direction is a genuine primary statement someone would write on its own: `depends-on` /
`required-by` and `runs-on` / `hosts`.

## When to run

Adding or changing a `related:` entry, authorising labels in a `COLLECTION.md`, or judging
whether a relationship is worth naming as a formal edge at all.

## Steps

1. **Decide whether this is an edge.** Not every mention is one. An edge is a reader aid: it
   says *follow this if you need X*. A subject mentioned once in passing is prose with a
   `[[wikilink]]`, not a declared relationship. Over-declaring is how a graph becomes a list of
   everything adjacent to everything.

2. **Say the sentence.** `[this page] <label> [that page]`. If it reads backwards, you want the
   other page to carry the edge, or a different label.

3. **Pick from the register that fits the pair**, below. Prefer the most specific label that is
   true; fall back outward only when nothing fits.

4. **Check the collection authorises it** for that destination -
   `kb/<name>/COLLECTION.md`'s `outbound:` block. If the label you want is not authorised and
   should be, that is a collection-contract change, made deliberately, not a lint error to
   route around.

5. **Write it with the tool**, never by hand:

   ```bash
   tools/wikitool xref add --a "<This Page>" --b "<That Page>" --rel <label>
   ```

## The catalogue

### Operational

Concrete things and how they stand to one another - the register this instance runs on. Mostly
entity to entity.

| label | inverse | asserts |
|---|---|---|
| `depends-on` | `required-by` | cannot function without the target |
| `required-by` | `depends-on` | the target cannot function without this |
| `runs-on` | `hosts` | executes on the target as its substrate |
| `hosts` | `runs-on` | provides the substrate the target executes on |
| `uses` | — | employs the target at runtime, but survives without it |
| `produces` | — | emits the target as an artifact or data |
| `consumes` | — | reads the target as an artifact or data |
| `maintains` | — | carries the upkeep of the target |
| `owns` | — | is accountable for the target's existence and decisions |

`uses` versus `depends-on` is the distinction worth keeping sharp: if removing the target breaks
this thing, it is `depends-on`. `owns` versus `maintains`: accountability versus labour, and
they are often different people.

### Realization

How an idea becomes a running thing. Usually concept to entity or the reverse.

| label | asserts |
|---|---|
| `implements` | is a concrete realization of the target |
| `operationalized-from` | is the prescriptive form of the target's theory |
| `mechanism` | is the mechanism by which the target works |
| `procedure` | is the procedure for carrying out the target |
| `applies-when` | applies under the condition the target describes |
| `operates-on` | acts upon the target as its subject matter |
| `invokes` | calls the target as a step within itself |

### Conceptual

Inference and comparison between ideas.

| label | asserts |
|---|---|
| `extends` | develops the target's argument further |
| `grounds` | provides the basis the target rests on |
| `rests-on` | takes the target as its premise |
| `enables` | is the operational prerequisite that makes the target possible |
| `precondition` | must hold before the target applies |
| `exemplifies` | is an instance of the general claim the target makes |
| `abstracted-from` | generalizes from the target |
| `contrasts` | differs from the target in a way worth reading both for |
| `compares-with` | is weighed against the target on shared dimensions |
| `contradicts` | asserts something the target denies |
| `composition` | is composed of the target |
| `part-of` | is a component of the target |

`grounds` / `rests-on` is a genuine pair and both directions are primary statements; they are
listed separately rather than as inverses because either page may legitimately carry only its
own side.

### Lineage

Where something came from, and what replaced it.

| label | asserts |
|---|---|
| `supersedes` | replaces the target, which is now historical |
| `derived-from` | was produced from the target |
| `adapted-from` | was reworked from the target for a different purpose |
| `defined-in` | takes its definition from the target |

A superseded page is never deleted or rewritten - see the collection contract for
`kb/concepts/`.

### Evidence

The provenance register. Distinct from `sources:` and `[^cite-id]`, which are the *mechanical*
provenance path: these two are authored claims about how strongly something is backed.

| label | asserts |
|---|---|
| `evidenced-by` | is supported by the target as evidence |
| `is-evidence-for` | serves as evidence for the target's claim |

### Universal

| label | asserts |
|---|---|
| `see-also` | nothing more specific applies, and a reader here would still want the target |

**`see-also` is the last resort and should stay rare.** A collection where it is the commonest
label has a vocabulary problem, not a lot of loosely related pages. The previous vocabulary's
`verwandt mit` was exactly that, and it is the reason this catalogue exists.

## Extending it

Adding a label is a line of data, never a code change:

1. Add a row here, in the register it belongs to, with the sentence it completes.
2. Authorise it in the `COLLECTION.md` of every collection that may use it.

The registers are advisory groupings for readers, not a schema - nothing checks that a label is
used only within its register. Invent an intra-collection label the work needs and propose it
here afterwards; the architecture is deliberately loose, because the link theory is still
developing.

## Decision points

- **Two labels both fit?** Take the more specific one. If they are equally specific and mean
  different things, the relationship is probably two edges.
- **The relationship reads better from the other page?** Write it there. Nothing is lost - the
  inbound view renders it here.
- **You want a reverse edge for navigation?** You do not need one. That is what the rendered
  inbound view is for, and it is complete in a way an authored mirror never was.
- **Nothing fits at all?** Use `see-also` and say so in the commit, or propose a label. Do not
  stretch a label whose sentence reads false - a wrong edge is worse than a weak one, because
  it is machine-readable and will be believed.

## Scope

Covers labels on `related:` edges between pages. Says nothing about `sources:` (the provenance
field, unlabelled by construction), `[^cite-id]` footnotes
([kb/CONTRACT.md](../kb/CONTRACT.md#provenance-and-citation)), or `tags:` (search keys, not
relationships).