A run doesn't only produce a model — it produces the account of how that model was made. Publishing sends that account to GLaaS, the registry that makes an artifact's lineage lookup-able by its content hash.
So later on, if you have a model and you want to recall the full context. Compute its hash, look it up in GLaaS to see it's full pipeline and all the inputs used, and click the link from GLaaS to the training request in TR that triggered it.
What gets captured
If roar is installed on the compute target, the run captures lineage as its stages execute — what each stage read and wrote, at which commit.
Getting roar onto the target is the install_roar flag in your workflow's Python environment block, or --install-roar on an on-demand compute target. Without roar there, there's no lineage to publish regardless of the mode you choose.
Visibility modes
What happens to that lineage afterwards is set per training request:
| Mode | Result |
|---|---|
disabled | Nothing is published. |
private | Published to GLaaS, linked to the project, visible only to people who can see the project. |
public | Published publicly and attributed to your organization. |
public_anonymous | Published publicly without attribution. |
Set it when creating the request:
treqs tr create --title "Train v2" \
--workflow-path .treqs/workflows/train.yaml \
--lineage-mode private
The two public modes require confirmation — interactively, or with --yes in a script. That's deliberate: publishing publicly is not reversible in any meaningful sense, since anyone may have read it already. Think of public as the decision it is.
Republishing
If a run completed but its lineage didn't reach GLaaS — a transient failure at publish time — you can republish without re-running:
treqs jobs republish-lineage <job-id>