I'm not sure if Subprojects will work for that - can you use the Web UI to compare the artifacts from two separate subprojects?

So I'm thinking maybe a Project for each thing we're forecasting, and then new Tasks for each time we run it

But we're also testing out new models all the time, which are typically implemented as git branches - they run on the same set of inputs but don't output their results into production

I'll give it a shot and see! Just setting up a test server now, so it's still a hypothetical question just from reading the docs so far

awesome, I'll test it out - thanks for the tips!

And then we want to compare backtests or just this week's estimates across multiple of those models/branches

My use case is running forecasting models in production across multiple businesses

Intersting!
I would also add that Task name is not unique and you can use to describe the "process / goal etc" which would make it pretty obvious to search / review from the UI.
Regrading models and branchs, Iw ould use the Task tags (you can have as many as you like) to tag the specific model type (or dev branch if the alg is diff), this means you can also easily filter based on the Tags in the UI.

can you use the Web UI to compare the artifacts from two separate subprojects?

Yes comparison is not limited, in the comparison mode you can add any Task to the comparison, you can also have "flatten view" of projects (i.e. Tasks from all the subprojects) for easy access

thanks for the thoughtful response, @<1523701205467926528:profile|AgitatedDove14> ! I think I'll need to test out some workflows to see what works

Hi @<1532532498972545024:profile|LittleReindeer37>
This is truly a great discussion to have. Personally I think the main difference is that software development is a somewhat linear process , and git captures it very well. But ML is a lot wider nonlinear process, which to me means that trying to conform the same workflow into a Dev tree will end up failing. The way ClearML thinks about it (and I think the analogy to source control is correct ) is probably closer to how you think about project management rather than git. That said, every Task holds everything about the state of process in Dev (ie code, args, env etc) , project is closer to Dev project (sometimes this is a single repo, but with more complicated projects you have multiple ) , but each Task/expriment is a "commit" of you will... I think that subprojects were born from the need to divide the progress into more managable workflow , where you can have multiple Dev streams under the same conceptual project (maybe diff models dev for the same goal). Wdyt ?