Skip to main content

Anomaly detection

Train a detector and make threshold selection an explicit workflow decision.

Anomaly detection

Activity responsibilities

ActivityResponsibility
collect-signalsExecute the collect signals stage and publish its declared outputs for downstream activities.
build-featuresExecute the build features stage and publish its declared outputs for downstream activities.
train-detectorExecute the train detector stage and publish its declared outputs for downstream activities.
score-validation-dataExecute the score validation data stage and publish its declared outputs for downstream activities.
choose-thresholdExecute the choose threshold stage and publish its declared outputs for downstream activities.
publish-detectorExecute 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.

Anomaly detection workflow execution evidence
Workflow evidence
Anomaly detection execution evidence
Execution evidence
Anomaly detection output evidence
Output evidence
Open verified output manifest ↓

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.