Findings and severity

What a finding contains, and why there are only two severity levels.

A finding is a structured record, not a log line. Every reporter (pretty, json, sarif, and the database behind Studio) carries the same fields.

The shape of a finding

Field	What it holds
`ruleId`	The rule that fired: `BG-001`, `BG-002`, `BG-003`, or `BG-004`.
`severity`	`error` or `warning`.
`message`	The human-readable statement of what crossed.
`filePath`	The file containing the sink.
`line`, `column`	Where the sink is.
`snippet`	The sink expression itself, first line, trimmed.
`trace`	Provenance, nearest-to-sink first. Empty for BG-002.
`fingerprint`	Stable identity across line shifts: rule, file, and sink text.
`suppressed`	Present when a suppression applies, carrying its reason or a null reason.

Two severities, not five

Severity is error or warning. Nothing in between.

The reasoning is practical rather than principled: a level nobody agrees on is a level nobody acts on. If a report can say "medium", then every project redefines medium, and the word stops carrying information. Two levels can each mean one thing: this fails the build, or this does not.

What the trace is for

trace is the path the value took, ordered nearest-to-sink first. An empty trace is not a bug: BG-002 is about the shape of a Server Action's interface, not about a particular value's journey, so there is no path to report.

antra trace app/account/page.tsx:42 --format json

Fingerprints

A finding's fingerprint is derived from the rule, the file, and the sink text, not from the line number. That is what lets a baseline survive edits above a finding, and what stops every reformat from looking like a new violation.

Note

The database records findings across scans, so fingerprint is what makes "is this the same finding as last week" answerable. See antra query for reading that history directly.