modularity_metric

Generic Description

A quality metric for judging how strongly a proposed partition separates internal ties from external ones.

Simple example:

CALL nexyron.modularity_metric()

Community detection procedures partition or group nodes by structural affinity. They are useful for segmentation, fraud-ring analysis, recommendation features, and exploratory graph profiling.

Consumer-Level Explanation

Use this to evaluate a partition, not to confuse evaluation with discovery. Different community algorithms optimize different objectives and assumptions. Modularity methods, label propagation, block models, overlapping memberships, and partition-quality metrics should be chosen for the question, not swapped blindly.

Conceptual Explanation

Modularity is one of the most common ways to score a community partition. It tells you whether a partition has more internal connectivity than you would expect from a degree-preserving null model. That makes it useful for comparing candidate partitions, but dangerous if treated as the only definition of quality.

How It Differs From Nearby Algorithms

Unlike Louvain or Leiden, this does not produce communities by itself. Unlike conductance, it is a more global partition metric. Unlike community analytics suites, it gives a compact numerical judgment rather than a narrative profile.

When To Choose It

More Detailed Explanation

The right mental model is “scorecard”, not “community detector”. A good workflow is to compute modularity, then check conductance, sample nodes, temporal behavior, and document abstractions before concluding the partition is useful

In practical queries, start by deciding the row grain you want after the call: one row per node, one row per path, one row per registry object, one row per artifact, or one row per summary. Then keep that grain explicit with YIELD and named projections. That is the difference between a useful planner-facing example and a vague call that downstream tooling cannot safely compose. For contract-driven procedures, the executable examples on these pages intentionally inspect procedure metadata unless the required named artifacts are created in the same example.

Advanced Example

The advanced example keeps modularity_metric in a named Cypher pipeline so the procedure output shape, downstream filters, and returned columns are visible to planner tooling.

CALL nexyron.modularity_metric() YIELD algorithm, num_communities, modularity
RETURN algorithm, num_communities, modularity
LIMIT 10

Real Use Cases

Real Limitations And Tradeoffs