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 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.
GLaaS (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.
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 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 — connect a repository so TReqs has code to run.
- Compute targets — give it somewhere to run.