> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pipefort.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Finding triage & new findings

> Track findings across scans, see what's new, and dismiss what doesn't apply.

Re-scanning a repo used to re-report everything, every time — with no way to
tell a fresh problem from the one you looked at last week, or to silence a
finding you've decided to live with. Pipefort now tracks every finding's
**identity across scans** and lets you **triage** it.

## Finding identity

Each finding gets a stable **fingerprint** built from what the finding *is*
(rule, file, and the specific step/action involved) — deliberately not its line
number, so edits that shift a finding down a file don't change its identity.
The fingerprint feeds a per-repo ledger recording when each finding was
**first seen**, **last seen**, and when it **stopped appearing** (resolved).

Two things surface from the ledger:

* **NEW badges** — findings first seen by the latest scan are marked `NEW` on
  the repository page, the latest-scan summary shows an "N new" chip, and the
  dashboard's Total findings card notes how many findings are new across your
  latest scans.
* **Resolution tracking** — a finding that disappears from a scan is marked
  resolved; if it comes back later it is *not* counted as new (the ledger
  remembers it).

## Triage

Expand any finding on the repository page and pick:

| Action             | Meaning                               |
| ------------------ | ------------------------------------- |
| **Dismiss**        | Not relevant here; hide it.           |
| **Accept risk**    | Real, but tolerated deliberately.     |
| **False positive** | The detection is wrong for this case. |
| **Reopen**         | Undo any of the above.                |

Triage is keyed to the fingerprint, so it **survives re-scans** — a dismissed
finding stays dismissed no matter how many times the repo is scanned (manually
or via [monitoring](/webapp/monitored-repos)).

<Note>
  **Posture counts exclude triaged findings.** From migration `0009` on,
  `scans.counts` rolls up **open** findings only. Dismissing a finding
  immediately recomputes the latest scan's counts, so the dashboard donut,
  trend chart, and repo table reflect your real, actionable risk. The finding
  row itself is always persisted — toggle **Show triaged** on the repository
  page to see everything.
</Note>

## Interaction with rule settings

[Rule settings](/webapp/rule-settings) and triage solve different problems:
disable a **rule** when it never applies to you (it stops being detected at
all); triage a **finding** when the rule is right in general but this one
occurrence is handled. A finding whose rule is later disabled simply stops
appearing and is marked resolved.

## CLI parity

The CLI's SARIF output (`-o sarif`) carries the same fingerprint as each
result's `partialFingerprints`, which GitHub code scanning uses to track a
result across commits instead of closing and reopening it when line numbers
shift. Triage states themselves are a database-backed web-app feature (GitHub
code scanning has its own dismissal flow for the Action path).