Findings & Results
A finding is the result a detector yields: one signal, raised on one asset. It’s the unit you triage, filter, and investigate. This page covers everything a finding carries — its fields, its priority, its confidence, and how it lives across repeated scans.
Almost every finding is detected — a detector read the content and judged it. One kind is asserted instead: a Tag records a fact a Custom connector already knew, without reading anything. Once raised, the two are the same object and share everything below.
Anatomy of a finding
Every finding records what was found, where, how sure the detector is, and how serious it is. The key fields:
| Field | What it tells you |
|---|---|
| Detector | Which detector raised it — a pre-built type, or your custom detector’s name. |
| Finding type | The specific signal, e.g. an API key, a credit-card number, a policy match. |
| Category | The broad family the signal belongs to (secrets, PII, security, …). |
| Priority | How much it matters — Critical to Routine (see below). Stored as severity. |
| Confidence | How sure the detector is, from 0 to 1 (see below). |
| Matched content | The exact text or value that matched. |
| Redacted content | A safe-to-show version with the sensitive part masked. |
| Context | The surrounding text before and after the match, for quick judgement. |
| Location | Where in the asset it sits (e.g. line, field, or column). |
| Metadata | Extra detector-specific details about the match. |
| Status | Where it is in its lifecycle — Open, Resolved, and so on (see below). |
Because each finding is attached to an asset, it also inherits that asset’s name, link, and metadata — so you always know which item, in which source, produced it.
Sensitive matches stay protected. Findings keep a redacted version of the match so you can review and triage without re-exposing the secret or personal data that was found.
Priority levels
Every finding is assigned a priority by the detector, based on what matched. Priority is how you focus on what matters first — you can sort and filter by it everywhere.
Priority is not a danger scale. A finding is critical because it is important to the question you are asking, not because it is hazardous — a company approaching insolvency, a shipment routed to the wrong address, and a leaked credential can all be critical, for entirely different reasons.
| Priority | Meaning | Example |
|---|---|---|
| Critical | Central to the question — look here first | A company entering insolvency proceedings; a live credential |
| High | Strongly relevant — worth acting on | A shipment addressed outside its expected region |
| Medium | Relevant, or a deviation worth reviewing | A value outside its usual range |
| Low | Weak signal, or context rather than a lead | A near-match on a watched term |
| Routine | Recorded for completeness | A tag applied by a custom detector |
The stored values are unchanged: the API, CLI, MCP tools and exports still use
CRITICAL,HIGH,MEDIUM,LOWandINFO, on a field namedseverity. Only what those levels mean, and the words the app shows for them, changed — there is noROUTINEvalue to send.
Confidence
Alongside priority, each finding carries a confidence score from 0 to 1 showing how certain the detector is about the match:
- 1.0 — the detector is fully confident (typical of exact pattern matches). A tag finding is always 1.0: it was asserted, not inferred, so there is nothing for a score to express.
- Lower scores — the signal is more ambiguous and may deserve a human check.
Priority and confidence answer different questions: priority is how much does this matter?, confidence is how likely is it real? A high-priority, low-confidence finding is worth a quick look; a high-priority, high-confidence one is worth acting on.
The finding lifecycle
Findings persist across scans. Rather than creating duplicates each run, Classifyre tracks the same finding over time and updates its status and history — giving you a complete audit trail.
Statuses you control
| Status | Meaning |
|---|---|
| Open | Newly detected, not yet reviewed. Shown as open. |
| False positive | Reviewed and judged not relevant to the question. Shown as not relevant. |
| Resolved | Dealt with — the thing it pointed at is settled. Shown as resolved. |
| Ignored | Seen and deliberately parked. Shown as set aside. |
History recorded automatically
Each finding keeps a timeline of what happened to it:
| Event | When it fires |
|---|---|
| Detected | First time it appears |
| Re-detected | Still present in a later scan |
| Resolved | No longer present after a scan (auto), or marked by you |
| Re-opened | Returned after having been resolved |
| Status / priority changed | You updated it manually |
Your decisions stick. When you mark something a false positive, ignored, or resolved, later scans respect that — your manual judgement is never silently overwritten.
From findings to investigations
Findings are evidence. On their own they’re a list; their real value comes from working them:
- Investigations — group related findings into inquiries and cases with hypotheses and evidence.
- Duplicate review — connect findings that share identity into duplicate and similarity clusters.
- Autopilot — let AI agents open inquiries, build cases, and draft hypotheses from new findings automatically.
- Scans — the full mechanics of how findings are detected, tracked, and auto-resolved across scans.
Detectors, end to end
| Page | |
|---|---|
| Overview | Pre-built and custom detectors at a glance |
| How Detectors Work | Running, routing, and per-source setup |
| Findings & Results | What detectors produce (you are here) |
| Pre-built Detectors | The ready-made packs |
| Custom Detectors | Build your own |