Triage States & Lifecycle

Every finding has a status. Most transitions are explicit (a user marks something false-positive); a few — auto_fixed, the resurrection of an auto_fixed row, the verification or disproof of a fix_claimed row, and the lazy-revert of an expired ignored snooze — are applied by Vygl automatically when a scan re-detects (or stops re-detecting) a fingerprint.

Statuses

Status	Meaning
open	New finding, not yet triaged. The default state when a finding first appears.
acknowledged	Triaged but not yet fixed — “we see it, working on it”. Auto-fix can still close this row.
fix_claimed	Falsifiable assertion the issue is fixed. The next full scan that doesn’t re-detect the fingerprint promotes the row to auto_fixed; a re-detection flips it back to open with claim_disproven_at set.
fixed	Manually marked fixed. Sticky — re-detection does not reopen this row.
false_positive	Rule fired incorrectly. Sticky across rescans.
ignored	Accepted risk or deliberate suppression. Sticky, but supports a snooze (see below).
suppressed	Finding-specific suppression with a full audit trail. Used by CVE Watch and any UI/API caller that wants the suppression visible in the dashboard.
auto_fixed	Vygl detected the fingerprint disappeared from a full scan. Resurrects to open automatically if it reappears.

There’s no enforced workflow DAG — any user-settable status can transition to any other. Common paths:

• open → acknowledged — “I see it, will fix later”.
• open → fix_claimed — “I’ve shipped a fix; verify on the next scan”.
• open → false_positive — “Rule is wrong”.
• open → ignored (with snooze) — “Revisit in 30 days”.
• acknowledged → fixed (or auto-promoted to auto_fixed) — “Done”.

Triaging a finding

From the finding detail page:

1. Click the Status dropdown.
2. Pick the new status.
3. Optionally add a reason — recorded on the row and on the audit log entry.
4. Save.

Bulk triage works the same way from the Findings list — select rows, use the bulk-action dropdown.

The fix-claim lifecycle

fix_claimed is a “claim” of a fix that the next scan can verify or disprove:

• Claim is verified. A full_scan runs, the fingerprint is missing, the row promotes to auto_fixed with metadata.claim_attribution (who claimed, when, which scan verified) and a finding.status_change.claim_verified audit entry.
• Claim is disproven. A scan re-detects the fingerprint, the row flips back to open, claim_disproven_at is set, and a finding.status_change.claim_disproven audit entry is emitted. The dashboard’s “Disproven claims” tile keys off this column.

Use fix_claimed rather than fixed when you want the platform to verify your assertion rather than trust it.

Cross-branch sticky triage

When a fingerprint first appears on a new branch, Vygl seeds it with the most recent sticky decision (false_positive, ignored, fixed, suppressed) and AI verdict from any sibling-branch row. So if you triaged a finding as false_positive on main, the same finding’s first appearance on a feature branch arrives pre-decided — no second triage required.

Snoozable ignore

ignored can be temporary. When marking ignored, optionally set an expiry via API:

• suppression_days — 1 to 3650.
• suppression_expires_at — explicit ISO datetime.
• Both null (default) — permanent.

Reads use a computed effective status: an expired ignored row resolves to open immediately for query and display, even before any scan touches it. The DB row is physically flipped back to open on the next scan that re-detects the fingerprint (or the next CVE Watch ingest), and that flip emits a finding.status_change.suppression_expired audit entry. There’s no wall-clock background sweeper today — the row stays ignored in storage until something writes to it.

What “fixed” really means

There are two paths to a fixed status:

• fixed — explicit, manual, sticky. If the same fingerprint reappears later, the row stays fixed. Use when you want re-detection to be a no-op (or use acknowledged if you’d rather have it reopen).

• auto_fixed — automatic, resurrects on re-detection. If the fingerprint reappears, the row flips back to open with reason "Re-detected by scan {short}", prior triage and AI verdict preserved on the row’s metadata. The audit trail records finding.status_change.auto_fixed_resurrected.

  See Auto-Fix Reconciliation for the full rules.

Status changes are audited

Triage emits finding.triage and finding.bulk_triage audit entries with actor, timestamp, prior status, new status, and reason. System events emit dedicated actions: finding.status_change.claim_verified, finding.status_change.claim_disproven, finding.status_change.auto_fixed_resurrected, and finding.status_change.suppression_expired. False-positive abuse (mass-marking findings FP to silence them) is trivially detectable by querying the audit log for those actions.

Required scope

Triage endpoints accept either triage:write or the broader write scope. The read scope can view findings but not modify state. See API Keys.