The TGraphX Workflow Surface: APIs, CLI, Notebooks, Dashboards, and Artifacts

The first breadth article in this series mapped what TGraphX can do across tasks. This one maps how you drive it — the surfaces through which a developer actually gets work done, from a one-line API call to a CLI health check to a local dashboard. A framework can have excellent internals and still be painful if the workflow surface is thin; TGraphX's is unusually broad for a research package, and this article ties each surface to a real entry point.

If you are just starting, Getting Started with Tensor-Valued Nodes is the on-ramp; this is the map of everything around it.

The workflow coverage map

The shape of this table is the point: there is a path for every working style — a one-liner for a quick check, a predictable aliased API for everyday code, and the explicit Stable layers when you need full control.

Three API altitudes

TGraphX deliberately offers the same capability at three altitudes. Easy mode (tgraphx.easy) is the zero-boilerplate path — train a tensor node classifier in one call and get back a result object with metrics. The ux layer (tgraphx.ux) adds LLM-predictable aliases and one-call helpers (classify_nodes, kg_completion, make_graph) that route to canonical implementations, as covered in API Stability and Aliases. And the explicit API — Graph, the tensor layers, build_model — is the Stable foundation for custom research code. You can drop from any altitude to the one below when you outgrow it; the v1.4.1 notes even document an "escape hatch" from EasyResult to raw PyTorch.

The CLI surface

pyproject.toml registers several console scripts, so common operations do not require writing a script:

• tgraphx-doctor — environment and install verification (the Colab gallery's notebook 28 uses it to confirm a fresh install in seconds).
• tgraphx-train, tgraphx-grid, tgraphx-report — config-driven training, grid sweeps, and reporting through the experiment manager.
• python -m tgraphx readiness — a package-readiness summary (optional deps, public-API count, known limitations), plus list-datasets and list-methods for discovery.

A CLI that includes a doctor and a readiness command signals a project that expects to be installed in unfamiliar environments and wants failures to be legible.

Notebooks, dashboard, and artifacts

For learning, the public Colab gallery curates over 30 CPU-runnable notebooks, each focused on one concept and runnable in under two minutes, alongside the tutorials/ quickstarts. For inspecting results, tgraphx-dashboard serves a local, offline-capable dashboard over run artifacts; audit_run_dir / dashboard_audit even return UX quality scores (completeness_score, reproducibility_score, portability_score, scientific_reporting_score, 0–100) so a run can be graded on how reproducible and well-reported it is. For persistence, the write_* metadata writers, the dataset_card / model_card / benchmark_card helpers, and .tgx serialization (see Serializing Tensor Graphs) capture a run in inspectable form.

Honest framing

Two qualifications. Most of this surface is Beta — tested and documented, API stable within v1.x, but not a hardened production MLOps platform; the dashboard is explicitly local-first and offline, not a hosted service. And breadth of surface is not the same as depth in any one of them: the CLI covers common flows rather than every option. What the breadth does guarantee is that you are unlikely to hit a wall where the framework simply offers no way to do something common — there is almost always an easy, a ux, or an explicit path.

A new user's first hour

If you are evaluating TGraphX, a sensible order through these surfaces makes the first hour productive. Start at the CLI: pip install tgraphx, then tgraphx-doctor to confirm the environment is sane. Next, run one Easy Mode call (tgx.easy.train_node_classifier(...)) or the matching gallery notebook to see an end-to-end result on synthetic data in under two minutes. Then open tgx.public_api() and tgx.api_status() to see the surface and its stability labels — this tells you which calls are safe to build on. Only after that drop to the explicit Graph and layer APIs for your real model. Finally, wrap the run in a reproducible() context and write artifacts so your first real result is already recoverable.

This path — doctor, one-call demo, registry, explicit API, reproducible run — front-loads the cheap checks and defers detailed work until you know the install and the surface are solid. Profile and measure performance later; first confirm the framework runs and does what you expect from the source.

Related guides

• Getting Started with Tensor-Valued Nodes
• Serializing Tensor Graphs: save/load and GraphML
• API Stability and Aliases
• Schema-Stable Experiment Packaging

Conclusion

TGraphX's workflow surface spans three API altitudes, a practical CLI (doctor, train, grid, report, readiness), a Colab gallery of over 30 notebooks, a local dashboard with run-quality scoring, and artifact/metadata tooling. The breadth is honest — mostly Beta, local-first — but it means a developer can enter at the altitude that fits the moment and always find a supported path forward. That is what makes a research framework pleasant to live in, not just powerful on paper.