Bring a model

Three ways in, one boundary

Each way in has one type, and the simulator and the trader import the same one. Below the entry point the sizing, limits and costs already exist. Trading anything other than a trend book still needs its trader integration built.

What a model declares, and what it sends

A model is registered once, and the registration is enforced on every batch. A registered model is one sleeve's combined forecast over one universe (a sleeve is one sub-strategy: a set of markets and the rule that forecasts them). The signals inside it are building blocks: their forecasts are stored as components and are not registered separately.

model_id         who it is
kind             forecast | target
origin           internal | external
owner
universe         a catalogue reference, not a list
clock            bar period and offset, UTC
horizon          matched exactly on every batch
scale            carver20 | sign | exp_return_bp
                 | zscore | native
forecast_scalar  a prior, and how fast to leave it
staleness        hold | decay | flatten | refuse
register_family  the group of related trials it is judged against
status           candidate → incubating
                 → live → retired

{
  "model_id": "your-model-daily",
  "model_version": "<hash of the registration>",
  "decision_at": "2026-10-16T21:00:00+00:00",
  "horizon": "1d",
  "scale": "zscore",
  "code_sha": "<the commit that produced it>",
  "forecasts": [
    {"instrument": "GOLD", "value": 1.3, "confidence": 0.6},
    {"instrument": "CRUDE", "value": -0.4, "confidence": null}
  ]
}

Rules the contract enforces

Each rule exists because a backtest can flatter a model without one.

• One scale below the boundaryforecasts capped at ±20

  Where forecasts are pooled and combined, every forecast is converted to one scale, capped at ±20 with an average absolute value of 10, the convention of Robert Carver's pysystemtrade. A sign signal maps to ±10 by a fixed rule, so sleeves that are live today size exactly as before. A model feeding the target-position engine can instead declare its own native units, which pass through unchanged and are not pooled.

• Normalise, scale, then capextremes cannot dominate

  Expected-return forecasts are divided by a volatility basis Nexus supplies, and one without it is refused. The scale is estimated from the cross-sectional median, with zeros dropped, and the scaled forecast is capped last.

• A scalar that cannot see aheadthe same rule in backtest and live

  pysystemtrade estimates its scalar on an expanding window and copies the first estimate back to the start of history, a small look-ahead it accepts. Nexus does not accept it. The scalar starts from a declared prior and moves toward the data as observations accumulate on the model's own clock. Each stored forecast records its raw value, the scalar used and the scaled result.

• Two clocks per forecastdecided, and available

  Staleness is measured from when the model decided. Causality is measured from when the forecast became available, which Nexus stamps: the time of receipt for an outside model; the end of the last input bar, plus that data's publication lag and a compute allowance, for an internal backtest. A book at time t reads only forecasts available by t, and fills come after that, plus execution lag.

• No restatementa forecast, once sent, stays

  The same model, time and market with the same value is a no-op. With a different value it is refused.

• Staleness declared, not discoveredrisk reduction always allowed

  Each model declares what happens when its feed goes quiet: hold, decay, flatten or refuse. Acting on that declaration is still to be built, and it must never block an order that reduces risk.

• Refused by nameand kept as data

  Unknown fields, unknown scales, markets outside the universe and the wrong horizon are refused, naming the field, and every refusal is stored.

• Every model countstrials, not just winners

  Each model that is incubated or goes live will add to its family's trial count, so a second model is judged against the bar the first one raised. That counting is in review.

Where it stands, 18 October 2026

The programme moved the internal models first, so that the contract was proved on the live book before anyone outside depends on it.

What plug-and-play still needs

A contract makes a model possible to connect. A quant still needs to be able to evaluate the platform in an afternoon, and that means a kit:

• A reference model. A small worked model that implements the contract end to end, to copy rather than read about.
• A sample dataset. History in the shape the model will see, to develop against before connecting.
• A conformance check. Run a model's batches against the contract offline and see every refusal, named, before the first live batch.
• Paper mode. The model runs against live prices with no capital, and its forecasts go into the same store as everyone else's.
• Attribution. Gross and net contribution per model, with the cost of its turnover charged to it. Nobody can be paid without it.

There is one more reason to want outside models. The due-diligence reviews cap at 4 because nobody but the builder has checked the work. A quant reviewing the harness their own model depends on would be the independent check the reviews cannot reach.