Choose an Algorithm from the Decision Question, Validate Assumptions, and Interpret Results Without Overclaiming

Learning outcomes

1. AtlasMart problem: an algorithm portfolio can become a cargo-cult portfolio

After four lessons, AtlasMart can run dozens of GDS algorithms. That capability creates a new risk: selecting the algorithm whose name sounds impressive, then fitting a business story to the score. Production analytics must reverse that sequence. Begin with a decision and a falsifiable structural hypothesis; then select the minimal algorithm family that tests it.

2. The decision-question matrix

3. Algorithm evidence card: required before a production interpretation

decision_question: "Which catalog products act as structural bridges between co-interest groups?"
source_cutoff: "<record timestamp/CDC checkpoint>"
neo4j: "2026.07.1"
gds: "2026.07.0 Community"
projection:
  name: "atlas-ch24-centrality"
  node_labels: [Product]
  relationship_types: [RELATED_TO]
  orientation: NATURAL
  node_count: "<measure>"
  relationship_count: "<measure>"
  degree_distribution: "<record p50/p95/p99/max>"
algorithm:
  name: "gds.betweenness.stream"
  mode: stream
  relationship_weight_property: null
  sampling_size: "<node count for exact, or justified sample>"
  sampling_seed: "<set when sampling>"
  concurrency: 2
resource_evidence:
  estimate_required_memory: "<measure>"
  compute_millis: "<measure>"
validation:
  hand_fixture: "passed"
  baseline: "degree ranking recorded"
  sensitivity: "sampling/direction changes recorded"
interpretation_limit:
  - "structural brokerage only"
  - "not causal"
  - "not profit/value"
refresh_and_rollback:
  cadence: "<define>"
  projection_drop: "CALL gds.graph.drop(...)"
  persistent_write: false

4. One end-to-end bounded Chapter 24 validation run

The following is a runbook skeleton, not fabricated output. It deliberately separates deterministic checks from measurements you must capture locally.

// 1. Verify exact versions.
RETURN gds.version() AS gdsVersion;

// 2. Inspect projection evidence.
CALL gds.graph.list('atlas-ch24-centrality')
YIELD graphName, nodeCount, relationshipCount, schemaWithOrientation, degreeDistribution
RETURN *;

// 3. Estimate chosen algorithm before running.
CALL gds.betweenness.stream.estimate('atlas-ch24-centrality', {concurrency:2})
YIELD requiredMemory, bytesMin, bytesMax
RETURN *;

// 4. Run in stream mode first: no persistent side effect.
CALL gds.betweenness.stream('atlas-ch24-centrality', {concurrency:2})
YIELD nodeId, score
RETURN gds.util.asNode(nodeId).productId AS productId, score
ORDER BY score DESC, productId;

// 5. Compare with simple degree baseline.
CALL gds.degree.stream('atlas-ch24-centrality')
YIELD nodeId, score
RETURN gds.util.asNode(nodeId).productId AS productId, score
ORDER BY score DESC, productId;

// 6. Drop the in-memory artifact when the run is complete.
CALL gds.graph.drop('atlas-ch24-centrality') YIELD graphName
RETURN graphName;

5. Sensitivity is part of correctness for heuristic/approximate analytics

6. Deliberately wrong: compare raw algorithm scores across unrelated graphs

A PageRank score from a six-node product projection and a PageRank score from a million-node supplier graph are not on a shared business scale. Betweenness depends on graph size/path structure; community IDs are labels; similarity metrics have distinct normalization. “Score 12 is twice as important as score 6” is often unsupported.

Repair by interpreting within the algorithm/projection context, using percentiles or rank where justified, and comparing against baselines on the same task. If cross-graph comparability is a requirement, design a validated normalization/calibration scheme rather than assuming raw outputs are portable.

7. Exploration versus production decision support

8. Production checklist across the Neo4j stack

9. Chapter 24 final verification checklist

1. Run RETURN gds.version() and record the exact version.
2. For each projection, record node count, relationship count, orientation, projected properties, and degree distribution.
3. Run an *.estimate form for the chosen algorithm before scale testing.
4. Validate at least one output manually: Degree, Jaccard, or a shortest route.
5. Run at least one baseline and one sensitivity experiment.
6. State what the output proves and what it does not prove.
7. Prefer stream/stats until persistent writes are explicitly justified.
8. Drop Chapter-24 projections and delete only Chapter-24 fixtures.

// Drop all Chapter 24 in-memory projections first.
CALL gds.graph.list()
YIELD graphName
WITH graphName WHERE graphName STARTS WITH 'atlas-ch24-'
CALL gds.graph.drop(graphName) YIELD graphName AS dropped
RETURN dropped;

// Then delete only synthetic Chapter 24 persisted fixtures.
MATCH (n)
WHERE n.chapter24 = true
DETACH DELETE n;

MATCH (n) WHERE n.chapter24 IS NOT NULL REMOVE n.chapter24;
RETURN 'Chapter 24 reset complete' AS status;

10. Bridge to Chapter 25: algorithms become features, and leakage becomes the next risk

Chapter 24 produces structural scores, communities, similarities, and paths. Chapter 25 will use topology and graph-algorithm outputs as embeddings/features in machine-learning workflows. The analytical discipline carries forward: projection cutoff, train/test separation, reproducible randomness, feature leakage, model catalog limits, and non-graph baselines all become mandatory. A graph feature is useful only if it adds measured predictive signal without leaking future or target information.

Summary and next step

Choose an Algorithm from the Decision Question, Validate Assumptions, and Interpret Results Without Overclaiming is useful only when its assumptions and observed evidence stay attached to the decision. The examples above establish a reproducible mechanism and boundary; they do not turn one lab result into a universal production rule.

Next, continue to Node Embeddings from Topology/Properties, FastRP/Node2Vec-Like Concepts, Dimensions, and Reproducibility. Carry forward the verified assumptions, fixture state, version/edition boundaries, and measurements from this lesson instead of treating the next topic as an isolated recipe.

Authoritative references

• GDS Manual v2026.07 — Current Graph Data Science manual and release baseline.
• GDS supported Neo4j versions — Compatibility matrix mapping Neo4j 2026.07 to GDS 2026.07.
• GDS editions — Community includes all algorithms but caps concurrency at four CPU cores and the model catalog at three models; Enterprise adds operational capabilities.
• Algorithm syntax and execution modes — stream/stats/mutate/write/estimate semantics and common algorithm configuration.
• Memory estimation — Estimate memory before allocating algorithm working state.
• Centrality algorithms — Current centrality family and quality tiers.
• Degree Centrality — Degree semantics and weighted/directed behavior.
• PageRank — PageRank iteration, damping, weights, and execution modes.
• Betweenness Centrality — Exact/sampled betweenness, samplingSize/samplingSeed, memory and concurrency tradeoffs.
• Eigenvector Centrality — Transitive influence and power-iteration semantics.
• Louvain — Modularity, levels, tolerance, seeding and execution modes.
• Leiden — Community detection with gamma, theta, randomSeed and connectivity refinement.
• Label Propagation — Fast topology-driven community detection, optional weights and seeds.
• Node Similarity — Structural neighborhood similarity with Jaccard, Overlap, or Cosine.
• K-Nearest Neighbors — Property-based approximate KNN and supported metrics.
• Path finding algorithms — Current shortest path, traversal, spanning, and flow families.
• Dijkstra Source-Target — Positive-cost shortest path semantics; sourceNode/targetNodes current syntax.
• Breadth First Search — Reachability traversal, targets, maxDepth, and stream/mutate modes.
• Graph algorithm operations reference — Current procedure/function names including spanningTree and similarity functions.
• Neo4j current versions — Current Neo4j database release and 5.26 LTS line.