# 667 catalogue entries, including 175 roadmap entries The census contains 667 family-and-name entries across 28 families. It marks 175 as roadmap; the other 492 carry the existing non-roadmap classification. This census is not a fresh execution audit. 667 nodes in the shipped catalogue Measured: 2026-09-21 492 nodes validated by an executable check Measured: 2026-09-21 175 nodes marked for later work Measured: 2026-09-21 379 nodes with user-settable parameters Measured: 2026-09-21 667 validated plus roadmap, equal to the total Measured: 2026-09-21 0 roadmap nodes with no published limitation Measured: 2026-09-21 A node is in one of two states: validated by an executable check, or marked for later work with its limitation written. The two counts add up to the total, and an automated check fails the build if a node falls between them. ## The family and the name make the key A catalogue entry carries a family, a name and a one-line note. The counting key is the pair family/name, so the same name under two families counts as two entries, and a rename produces a new identity. Of the 667 entries, 379 expose at least one parameter. Parameter blocks define settings and search ranges. Entries without parameters take their behaviour from their implementation and graph inputs. [Screenshot: The recorded strategy in the current visual builder: connected inputs, trading rules and validation nodes.](https://stochastly.com/screenshots-current/docs-nodes--a-strategy-made-of-connected-nodes.png) The recorded strategy in the current visual builder: connected inputs, trading rules and validation nodes. ## 6 sections, 28 families, and the custom one The catalogue groups its families into sections, and the app draws its palette from that grouping. Each line gives the validated count over the family total, on 2026-09-21. Inputs - Data & Splits: 10 validated of 19 - Macro & Alt-Data: 4 validated of 4 - Timeframe: 3 validated of 5 Signals - Core Signals: 24 validated of 36 - Breakout: 9 validated of 9 - Mean Reversion: 10 validated of 12 - Trend & Momentum: 14 validated of 17 - Price Action & Patterns: 11 validated of 12 - Volume & Order Flow: 10 validated of 10 Logic - Entry Filters: 42 validated of 43 - Cost & Slippage: 17 validated of 26 - Position Sizing: 4 validated of 6 - Stops & Exits: 0 validated of 13 - Prop-Firm Rules: 13 validated of 17 Models - Regime & Labeling: 7 validated of 18 - Machine Learning: 24 validated of 38 Search & Eval - Optimisation & Portfolio: 33 validated of 44 - Monte Carlo: 22 validated of 23 - Synthetic Paths & Null Models: 16 validated of 55 - Validation & Metrics: 41 validated of 47 - Statistical Tests: 11 validated of 14 - Time-Series & Volatility: 13 validated of 17 Output - Run & Execution: 6 validated of 6 - Live Display: 6 validated of 6 - Analysis & Plots: 132 validated of 159 - Export & Codegen: 7 validated of 8 The custom family carries no section and holds 2 entries, described further down. Figure 1. The shipped catalogue, family by familyFilled bar: nodes validated by an executable check. Outline: the family total. Common scale across all 28 families, so the widths are comparable. Measured 2026-09-21. The gap between the two bars is where the work is, and it is concentrated: Synthetic Paths & Null Models (16/55), Analysis & Plots (132/159), Machine Learning (24/38), Stops & Exits (0/13) carry 53 % of it, on 4 of the 28 families. The rest of the catalogue sits at or near its own total. [Screenshot: Search the node catalogue by name, here for the Ridge regression model, before adding it to the strategy.](https://stochastly.com/screenshots-current/docs-nodes--find-a-node-by-name.png) Search the node catalogue by name, here for the Ridge regression model, before adding it to the strategy. ## Validation requires an executable result A node reaches the validated state when an executable check wires it and obtains two results that differ. Display labels such as live, ported or implemented do not establish that result. The split is recalculated from the shipped catalogue, so no published count is stored separately. The catalogue distinguishes six cases: ``` validated an executable check produces two different results roadmap the catalogue states what is still missing executable a matching kernel or function resolves; this is only a ceiling output the node displays, renders or exports declared inactive its family is announced in-app as not running label only declared implemented, but no matching function resolves ``` ## A badge carries what the node still lacks Each roadmap entry should name what it still lacks. Of the 175 entries marked for later work, 0 carry no reason; that count is recalculated from the shipped catalogue. A badge with no reason is a promise with no content behind it. The count goes on the page beside the others, at the same rank as the counts that flatter the product. ## Custom nodes run Python you wrote yourself The custom family runs a signal(df) function you author. The call goes through exec with the app's privileges. Withholding import names is a convenience, not a security boundary. A graph carrying custom code is confirmed in the interface before an autonomous run. The causality gate applies to it as well: run() is re-evaluated on truncated bars, so a signal reading the full series or a negative shift fails the gate. ## The shipped catalogue and the enriched one differ The counts above come from the catalogue inside the desktop build. A second catalogue enriches those entries at runtime and therefore lands on a higher figure. Both are correct on their own object, and the numbers published here describe the build. What a validated node establishes is bounded by the executable check behind it, and the validation protocol is described under Research. --- Source: https://stochastly.com/docs/nodes