TL;DR
One workspace for execution history and candidate library review.
Use it / Skip it
A researcher needs both what ran and what survived. This page keeps run operations and candidate browsing in the same place.
Use when
You need to check progress, reopen outputs, inspect candidates, or hand off a ranked set.
Don't use for
Do not use it for module-specific setup. Start the run from the relevant page first.
Inputs
- Tab
- Runs for execution history, Candidates for scored library review.
- Filters
- Status, target, score, or text filters depending on the tab.
Outputs
- Run or job record
- A persisted job with status, timestamps, inputs, and enough context to reopen it later.
- Artifacts
- CSV, JSON, PDB, or report files depending on the module.
- Decision signal
- A shortlist, score, verdict, or review note that supports the next wet-lab or design step.
Walkthrough
1. Open Runs when something is queued, running, failed, or needs provenance
Open Runs when something is queued, running, failed, or needs provenance.
2. Open Candidates when the question is what to express, export, or compare
Open Candidates when the question is what to express, export, or compare.
3. Use filters before interpreting top rows
Use filters before interpreting top rows. Different modules write different metadata.
4. Reopen the source module for deep inspection when a row needs structural or run-specific context
Reopen the source module for deep inspection when a row needs structural or run-specific context.
Under the hood
- Aggregates persisted run and candidate data written by platform modules.
- Specific artifact availability depends on the module that created the record.
Worked example
Pitfalls
- A high score without provenance is weak evidence; always reopen the source job before handoff.
- Old records may have fewer metrics than newer jobs after schema additions.