Anomaly

​

Inputs

• Data in — value to pass through. Optionally captured into the anomaly’s params under Param key so consumers can report it back.
• Entity ID — optional Twine-internal UUID of the entity the anomaly is about. Populates the row’s entity_id column for the auto-resolve sweep and rich entity rendering in the UI.
• External ID — optional source-system identifier for the entity. Always populate this in convert_from_system flows: at that pipeline stage, the only id available is the remote one.

​

Outputs

• Result — the input value, unchanged.

​

Schema

• Code — short stable identifier (e.g. missing_phone).
• Severity — info / warning / critical. Influences how consumers triage and surface the anomaly.
• Message — human-readable description shown to the customer. In flow mode, {assign} / {assign.nested.path} tokens are interpolated from the run’s assigns when the anomaly is recorded (same syntax as Flow Log).
• Param key — optional. In data mode, captures the inbound value under this key so the message template can reference it. In flow mode it names an assign to capture (resolved like a {token}, nested paths allowed), recorded in the anomaly’s captured params — the input port carries no meaningful value in a flow, so the assign is the source.
• System integration — flow mode only: the tenant integration the persisted anomaly row is scoped to. Required when the node runs in a flow; ignored in data (property-mapping) mode.

​

Ports