# roar, GLaaS, and TReqs

> Three tools, one lineage story — and which one you reach for when.

## Code + Compute + Conversation = Full Context

TReqs is one of three tools that share a single idea: the history of a model should be a fact you can look up, not something you reconstruct from memory. Each covers a different part of that.

[**roar**](https://github.com/treqs/roar) is a command-line tool that watches your commands as they run. Prefix a command with `roar run` and it records what was read, what was written, the git commit, the environment, exit status, and timing — without you declaring a pipeline or writing extra configuration. The result is a DAG inferred from what actually happened on disk.

::u-page-grid{class="lg:grid-cols-2 gap-4"}
:u-page-card{icon="i-lucide-book-open" title="roar guide" to="https://glaas.ai/docs/roar-guide" target="_blank"}
::

[**GLaaS**](https://glaas.ai) (Global Lineage-as-a-Service) is the registry roar publishes to. It makes an artifact's lineage lookup-able by its content hash, from anywhere. Given a model file, GLaaS answers what produced it, from which inputs, at which commit.

::u-page-grid{class="lg:grid-cols-2 gap-4"}
:u-page-card{icon="i-lucide-book-marked" title="GLaaS docs" to="https://glaas.ai/docs" target="_blank"}
::

**TReqs** is where the work gets planned, reviewed, and executed. A training request describes an intended run — code at a commit, a workflow, a compute target — and goes through review before anyone spends GPU hours on it. When it runs, TReqs executes it on your compute and publishes the resulting lineage to GLaaS.

## How they fit together

Read left to right, they cover intent, execution, and record:

- **TReqs** holds the *intent*: what we plan to train, why, who approved it.
- **roar** observes the *execution*: what the run actually touched.
- **GLaaS** keeps the *record*: a permanent, searchable lineage graph.

A training run in TReqs uses all three. TReqs clones your repo at the pinned commit onto a compute target, runs the stages in your workflow file, and — when roar is installed on that target — captures lineage as those stages execute. At the end, the run publishes to GLaaS according to the visibility you chose. See [Training runs](/docs/training-runs) for the publishing options.

## Which do I need?

You can use them independently.

- **roar alone** is useful on a laptop. It answers "where did this file come from?" locally, with no account and no server.
- **roar + GLaaS** makes those answers shared and permanent, so a colleague can reproduce your artifact from its hash.
- **TReqs** adds the parts a team needs: shared compute, a review step before expensive runs, and a record of who approved what.

If you only want lineage, you do not need TReqs. If you want a team to agree on a training run before it happens, and to run it on shared infrastructure, that's what TReqs is for.

## Going the other direction

The flow also runs backwards. If you already have a DAG in GLaaS — something you ran locally with roar and registered — you can turn it into a training request rather than writing one from scratch, starting from **Run on TReqs** in GLaaS. TReqs reads the session's lineage and pre-fills the code, commit, and stages it observed.

## Next

- [Projects](/docs/projects) — connect a repository so TReqs has code to run.
- [Compute targets](/docs/compute-targets) — give it somewhere to run.