---
title: clique_counting
url: https://nexyron.tech/docs/cypher/procedures/algorithms/clustering-and-triangles/clique-counting
description: Clustering and triangle procedures measure local closure: whether neighbors of a node also connect to each other. They are useful for cohesion, trust, fraud ring, and dense neighbo
---

# clique_counting

## Generic Description

Count cliques by size.

Simple example:

```cypher
CALL nexyron.clique_counting()
```

Clustering and triangle procedures measure local closure: whether neighbors of a node also connect to each other. They are useful for cohesion, trust, fraud-ring, and dense-neighborhood analysis.

## Consumer-Level Explanation

Use `clique_counting` when count cliques by size is the graph-analysis or operational question you actually need to answer. Keep the call explicit because its `YIELD` columns, row grain, and required runtime state determine how the rest of the Cypher pipeline can safely compose it. These procedures explain local structure rather than global communities. High triangle counts can mean cohesive groups, repeated event modeling, or simply high degree, so interpret them with the graph model in mind.

## Conceptual Explanation

`clique_counting` should be read as one named procedure contract in the broader Nexyron Cypher surface. The procedure call is not only a syntax hook: it defines what runtime state, projection, registry entry, or graph algorithm is being asked to operate, and it determines which output columns downstream `YIELD`, `WITH`, and `RETURN` stages can safely use.

## More Detailed Explanation

Clique counting is stricter than triangle or community work because every member must connect to every other member

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.

## How It Differs From Nearby Algorithms

Clique counting is stricter than triangle or community work because every member must connect to every other member.

## Advanced Example

This example yields named columns from `clique_counting` and returns a bounded result shape that downstream planner tooling can compose without guessing column names or row grain.

```cypher
CALL nexyron.clique_counting() YIELD size, count
RETURN size, count
LIMIT 10
```

## Real Use Cases

-   dense-ring detection
-   subgroup strictness analysis
-   quality checks for candidate communities
-   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

-   full cliques are rare in messy real graphs and expensive in dense graphs
-   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