Docs
What SIDERIUS can do
You bring a dataset and a research question. SIDERIUS proposes a model, writes and checks it, trains and scores it, and uses each result to plan the next try.
What changes when you use it
Before: finding a good model means reading results, thinking of the next architecture, writing code, fixing it, tuning it and comparing scores again, all by hand. It is also hard to say later exactly how a given score was produced.
With SIDERIUS: agents with one job each carry out those steps in turn. Training, scoring, data splits and validity checks are not left to the agents: SIDERIUS does them the same way every time and records every run.
After: you spend your time on the science (which data, which metric, what counts as a valid result) while the agents try more models, and every score can be traced back to how it was made.
Seven words to know
Each links to its full description in the reference or a tutorial.
- WorkflowThe plan for one experiment: which modules run, how they connect and what they may spend. It is saved as a Python file in your project, and every save becomes a version you can return to.
- Capability (module)One agent with one job: interpret results, review literature, propose a model, implement it, validate the code, or train and tune it. The console shows each as a card.
- ConnectorA typed socket on a module, such as Model plan or Code verdict. An output connects only to an input of the same type, so a wrong wire is refused before anything runs.
- AdaptorA small fixed step between modules that chooses or splits results, for example train only the first implementation that passed Validate.
- AggregatorAn adaptor that combines several results into one input, for example several literature reviews for one proposal.
- RouteA rule that runs part of a workflow only when an earlier result meets a condition, for example a backup branch that runs only if the first Validate fails.
- Research loopRepeats the workflow round after round. Each round's Training report goes back to Interpret results, and stop conditions can end the loop early.
Worked example: one round of the Quick start loop
Quick start opens a ready-made research loop: Interpret results → Propose model → Implement → Validate → Train & tune, then back to the start. Here is one round. The score is made up for the example.
| Module | What happens |
|---|---|
| Interpret results | Round 1: there is no earlier result yet, so it reads the starting summary the run prepared and sends a Results analysis. |
| Propose model | Reads the analysis and the advice you typed into its advice field ("start from a small baseline"; the Quick start template connects that input) and sends a Model plan for a small convolutional network. |
| Implement | Writes the plan as model code and sends Model code. |
| Validate | Loads the code, runs its tests and checks that gradients flow. The Code verdict says it passed. |
| Train & tune | Tries a few settings in short trial rounds, then trains a formal round within your time budget. SIDERIUS scores it and runs your task's Health checks. Say the valid score is 0.81. |
| Research loop | Sends the Training report back to Interpret results. Round 2 starts from "0.81, underfits long signals" instead of from nothing. |
With Final iteration 5 and a No improvement stop after 2 bodies, the loop runs at most 5 rounds; if rounds 3 and 4 both fail to beat the best score, it stops after round 4.
Who owns what
- You: the task itself: data, model inputs and outputs, metric and validity checks. They live in a task package in your project, written with your coding agent.
- The agents: interpreting, proposing, writing and checking code, and picking hyperparameters during training.
- SIDERIUS itself: selecting data, actually running training, scoring, Health checks and keeping records. None of this depends on what an agent says.
What 1.1.0 includes, and what is coming
- The browser console: Quick start, drag-and-connect workflow building, the workflow check, named versions, a step-by-step Run page, Monitor and Stop.
- Research loops with three stop conditions: metric threshold and no improvement (set in the console), and a judge model (declared in the workflow source by your coding agent; no console editor yet).
- Routes, adaptors and aggregators: declared in the workflow source by your coding agent and run from the command line; the console cannot create them yet.
- Coming soon Aggregators that use a language model.