Labs, runs and files
Studio keeps three kinds of thing. They persist differently, and only one of them produces something another person can reproduce.
Labs
A lab is Biosimulant’s top-level resource: executable model components described by model.yaml, coordinated by lab.yaml. Everything you run is a lab.
/labs lists the labs you own, the ones you have forked, and public labs you have opened. Forking a public lab gives you your own copy at the exact version you forked from; the original is immutable and stays where it was.
- The schemas are in
lab.yamlandmodel.yaml. - Published labs come from the Hub.
- To change who can see one of yours, see Visibility and sharing.
Runs
A run executes one lab at one exact version on managed compute. /runs is the history, with the lab context behind each simulation.
A managed run records the runtime, the inputs and the version, so it can be recovered after you disconnect and reproduced by someone else. It also yields a signed Evidence Passport.
A local run (biosimulant labs run, or BioWorld.run() in Python) is useful but it isn’t a managed Run and produces no Passport. See Running: local or managed.
To group runs and compare them against one question, use experiments.
Files
/files holds two things: reusable input files you upload, and the outputs your runs produce.
Outputs are artifacts. What a lab emits and how to read it is the artifact outputs contract. Large artifacts come back as short-lived download links, so download them rather than passing the link on.
What persists
| Guest | Account | |
|---|---|---|
| Labs you fork | Session only | Kept |
| Run history | Session only | Kept |
| Uploaded files | Session only | Kept |
| Downloads you take | Yours to keep | Yours to keep |
See Guest and account mode for the session limits.
Next steps
- Run an experiment: several arms, one comparison
- Deployments: publish a Lab version on every push
- Developer API: the same managed runs from your own code