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.
Today the only artifact kind produced in practice is the patch. The model is general, but patch generation is the one producer that’s wired up. Treat the broader shape as where this is heading, not as a set of features to build against right now.

​
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.