TGraphX Across Graph-Learning Tasks: A Grounded Capability Map
It is tempting to summarise a research framework with a list of buzzwords. This article does the opposite: it maps what TGraphX actually covers across graph-learning tasks, ties each area to a real module, and attaches the project's own stability label so you can tell a tested foundation from an evolving experiment. The framework's README capability map and docs/api_stability.md are the source of truth; this is a reader's guide to them.
First, the vocabulary. TGraphX uses four labels: Stable (public API will not change in v1.x), Beta (tested and documented, API stable within v1.x), Experimental (correct foundations, API may evolve), and Optional (needs an optional dependency). The package as a whole is Beta — a validated research framework, not a 1.0-forever product. Reading the labels honestly is the difference between using a feature appropriately and over-trusting it.
The matrix
| Task family | TGraphX concept | Module / path | Stability | Read next |
|---|---|---|---|---|
| Tensor-aware message passing | conv / attention / SAGE / GIN over [C,H,W] nodes |
tgraphx/layers |
Beta | φ→AGG→ψ pipeline |
| Node & graph classification | NodeClassifier, GraphClassifier, pooling |
tgraphx/models, tgraphx/layers/pooling.py |
Beta | Tensor-valued nodes |
| Graph algorithms | BFS/DFS, shortest paths, MST, matching, colouring | tgraphx/algorithms |
Beta | Topology vs feature geometry |
| Graph mining | motifs, centrality, spectral, WL features | tgraphx/mining |
Beta | Motif discovery |
| Scalable sampling | NeighborLoader, GraphSAINT, Cluster-GCN |
tgraphx/{loaders,graphsaint,cluster_gcn} |
Beta | Neighbor sampling |
| Knowledge graphs | TransE/DistMult/ComplEx/RotatE, filtered ranking | tgraphx/kg |
Beta | KG tensor embedding |
| Classical graph generation | ER/BA/SBM/typed generators + metrics | tgraphx/generation |
Beta | Graph generation |
| Neural graph generation | VGAE / autoregressive / transformer | tgraphx/generation |
Experimental | Graph generation |
| Evolutionary optimization | GA, simulated annealing, NSGA-II | tgraphx/evolutionary |
Beta | Evolutionary optimization |
| Graph reinforcement learning | environments + agents (REINFORCE/A2C/DQN/PPO/TD3/SAC/…) | tgraphx/rl |
Experimental | Graph RL |
| Explainability | saliency, integrated gradients, edge attribution | tgraphx/explain |
Beta | Multimodal nodes |
| Reproducibility | set_seed, deterministic mode, run metadata |
tgraphx/{training,ux} |
Beta | GNN reproducibility |
| Hetero / temporal | RGCN/HAN/HGT, TGN/TGAT | tgraphx/{core,temporal} |
Experimental | Multimodal nodes |
The pattern is worth naming: the foundations — message passing, classification, mining, sampling, KGs, classical generation, evolutionary optimization, explainability, reproducibility — are Beta, meaning tested and documented. The frontier — neural generation, graph RL, heterogeneous and temporal graphs — is Experimental, meaning the ideas are implemented with correct foundations but the API or semantics may change. A breadth article that blurred that line would be misleading; the labels are the whole point.
Four senses of "supported"
"Supported" is not binary, so it helps to distinguish how strongly a capability is backed:
- Implemented & tested — has unit tests and a stability label (most Beta items above).
- Documented — has a dedicated page under
docs/(for example knowledge graphs, neighbor loaders, evolutionary optimization). - Example-backed — has a runnable script in
examples/or a notebook in the public gallery. - Experimental — implemented with correct foundations but explicitly labelled as subject to change.
Many TGraphX areas hit three or four of these at once; the Experimental ones deliberately stop short of the first. When you evaluate the framework for a project, the right question is not "does it do X?" but "at what support level does it do X?" — and the capability map answers that directly.
What this map is not claiming
This is not a benchmark table and not a ranking against other libraries. It does not claim TGraphX is the best tool for any of these tasks; mature ecosystems like PyTorch Geometric and DGL exist precisely because large-scale GNN infrastructure is hard, and the TGraphX positioning is explicitly complementary. The map's job is narrower and more useful: to show that the breadth is real and module-backed, and to be honest about where the foundations are solid versus evolving.
How to use it
If you are evaluating the framework, start at the row matching your task, read the linked article, then open the named module and its docs/ page. If your task lands on an Experimental row, plan for some API churn and pin your version. If it lands on a Beta row, you can build with the expectation that the public API holds across the v1.x series. The api_stability contract spells out the per-component details.
The labels are not frozen
One reason to trust this map is that the labels move over time, and the framework lets you check the current state rather than relying on a blog post. tgx.api_status() reports the stability label per component at the version you have installed, and tgx.public_api() lists the current public surface. So if an Experimental subsystem graduates to Beta in a later release — or a Beta API expands — you can confirm it programmatically instead of guessing from documentation that may have aged. When you read this matrix, treat it as a snapshot of the version it describes: pin your version for a paper, and re-check api_status() after an upgrade. A capability map you can query from code is far more reliable than a static table that silently ages, and querying it is the right habit to build when depending on a framework whose frontier is still moving.
Related guides
- Inside Tensor Message Passing
- Knowledge Graph Embedding with Tensor Features
- Graph Reinforcement Learning in TGraphX
Conclusion
TGraphX spans the graph-learning landscape — message passing, classification, algorithms, mining, sampling, knowledge graphs, generation, evolution, RL, and explainability — but its breadth is honest about depth: a Beta core and an Experimental frontier, each tied to a named module. Use the capability map as a routing table, read the stability label before you commit, and the breadth becomes a strength you can plan around rather than a promise you have to take on trust.