conductance

Generic Description

A cut-quality metric that measures how easily a community leaks to the rest of the graph.

Simple example:

CALL nexyron.conductance()

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 conductance when boundary sharpness matters more than a single global modularity score. 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

Conductance asks whether a set is well-insulated: do edges mostly stay inside, or do they leak out heavily? It is especially useful for validating whether a proposed community is operationally separable, not just mathematically assigned.

How It Differs From Nearby Algorithms

Compared with modularity, conductance is often more local and boundary-focused. Compared with community detectors, it scores a partition or subset instead of creating one. Compared with cut optimization procedures, it is the metric rather than the optimizer.

When To Choose It

• evaluating whether communities are truly isolated enough to act on
• checking suspicious bridge-heavy communities
• comparing partitions where boundary quality matters

More Detailed Explanation

A community may have acceptable modularity but poor conductance because it leaks into the rest of the graph through many boundary edges. That distinction matters in fraud, reliability, and operations use cases where leakage is the real problem.

Advanced Example

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

CALL nexyron.conductance() YIELD algorithm, community_id, community_size, cut_weight, volume, conductance
RETURN algorithm, community_id, community_size, cut_weight, volume, conductance
LIMIT 10

Real Use Cases

• Decide whether a suspected fraud ring is tight enough to isolate operationally.
• Validate whether a service cluster is really a domain boundary or just a loose neighborhood.
• Compare candidate partitions for intervention planning where cross-boundary leakage is expensive.
• compare algorithm output with domain labels or time windows before operationalizing it
• feed graph-analytic scores into ranked reports, feature contracts, or investigation queues only after checking the modeling assumptions

Real Limitations And Tradeoffs

• Low conductance alone does not tell you what the group means.
• Some domains naturally have bridge-heavy structure, so strict conductance can punish realistic communities.
• Like all summary metrics, it should be paired with direct inspection.
• algorithm output reflects the projected graph, not an abstract real-world network outside the data model
• nearby algorithms can answer different questions even when their output columns look similar