Atlas

Graph communities & layout

A graph of thousands of entities is only legible if it's arranged. eli.ai computes a stable ForceAtlas2 layout and Louvain communities on the server, persists them with a version, and serves the precomputed positions to the explorer — so the graph opens laid out and colored instead of jittering into place in the browser every time.

How it's built

Compute on the server, version it, point at it, serve it.

Server-persisted ForceAtlas2 layout

Layout runs server-side over canonical_relations — the same serve-time edge table everything else reads. ForceAtlas2 produces an (x, y) position for every node, and the result is written to graph_layout, one row per node, carrying:

x, y — the persisted position, so the client renders without running a physics simulation.
communityId — the Louvain cluster the node belongs to (below).
pagerank and degree — centrality signals used to size and prioritize nodes.
layoutVersion — which computation produced this row.

Versioned, with an atomic pointer

Each recomputation writes a new layoutVersion rather than mutating rows in place. When it finishes, workspace_meta.currentLayoutVersion flips to point at the new version. The explorer always reads through that pointer, so a viewer never sees a half-written layout: they see the previous complete version until the instant the pointer advances to the next complete one. Stale versions can be reclaimed without touching what clients are reading.

Why persist instead of compute client-side

A browser force simulation is non-deterministic and slow on large graphs — every reload lands nodes somewhere new. Persisting positions makes the map stable (a node is where you last saw it) and fast(open, don't simulate), and it moves heavy computation off the client entirely.

Louvain communities

Louvainmodularity detection partitions the graph into communities — tightly interlinked clusters that usually correspond to something real: a workstream, a system-and-its-dependencies, a team. Each node's communityId is stored on its graph_layout row in the same pass as positions, so clustering and geometry always agree and are versioned together.

Community coloring & legend

The explorer colors each node by its communityId and renders a legend mapping colors to communities, turning a hairball into a readable map: you can see at a glance which clusters exist, how large they are, and where they bridge. Combined with pagerank/degree sizing, the important nodes in each community stand out.

a graph_layout row (illustrative)json

{
  "entityId": "01J…",
  "x": -142.6, "y": 88.1,
  "communityId": 3,
  "pagerank": 0.021, "degree": 17,
  "layoutVersion": 12
}