Skip to main content

​
Two kinds of result

A workflow run produces results in two places, and it’s worth keeping them straight: The run itself is a record — status, per-step timings, which agents ran. The results are what the agents recorded while running.

​
Findings

The primary output. When an agent confirms a vulnerability it records a finding with the affected file and symbol, its reasoning, and provenance back to the run and the detection that produced it. Findings are deduplicated per project, so a recurring issue updates in place rather than accumulating duplicates across runs.

​
Patches

When patch generation is part of the chain, an agent that fixes a finding records the resulting diff against that finding. Patches are verified before they’re recorded, not proposed speculatively: the agent edits the file, re-runs the detection to confirm the match is gone — for policy detections, an independent read-only verifier judges the result — and only then captures the diff. That’s why a finding’s suggested fix can open a pull request directly.

​
The artifact model

Underneath findings and patches, Console stores results as artifacts. An artifact has:
  • A kind — what type of thing it is
  • A summary — a short description
  • Files — one or more, each with a path, a content type, and its contents
  • Subjects — optionally, the findings the artifact addresses
This model is deliberately open-ended: an artifact is a set of files an agent produced, with provenance and optional linkage to the findings it relates to. Nothing about it is specific to security. A risk assessment, a compliance report, a threat model, a generated test suite are all describable in the same shape. Console ships several kinds of its own — findings and patches among them — but your own agents can define and record their own, with no setup outside the agent’s own definition. See defining your own kind for how to declare one.
A kind’s shape is fixed once it’s registered. Saving the identical shape again is a no-op; changing it is rejected outright, so a kind never silently reinterprets artifacts you’ve already recorded under the old shape. If a kind’s shape needs to change, give it a new name.

​
Getting results out

Recording a result and delivering it are different steps. A run’s results sit in Console until an output pushes them somewhere: Both act on the pull request that triggered the run, so they’re skipped on manual runs.
These two destinations are the whole set today. There’s no built-in delivery to ticketing systems, chat tools, or arbitrary webhooks, and no general outbound-write tool — web_fetch performs reads only. If you need results elsewhere, read them from Console rather than expecting a workflow to push them.

​
Inspecting a run’s results

Open the run from Runs or from View runs on the workflow. You’ll see the step chain with per-step status and duration, the findings the run produced, and each output with its delivery status. See running a workflow.

​
Next steps

Findings

Review results and accept fixes.

Outputs

Deliver results to pull requests.