Evaluate Expression

How it fits

Typical backends

Caveats

• Compatibilityexpression runs through a restricted interpreter, not raw Python: lambdas, imports, attribute-reflection helpers, and method calls on string literals are blocked, so use comprehensions and temporary variables instead.
• Hard constraintThe script must produce a value via a trailing expression, a return, or an assignment to result or output; a side-effect-only script fails the call with a did-not-produce-a-value error. An interpreter error aborts the whole call as a runtime error carrying the error trail.
• I/O contractA record input arrives as a mapping keyed by field name, so its fields are read as x0['point'] rather than x0.point, and a named type is a record of its declared fields rather than a positional list. When a script fails, the error names the shape of every bound input alongside the interpreter trail, so the accessor that would have carried the value is visible from the message.
• OrderingInputs bind positionally as x0, x1, ... in upstream declaration order; re-wiring upstream silently re-binds the symbols and the script cannot detect the swap.
• State lifetimeThe script-visible state dict and message counter are per replica, so a horizontally-scaled deployment splits state across replicas with no synchronisation.
• I/O contractThe wall-clock helpers are the component's clock at evaluation time, not derived from upstream message timestamps, so they drift relative to data-time backends.
• I/O contractThe output type is unconstrained — whatever the script returns becomes the output — so the catalogue cannot type-check the consumer and mismatches surface downstream rather than here.
• State lifetimeexpression is re-read on every message, so live edits take effect immediately without a redeploy.