Detection History

Every finding carries two parallel histories. Detection history records which scans saw the fingerprint and how (new / recurring / auto_fixed). Status-transition history records every triage action — human and system — with actor, prior status, new status, and reason.

What’s tracked

Per finding:

First detection — first_seen_scan_id is set on initial insert and never overwritten. This pointer is per (project, branch, fingerprint) row, so a fingerprint first seen on feature-x then reaching main will have a separate first-seen on the main row.
Re-detections — every subsequent scan that contained the same fingerprint, joined via the scan_findings table, with detection ∈ {new, recurring, auto_fixed} recording how the scan saw the row.
Status transitions — every status change with actor, timestamp, and reason. Includes both human triage (finding.triage, finding.bulk_triage) and system events (finding.status_change.{claim_verified, claim_disproven, auto_fixed_resurrected, suppression_expired}).
AI verdict (current) — the latest verdict, confidence, and reasoning live in metadata.ai_verification. Re-running AI verification overwrites the prior verdict — it isn’t versioned.

Reasons in lieu of comments

Per-finding comments aren’t a feature today. Each triage action accepts an optional status_reason string instead — recorded on the row itself and on the audit-log entry. The status-history view renders the reason next to each status change, making it the conventional place to leave triage context like:

“Vendor patch ETA mid-May, accepting until then” — context for acknowledged.
“WAF rule deployed, no code change needed” — explanation for false_positive.
“Tracked in JIRA-1234” — link to external work.

status_reason is updated on each new triage rather than appended to. Use the audit log if you need to read the full sequence of reasons over time.

Where to find it

On any finding detail page:

The History section shows scan-by-scan detection with branch and commit SHA per scan.
The Status history section reconstructs status transitions from the audit log, including system events.

For programmatic access:

GET /api/v1/findings/{id}/history — returns the scan-detection event stream from the scan_findings join (detection ∈ {new, recurring, auto_fixed}).
GET /api/v1/findings/{id}/status-history — returns the audit-derived status-transition stream.

What history doesn’t have (yet)

Per-finding threaded comments — use status_reason for now or link to an external tracker.
AI verdict versioning — only the latest verdict is kept; re-verification overwrites prior verdicts.
Full-text search across reasons.