Compose and run pipelines
A pipeline you build once and run again on anything.
A project owns its universe, benchmark, date window, data lineage, features, runs, strategies and reports. A workflow is an ordered, validated, versioned list of methods drawn from the catalogue. Together they turn a sequence you ran once into something you can hand to someone else and press run.
- Workflow templates
- 5Blank, Signal research, Volatility modelling, Portfolio construction, Pairs and relative value
- Step outcomes recorded
- 5ok, unavailable, skipped, blocked, failed
- Methods to compose from
- 119
01What you actually do here
Five things, in the order the page presents them.
- 01
Create a project, choose where its data comes from
A new project has no universe until you apply one. The preset decides which index to show, which benchmark and which currency; the securities are yours to tick. Every downstream statistic inherits that choice, including its survivorship bias.
- 02
Compose the pipeline from the catalogue
Pick methods, order them, bind parameters. A step declares what it consumes and what it produces; the composer checks that every input is produced earlier or supplied by the project, and separates blocking problems from warnings.
- 03
Run it, or run a draft before saving
A draft can be run without committing a version, so an edit can be tried first. The route re-validates before submitting, and an invalid workflow is refused with its blocking reasons rather than started.
- 04
Read the run record
Each step records when it started and finished, the parameters actually used after defaults were resolved, and one of five outcomes. A failure stops what depends on it and nothing else. A step that cannot run is recorded, never dropped.
- 05
Re-run on new data, keep every version
Saving bumps the version and appends the previous record to the history; nothing is overwritten. Archiving keeps every version reachable, which matters when a result elsewhere cites the version that produced it.
01bThe loop as a path
Eight stages, one direction, nothing skipped silently.
A workflow runs the stages in order and records an outcome for each. Choose a stage to see where it sits; the same order governs the composer's validation, the run record and the report.
02How it works
The method, stated for the specialist.
A workflow is a specification, not a script. It can be written, validated, saved, versioned, diffed and re-run with different bindings without any engine being involved. Validation happens before running, not during.
- Blocking versus warning
- Missing name, unknown method, invalid binding, a dependency that is not in the workflow, or a cycle: blocking. A step whose declared inputs nothing earlier produces, or a method catalogued but not available in this deployment: a warning that does not block.
- Ambient inputs
- Prices, returns, series, universe, benchmark, correlation, covariance, features, weights and the trial ledger are supplied by the project whatever the step order. Fundamentals, factors, macro series and execution records must come from a data step.
- Parameters as used, not as written
- The run record stores the method defaults overlaid with the step's own bindings, so the answer to "what did this actually run with" is in the record, not in someone's memory.
- Refusal over storage
- Save refuses an invalid workflow. A saved workflow is something another person will pick up and press run on; storing one already known to be broken makes the archive untrustworthy.
- Project isolation on switch
- The outgoing project's results and configuration are written out first, then in-memory state is cleared, then the incoming project loads. Nothing computed on one universe can be on screen while another loads.
03What you get out
Outputs, and what they let you defend.
The pipeline's output is the record. Every figure that later appears in a report can be traced to a run, a step and a parameter set.
- A per-step run record with outcome, timings, resolved parameters and produced artifacts
- Report-ready evidence blocks emitted by the steps that produced them
- A version history for every saved workflow, never overwritten
- A workflow you can diff, share and re-run with different bindings
- Dashboard workflow health across the eight stages, computed from real state
04What this does not do
Stated plainly, because it matters as much as what it does.
No graphical DAG editor
Steps are ordered and can declare dependencies on earlier steps by id. There is no canvas of draggable nodes in the workspace; the site's composer preview is a preview.
Not a scheduler for production jobs
Runs execute as jobs inside the workspace. A durable job queue for long-running validation and training is on the roadmap.
Not execution
A pipeline ends at evidence. Nothing in it places or routes an order.
Compose your first pipeline on a real question.
Beta researchers start from a template, swap in their own data, and keep the run record.