Engagements

An engagement is one run, carrying its own targets, its in-scope and out-of-scope lists, its rules of engagement and exactly one framework. A schedule can create engagements on a cadence; that recurring series is a campaign, and each engagement in it is the same object as one you submit by hand. This section covers engagements, however they were created.

Anatomy of a run describes what happens between submitting an engagement and downloading evidence. The pages here go a level down, into the decisions you make before a run and the failures you can hit during one.

Before the run¶

• Scope — the identifier kinds, how subdomain coverage works, how the in-scope and out-of-scope lists combine, and what overlapping them costs.
• Ownership verification — the two automated proofs, the attestation route for everything else, and the re-check that runs at every launch.
• Rules of engagement — what the agent is told, what the scope guard enforces, and where the two differ.
• Choosing a framework — which of the six frameworks decides the control identifiers on your report.

During and after¶

• Phases — the seven stages and what each produces.
• Running an engagement — submitting, the queue, and the live progress stream.
• Lifecycle — the statuses an engagement moves through and which of them are terminal.
• When a run fails — blocked launches, aborted runs, and what survives each.

Where to start¶

Register an asset and prove you own it before anything else. Nothing reaches the job queue until every target and every in-scope entry is covered by an asset whose proof holds at that moment, so Ownership verification is the page that most often stands between a new account and a first run. Your first engagement walks the whole sequence once, end to end.

What happens to a finished run's evidence — the hash chain, the seal, the exported zip and the share link — is the Evidence locker section.