Reference

Finding format

A finding is one prioritised, explained recommendation about one database. This page documents the shape findings take — their fields, the severity scale, and the status lifecycle — so you can filter, triage, and integrate them. It describes the output contract, not how findings are produced.

How findings are delivered

Workbench UI — the findings list and detail view, with inline chart blocks where a finding has one attached.
findings.json — the machine-readable form, for piping into your own tooling.
summary.txt — a plain-text digest for a quick human read.

PDF export is on the roadmap, not yet available. Some license tiers list a pdf_reportsentitlement that reserves the capability, but no PDF generator ships today — don't build a workflow around PDF output until it's released.

A finding's fields

Each finding carries:

{
  "id": "...",                         // stable identifier
  "database": "...",                   // which registered database it concerns
  "title": "Sequential scan on large table",
  "severity": "medium",                // critical | high | medium | low | info
  "status": "new",                     // triage state (see below)
  "summary": "...",                    // what it is, in plain language
  "confidence": "...",                 // how strongly it is asserted
  "first_seen": "...",                 // when it first appeared
  "last_seen": "...",                  // most recent evaluation that raised it
  "recommendations": [ ... ],          // concrete, ordered next actions
  "evidence": [ ... ]                  // supporting material the finding cites
}

recommendations are the actionable core — ordered, concrete steps. evidence is the supporting material a finding cites so you can verify it before acting.

Severity

Five levels, highest first: critical > high > medium > low > info. Use severity to filter the list to what warrants attention now (for example, severity ≥ medium).

Status lifecycle

Every finding moves through a closed status state machine as your team works it:

new ──▶ acknowledged ──▶ in_progress ──▶ resolved
  └───────────────────────────────────▶ ignored

new — surfaced, not yet triaged.
acknowledged — seen and accepted as real.
in_progress — being worked.
resolved — addressed.
ignored — deliberately not actioned.

Status updates are operator-driven and audited. When you connect a ticket system, pushing a finding opens a tracked issue without leaving the same lifecycle.

For how to read and act on a finding end-to-end, see the evaluation guide.