Hierarchy

Hierarchy

Links make a graph; sometimes you also want a tree. track builds hierarchy navigation from one conventional relation property: up. A note that declares up:: [[Parent]] sits under that parent, and the engine derives everything else — no separate outline file to maintain. If you know the up/parent convention from Obsidian vaults or org-mode's file hierarchies, this is the same idea.

Declaring a parent

up is an ordinary property whose value is a wiki link. Write it wherever properties live:

up:: [[Projects]]

or set it on the sidecar from the CLI:

track meta --title "My note" --set "up=[[Projects]]"

Only a link-typed value counts (up:: draft is just a string property), and the link resolves the same way a body [[link]] does. A note may declare several parents; the breadcrumb trail follows the first one, while every parent still lists the note among its children.

A published site is a vault, so the same rule holds there: this page's parent is the up in its sidecar, and the trail you see above it was built from that.

What you get

• Breadcrumbs — the Web workspace note view (and this published site) shows the chain of up links above the note, root first. The trail at the top of this page comes from this page's own up property; Block links shows a two-level trail.
• Children — next to the backlinks, each note lists the notes whose up points at it. Open track and you'll see the help topics gathered there.
• The whole tree — the workspace rail carries a hierarchy button between search and the graph. Hovering it opens the vault's entire up forest as a folding tree, in title order. The roots and their children are always in view; anything deeper unfolds where you ask, and the tree remembers which branches you left open. Notes the hierarchy does not place — no parent, no children — are simply absent from it.
• CLI/API — track nav --id N (or --path P) prints the same data as JSON:

{"trail": [{"note_id": 1, "title": "Projects", "...": "..."}], "children": []}

The live server serves it with each note response, and track export-site bakes it into the published bundle, so all three surfaces agree.

Notes

• A cycle (A → B → A) is harmless: the trail stops where it would repeat a note.
• In a vault the relation is data in your notes — track props and queries see it like any property — but the note view keeps it out of the property strip: the breadcrumbs and children are its display, and one relation should not render twice.