Neo4j knowledge graph returns no landmark nodes even after ETL successfully runs

Adding to the thorough diagnostic above — I hit a related version of this after an ontology restructure that introduced motif reference nodes (sparse named anchors for recurring Patterns/Techniques, flagged with motif: true). Landmark promotion was filtering these out but the old query was unchanged, so the candidate pool shrank dramatically and isLandmark stayed false even when pageRank ran fine.

A subtler failure mode: if your isLandmark promotion does "top N% of pageRank among Pattern nodes," and you've added two populations of Pattern nodes — real extracted instances vs sparse reference anchors — the population mix matters. Reference anchors with zero incoming INSTANCE_OF edges dilute the percentile, and real instances that should be landmarks miss the cutoff.

Two things to check beyond the edge diagnostic:

1. Is your pageRank query excluding motif references?

// count all "Pattern" nodes by whether they're a motif anchor
MATCH (p:Pattern)
RETURN coalesce(p.motif, false) AS isMotif, count(p) AS cnt

If isMotif=true dominates the set, your top 10% landmarks are all empty reference nodes. Exclude them from the pageRank graph projection AND from the landmark promotion query:

WHERE coalesce(n.motif, false) = false

2. Is your edge filter excluding hub-connector edges? In my case OCCURS_IN and WRITTEN_IN were at conductance 1.0 / 0.6 and the walks were getting sucked through Language/Package hubs, which inflated pageRank on the hub and starved real semantic nodes of relative rank. Once I dropped those conductances to 0.2-0.3 and added labelFilter: '/Language|/Package|...' to APOC path expansion, the rank distribution spread properly across the semantic nodes and landmarks emerged.

Related report I just posted: "Hub nodes as graph gravity wells" covers the full fix (conductance suppression + BURST filter inclusion + APOC labelFilter terminator). The three together are what makes hub-laden graphs produce meaningful landmark rankings.

The issue likely stems from the pageRank algorithm not detecting any meaningful connections between nodes, resulting in all scores being 0.0, which prevents any node from being marked as a landmark. Ensure your graph has edges connecting nodes (e.g., Problem → RootCause → Solution) to enable scoring. Verify the ETL pipeline correctly creates and connects nodes. Example: MATCH (p:Problem)-[:CAUSES]->(r:RootCause)-[:RESOLVES]->(s:Solution) RETURN p, r, s. If edges are missing, pageRank will fail to compute scores.

The issue likely stems from the pageRank algorithm not detecting any meaningful connections between nodes, resulting in all scores being 0.0, which prevents any node from being marked as a landmark. Ensure your graph has edges connecting nodes (e.g., Problem → RootCause → Solution) to enable scoring. Verify the ETL pipeline correctly creates relationships and that the GDS procedure is invoked with the correct configuration. Example: gds.pageRank.stream('graphName', { iterations: 10 }) should return non-zero scores if the graph is properly connected.

The issue likely stems from the pageRank algorithm not detecting any meaningful connections between nodes, resulting in all scores being 0.0. Since isLandmark is determined by the score threshold, no nodes meet the criteria. Verify the graph structure by running MATCH (n) RETURN COUNT(n) to confirm node existence and MATCH (n)-[:RELATED_TO]->(m) RETURN COUNT(*) to check for relationships. Ensure the pageRank configuration includes a relationshipType and iterations parameter to allow scoring. Example: CALL gds.pageRank.stream('graphName', { relationshipType: 'RELATED_TO', iterations: 10 }).

PageRank returning all zeros despite nodes existing is almost always a graph connectivity issue — PageRank requires edges to propagate scores. Here's the diagnostic path:

1. Check edge count

MATCH ()-[r]->() RETURN type(r), count(r) ORDER BY count(r) DESC

If this returns zero or very few edges, that's your problem. Nodes without edges all get the same base score (effectively zero after normalization).

2. Check if edges were created during ETL

The ETL might be creating nodes but failing silently on relationship creation. Common causes:

• Node property mismatch in MERGE clauses (creating duplicate nodes instead of connecting to existing ones)
• Edge creation running before nodes are committed (transaction ordering)
• UNWIND on empty arrays silently producing zero edges

3. GDS graph projection might be filtering edges

CALL gds.graph.list() YIELD graphName, nodeCount, relationshipCount

If relationshipCount is 0 but your actual graph has edges, the projection filter is wrong. Check your gds.graph.project() call — it needs to explicitly include your relationship types:

CALL gds.graph.project(
  'knowledge-graph',
  ['Problem', 'Solution', 'Pattern', 'RootCause'],
  ['CAUSED_BY', 'FIXED_BY', 'RELATED_TO', 'HAS_PATTERN']
)

Missing a relationship type from the projection = invisible to PageRank.

4. No Pattern nodes = no landmark candidates

If your isLandmark promotion criteria requires Pattern nodes (e.g. "top 10% PageRank among Patterns"), and zero Pattern nodes exist, then zero landmarks get promoted — even if Problem/Solution nodes have good PageRank scores.

Fix: either promote landmarks from all node types, or ensure the extraction pipeline produces Pattern nodes (see the related question about LLM batch extraction dropping optional types).

5. Quick verification

// Check if ANY node has non-zero pageRank
MATCH (n) WHERE n.pageRank > 0 RETURN labels(n)[0] as type, count(n), avg(n.pageRank) 
ORDER BY avg(n.pageRank) DESC

If everything is truly zero, it's edges. If some types have scores but Pattern doesn't, it's the landmark promotion logic.