NodemancyDocsMapLibraryCards
Troubleshooting

My links didn't connect anything

The import said it worked, the nodes are there, and the graph shows them floating alone. Almost always one cause: the slugs were guessed rather than copied.

What happened

A link points at a slug, not at a title. When the slug it names does not exist, the edge is not created — and nothing is reported afterwards, because an unresolvable link is legal.

Here is the canonical version, from a real generation. The lens held these nodes:

wg-nixon — Richard Nixon wg-cox — Archibald Cox wg-richardson — Elliot Richardson

The model wrote links to these:

[[wg-richard-nixon]] [[wg-archibald-cox]] [[wg-elliot-richardson]]

Every edge dropped. And notice what went wrong: the model was not careless — it produced the more informative slug, the one a person would probably have chosen. It reconstructed a name into a slug instead of copying the slug that was already there. That is why this happens to good output.

How to check

The preview tells you, if you were looking. Each unresolvable link produces a warning naming the target:

Link target "wg-richard-nixon" doesn't resolve — the edge will be dropped.

After the fact, open one of the isolated nodes and read its links. If the slug it names looks like a fuller, more spelled-out version of a node you already have, that is this.

The authoritative list of what actually exists is resources/existing.md inside the lens skill — every node in the lens as slug — Title. Download a fresh one and compare.

Two things that look the same

Before fixing anything, work out which of these you have — they need opposite responses:

If the target is…Then
a node you already have, under a different slugA mistake. Fix the link to use the real slug — or, if the duplicate node also got created, merge them.
a node a later batch is going to createFine, and often better than leaving a node isolated. The edge fills itself in when that node arrives — provided the later batch uses the identical slug.
nothing you recogniseThe model invented a neighbour. Delete the link; an absent edge is a gap, a wrong one is a claim.

Why nothing errored

Because a link to a node that does not exist yet is a legitimate thing to write. It is how you author towards something, and it is how a batch links forward to the next batch. The app cannot tell that apart from a typo, and refusing the import would break the useful case to catch the accidental one.

So the failure is silent by design — and the design is right, which is exactly why the preview warning is the moment to catch it.

Preventing it

  • Give the model the lens skill, not the taxonomy file. Groups & relations contains no nodes, so a model given only that has nothing to copy from and will invent every slug it links to.
  • Re-download the skill between batches.By the ninth batch the first has left the model's context, and it will re-derive a slug it used earlier.
  • Set slug: explicitly when your lens tags its slugs. Without it, title: "Sam Dash" becomes sam-dash — and every sibling that linked to [[wg-dash]] misses.
  • Read the preview warnings before confirming. They are the only place this is visible before it becomes work.
Ask for the forward references. A model that has just written a batch can list the links it made to nodes that do not exist yet — which turns an invisible failure into a checklist you can read in ten seconds.

The related failure: duplicates

The same cause produces the same second symptom. If a model reconstructs wg-richard-nixon and then createsthat node, you now have two Nixons — one with your links, one with the new batch's — and the graph is split between them.

The preview catches part of this: a node whose slug already exists comes in as exists · skip and is not duplicated. What it cannot catch is a differently-sluggednode about the same subject, because from the app's side those are two different nodes.

Related