Graph algorithms are widely available and rarely used well. The library is a pip install. What decides whether the output means anything is whether the graph underneath it was modeled for the question being asked, and whether anyone checked what the algorithm actually measures before shipping its numbers to a decision maker.
Community detection on a graph where every account connects to a shared payment processor returns one enormous community and no insight. Centrality on a graph with unresolved duplicates ranks the duplicates. The algorithm was fine. The inputs were not.
The algorithms that earn their place, and the modeling that makes them honest.
Louvain and its relatives, to find the groups that transact mostly with each other: fraud rings, collusive sellers, circular payment flows. Most valuable where the group is the unit of interest rather than the individual.
Betweenness, PageRank and degree, to rank what matters structurally. Mule accounts, single points of failure in a supply chain, the supplier whose removal splits the network.
Node similarity and graph embeddings as features for models that cannot otherwise see structure. Often the fastest measurable lift available to an existing model.
Shortest path, weighted path and reachability, for the questions that are literally about routes: beneficial ownership chains, supplier exposure, how far a recall spreads.
The part that decides whether any of the above is meaningful. Which nodes and relationships enter the projection, what gets weighted, and which hub attributes have to be excluded before they swamp the result.
Every engagement opens with your data and your question, never a slide deck.
Kickstart
$500
Deployment
Customscoped to your data
Embedded
Customfull time
The 60-day guarantee. If a deployed solution is not delivering in 60 days, we keep working at no charge until it does.
Almost always connected components, because it is cheap and it tells you whether your graph is one blob or genuinely structured. That answer shapes everything after it. Community detection and centrality come next, in that order.
Billions of relationships is routine with the right projection. The limit in practice is rarely raw size, it is memory during projection, which is a planning problem rather than a wall.
That is often the highest-return version of it. Graph features added to a model that already works tend to produce a measurable lift without touching the rest of the pipeline, and they are straightforward to A/B.
For continuous, queryable work yes. For a one-off analysis, an in-memory graph built from your existing files is often enough, which is exactly what Bridgr does.
By validating against cases where the answer is already known, before trusting it on cases where it is not. If nobody can produce a set of known cases, that is the first problem to solve.
Or email info@eastridge-analytics.com
