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.
- Measured
- Measured
- Measured
- Measured
- Measured
- Measured
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.
Open full size6 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
Signals
Logic
Models
Search & Eval
Output
The custom family carries no section and holds 2 entries, described further down.
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.
Open full sizeValidation 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.