User indicators

The user category is where indicators you load yourself land: it ships EMPTY, by design. Of the 171 built-in indicators, none sits here, and the table below is empty on purpose: the exporter renders every vike_indicators::Category variant, empty ones included, so a category that vanished for having no rows can never pass for one that was never declared.

An indicator you write — in Rhai, through the Studio, or as a Rust type registered with IndicatorMeta::user — is classified User and appears in the catalog beside the built-ins with the same parameter surface: name, default and sweep range. Two pages walk the two paths: writing an indicator covers the Rhai form and its param() declarations; loading indicators covers where a user indicator lives on disk and how the Studio and the CLI pick it up.

Every built-in indicator carries one guarantee: its streaming on_bar path equals its batch vectorize kernel bit-for-bit, proven by the parity gate in the product tree (crates/vike-indicators/tests/parity.rs). The exceptions are declared, not discovered: an indicator marked batch-only reads future bars in its batch form, so its streaming value is a causal best-effort that is NaN at the unknowable tip, and the gate skips it by name.

A user indicator is outside that gate: the parity harness runs over the built-in registry, so the streaming-equals-batch property is yours to test for your own kernels — the research tree shows the harness a study can reuse for exactly that.

Indicators

Using them

In a Rhai strategy an indicator is a call by id with its parameters in registry order — sma(…) — and the Studio's indicators pane offers the same catalog with each parameter's sweep range pre-filled from the defaults below. From Rust, vike_indicators::make(id) builds the default instance and make_with(id, &params) the parameterised one; both consult the same registry row this table was rendered from.