---
name: using-sonar-workflow-infrastructure
description: Admin-only legacy reference for understanding catalog workflow definitions. Use operate-sonar-recon for accepted bounded recon; use explore-target-assets for reads.
category: pull
---

# Running distributed scans with Sonar

Sonar ships a catalog of ready-made workflows — a workflow is a DAG of shell-command steps
the engine runs across many workers. This reference is for authorized internal administrators.
Astrix authors complete documents with author-sonar-workflows and operates accepted recon through
operate-sonar-recon. Coordinators and pentest agents must not use this as scan control.

## Inspect a provided workflow

1. `list_workflows` → inspect the workflow whose job matches (subdomains, http-paths, tech, ports, …).
   Browse the catalog for the closest fit; there is one for most common recon jobs.
2. `get_workflow { id }` → inspect the declared inputs, graph, input query, output tables, and
   routing. Do not treat any input as permission to launch.
3. Do not launch from this legacy reference. The durable control plane must supply the immutable
   workflow version, explicit expected manifest, correlation lineage, and command hash.
4. Poll only through the authorized operator/control-plane runbook.
5. Read only frozen, finalized results with the returned revision and opaque cursor.

## Understanding a workflow definition

`get_workflow` (and `export_workflow`) return the full definition so you can judge what a workflow does before running it. A workflow is a **DAG of steps**; each step runs one shell command on a worker, and later steps consume earlier steps' output. The fields that matter when reading one:

- **`steps[]`** — the ordered work. Each step has a `name`, the `command` it runs, an `executionLocation` (which worker pool, e.g. `Vps` / `GitHub`), and `targetTags` (which workers may pick it up).
- **`dependencies`** (per step) — the DAG edges: which step must finish first, and the `dependencyType` — `All` waits for the whole upstream set; `Single` runs once per upstream item (fan-out).
- **`inputSource` / `inputSql`** — where a step gets its input set. An `inputSql` step is fed the rows its SQL selects (e.g. in-scope domains); this is what scopes a run to your target.
- **`saveToDb` / `outputTable`** — whether a step persists its results and to which asset table (`domains`, `ports`, `http_paths`, `technologies`, …). The `saveToDb` steps tell you what the run produces — and therefore which `list_*` tool to read afterward.
- **declared inputs** — distinguish required typed targeting parameters from controlled secret
  references. Never place credentials in a document, command, log, or result body.

Reading those answers the three questions worth asking before handing off: what it scans (its
`inputSql`), what it produces (its `saveToDb` tables), and what typed inputs the document declares.

If no catalog workflow fits, Astrix should author a complete document; this reference does not
authorize graph mutation or direct execution.