# The pipeline

> Hand a strategy that passed its gate to a conveyor that takes it, under fixed rules, as far as live-ready.

Every stage between a passing backtest and a live run is already a tool:
`gate_check`, `strategy_freeze`, `holdout_evaluate`, `trading_deploy`. The
pipeline strings them together. You submit a candidate once, and a ten-minute
tick moves it forward as far as the evidence allows. Nothing is skipped, and
every step writes the same ledger rows it would if you called the tool
yourself.

## The stages

| Stage | What happens | Leaves by |
|---|---|---|
| `submitted` | Waits for a backtest of the spec on the split | `gate_check` passes, or fails and is **rejected** |
| `confirming` | Freezing pinned new parameters, so one backtest of the frozen spec runs (one trial) | the frozen spec passes its own gate |
| `frozen` | The one-shot holdout is spent | net-positive after costs, or **rejected** |
| `incubating` | A **paper** run on the split's own bars | 14 days and 4 fills without a halt, or **retired** |
| `live_ready` | You are told. Nothing else happens on its own | `pipeline_promote` |
| `live` | A live run beside the paper shadow | a halt or `pipeline_retire` |

A rejection is final for that spec. Submitting it again would be re-running a
test until it says yes, so the pipeline refuses it; register a genuinely
different rule instead, which is counted as a new trial.

## Using it

```
pipeline_submit(strategy_id, split_id, note="the mechanism, in one sentence")
pipeline_status()                 # the board, and the rules in force
pipeline_status(candidate_id)     # one candidate's full history
pipeline_advance(candidate_id)    # take the next step now, not at the next tick
```

Submit only after `gate_check` has passed. The pipeline would reject a failing
spec anyway, and the rejection closes that spec for good.

## The last step is yours

Two acts put real money in front of the venue, and both are deliberate:

1. `trading_arm` switches the account to live, with a per-order and a daily
   cap. Arming alone moves nothing: a paper run on an armed account stays
   paper.
2. `pipeline_promote(candidate_id, phrase="PROMOTE TO LIVE", capital_usd=…)`
   starts a live run for a `live_ready` candidate, with no more than the
   policy ceiling (default $100).

The paper run keeps running beside the live one, so the live fills always have
something to be compared against.

## Why paper incubation is not evidence

Two weeks of paper profit and loss is noise, and the pipeline does not read it
as performance. The evidence is the holdout. Incubation catches the mechanical
failures a backtest cannot: a spec that never sees the bars it expects, orders
below the venue minimum, a drawdown on the first weeks of real prices.

## The rules in force

`pipeline_status` returns them. The operator of a server can change them.

| Rule | Default |
|---|---|
| Holdout spent automatically once the gate passes | yes |
| Paper capital | $1,000 |
| Paper drawdown that halts the run | 10% |
| Minimum paper incubation | 14 days, 4 fills |
| Paper return floor at the end of incubation | −5% |
| Largest live promotion | $100 |
| Live drawdown that halts the run | 10% |
| A submission with no backtest is dropped after | 7 days |