Campaigns, runs and scans

Three words name how work runs. They are not interchangeable.

Scan

A scan is a bounded connector pass against one asset. It is the smallest unit of work: one asset, one set of connectors, a defined perimeter.

Run

A run is one asset scan, identified by a run_id. Prefer "run" in anything new.

Campaign

A campaign is a run of the agentic pentest pipeline - the LLM planner drives a sequence of phases against the asset. A campaign and a run share an id field (campaign_id == run_id on the shared activities); that is an implementation artefact, not a meaning.

Phases

A campaign moves through phases, each one step of the runtime chain:

recon → map → discover → scan → inject → web_audit
→ api_abuse → protocols → bola → bfla → sast → reattack

Connectors and checks

• A connector wraps one open-source tool and emits raw results. It never produces a finished finding - normalisation is central, by design.
• A check is the customer-facing catalogue row describing what a connector proves about an asset. A check's execution is success, error, skipped, unavailable or needs_authorization. unavailable means the tool never ran and must not be read as a clean result.