Anomaly detection
Train a detector and make threshold selection an explicit workflow decision.
collect signalsbuild featurestrain detectorscore validation datachoose thresholdpublish detector
Activity responsibilities
| Activity | Responsibility |
|---|---|
collect-signals | Execute the collect signals stage and publish its declared outputs for downstream activities. |
build-features | Execute the build features stage and publish its declared outputs for downstream activities. |
train-detector | Execute the train detector stage and publish its declared outputs for downstream activities. |
score-validation-data | Execute the score validation data stage and publish its declared outputs for downstream activities. |
choose-threshold | Execute the choose threshold stage and publish its declared outputs for downstream activities. |
publish-detector | Execute the publish detector stage and publish its declared outputs for downstream activities. |
Inputs
- Signal dataset
- Feature specification
- Operating-cost policy
Outputs
- Detector
- Threshold
- Validation report
Provenance to preserve
- Time window
- Feature code
- Threshold rationale
Runnable example
This is the complete checked-in bundle for this pattern. Download the environment, scope, topology, workflow, input, container recipe, runner, and validation contract from this page before executing it.
Verified local execution
These captures and the output manifest were produced by the fixture's local Docker run and validator. They are published with the same bundle as the runnable files.



Execution considerations
Preserve time-based splits to prevent leakage. Feature construction may require more data movement than training.
AkôFlow boundary: the engine schedules, deploys, executes, transfers data, and records evidence. The ML or agent framework remains an implementation choice inside each activity.