Outliers
Flag outliers before deciding whether they are errors
An unusual value may be a typo, a rare but valid event, or the most important observation in the file. The current workflow supports deterministic IQR flagging so outlier candidates stay visible rather than being silently changed or removed.
Use a clear, parameterized detection rule
The supported outlier operation uses the interquartile range and an editable multiplier to identify candidates. Its action is flagging, not deletion. The plan shows the target column, rationale, risk, and preliminary impact before confirmation.
Because the operation is deterministic, the same numeric input, parameters, and engine version produce the same flags. The completed report can show the number of rows flagged and any warnings returned by execution.
Do not confuse detection with treatment
Winsorization, clipping, replacement, and row deletion answer a different question from detection. Those treatments can distort a distribution or remove legitimate edge cases, so they need distinct schemas, risk rules, impact reporting, and Worker support.
The development preview can demonstrate how a future advanced rule might explain those choices, but the real product does not send winsorization or delete-outlier operations to the Worker.
- Supported now: IQR candidate flagging
- Editable now: multiplier within the validated schema
- Preview only: winsorize, clip, or delete candidates
- Always review domain meaning before treatment
Preserve context through report provenance
The run report connects flagged counts to a frozen rule snapshot, source hash, output hash, and engine version. That record helps distinguish a data change from a change in thresholds or tooling.
Future recipe versions will need to keep outlier parameters immutable and re-check target types when schemas drift. Until that backend exists, recipe reuse and mapping remain explicitly marked coming soon.