Issue confidence & dedup
How BugBrain fingerprints each issue with a signature to deduplicate the same bug across runs, scores it with a confidence oracle, and drops low-confidence noise below a keep-floor — so you prioritize by confidence and severity.
A test tool that reports every flicker as a separate bug quickly becomes noise you stop reading. BugBrain is built to do the opposite: collapse the same problem into a single, well-evidenced issue, attach a measure of how sure it is, and quietly drop the things that aren't worth your time. The result is an issue list you can actually trust and triage.
Signatures: one bug, one issue#
Every issue BugBrain creates gets a signature — a fingerprint computed from the essence of the problem (what broke, where, and how). The signature is what lets BugBrain recognize that a bug it sees today is the same bug it saw last week.
When a new finding matches the signature of an existing issue, BugBrain doesn't create a duplicate. Instead it folds the finding into the existing issue and increments an occurrence count. So a recurring problem shows up as one issue that says "seen 12 times across 5 runs," rather than twelve near-identical entries cluttering your list.
This matters in two directions. It keeps the list short and readable, and the occurrence count itself becomes a signal — a bug that keeps recurring across runs is clearly real and persistent, which helps you decide what to fix first.
Confidence: how sure is it?#
Recognizing a duplicate is one thing; deciding whether a finding is worth reporting at all is another. For that, an oracle assigns a confidence score to each finding — an estimate of how likely it is to be a genuine, reproducible bug rather than a transient glitch or a false alarm.
Confidence rises with stronger and more consistent evidence: the problem reproduced, the symptoms are clear, the signals line up. It falls when the evidence is thin, ambiguous, or one-off.
Findings whose confidence sits below a keep-floor are dropped as noise — they never make it onto your issue list. This is deliberate: it's far better to surface eight issues you can trust than fifty you have to manually sift. The keep-floor is what protects the signal-to-noise ratio of everything you see.
Putting it to work: confidence + severity#
Each issue carries both a confidence score (how sure BugBrain is it's real) and a severity (how much it would hurt if it is). Use the two together to prioritize:
- High severity + high confidence — fix first. A serious problem that BugBrain is confident about.
- High severity + moderate confidence — investigate soon. Potentially serious; confirm it.
- Low severity + any confidence — schedule it. Real but minor.
Severity tells you how much a bug matters; confidence tells you how likely it is to be a bug at all. Reading them as a pair turns a long list into a clear order of attack.
Trust the occurrence count
An issue with a high occurrence count has reproduced again and again across runs — that's strong, independent evidence it's real. Pair a rising occurrence count with high severity and it goes to the top of the queue.
Related#
Frequently asked questions
Why don't I see the same bug listed ten times?
Each issue gets a signature — a fingerprint of the problem. When the same signature shows up across runs, BugBrain collapses it into one issue with an occurrence count instead of creating duplicates.
What is the confidence score on an issue?
It's an oracle's estimate of how likely the finding is a real, reproducible bug rather than noise. Higher confidence means stronger, more consistent evidence.
What happens to low-confidence findings?
Findings below a keep-floor are dropped as noise so your issue list stays trustworthy. Only findings the system is reasonably sure about are surfaced.
How should I prioritize issues?
Combine confidence and severity. A high-severity, high-confidence issue is your top priority; a high-severity but lower-confidence one is worth a look; low-severity, lower-confidence ones can wait.