Anatomy of a card

What is inside a card, and how the manifest becomes the thing you see on the canvas.

The folder

card.json      identity, ports, parameters
run.py         the implementation
panel.html     optional custom editor
icon.svg       optional

The manifest draws the card

There is no separate interface to build. A parameter declared as float with a unit renders as a numeric field with that unit; an enum renders as a dropdown. Declaring it is what makes it appear.

The full schema is in the SDK reference.

The implementation

One function, run(ctx). The context carries the resolved inputs and parameters, plus helpers for building outputs and reporting progress.

def run(ctx):
    x = ctx.inputs["in"]
    low  = ctx.params["l_freq"]
    high = ctx.params["h_freq"]
    return { "out": x.filter(low, high) }

Why the gears view matters

The card face shows what you set. The gears view shows what the software resolved from it: the filter order, the number of taps, the actual transition width. Those are the numbers you need when a reviewer asks what you did, and they are usually the ones nobody can find.

Execution phases

Each card declares a phase, which determines ordering and caching. Loading, spatial preprocessing, temporal preprocessing, epoching, analysis, visualisation. The engine sorts the graph by phase before running it, so a filter cannot accidentally run after epoching because of where it sits on screen.