Every component carries a confidence: a calibrated belief in [0,1] that the component is really there and really identified as claimed. Two rules govern it:
  1. Detectors never set component confidence. A detector scores its own sighting. The engine assembles the component-level number from every sighting.
  2. Filtering is presentation, never assembly. --min-confidence trims what you see. It never changes what was merged, what evidence was recorded, or what any component scored.

​
How the engine assembles it

Confidence is a grouped noisy-OR over the occurrences behind a component. Three steps:
1

Group per detector and method

For each (detector, method) pair, take its highest sighting confidence, then add a small bonus for repeat sightings by that same pair:
The bonus is capped at 0.15. Seeing the same thing twenty times with one detector is only marginally better evidence than seeing it twice — the sightings are not independent.
2

Noisy-OR across methods

Reduce the groups to a per-method maximum, then combine across methods:
This is where confidence really rises. Independent methods reinforce each other: a model named in a lockfile and fingerprinted in an AST and matched by a file header is strong evidence in a way that three source-code regex hits are not.
3

Clamp at 0.99

The result is capped at 0.99, unless the evidence includes a hash-comparison sighting (or, in v2, a verified attestation).
The 0.99 clamp is a statement of epistemics, not a fudge factor. Static analysis reads what the code says, not what it does. Only a digest matched against known weights lets AIROM assert certainty — that is the one v1 path to 1.0.
The multiplication runs in sorted method order deliberately. Float multiplication is not associative, so map-iteration order would make the last bits of the score vary between runs. AIROM’s output is reproducible.

​
Bands

The SDK type airom.Confidence offers a Band() helper that buckets a score into three names:
Bands are a convenience for consumers of the Go SDK. No AIROM output emits them: they are not stored, not a field in any format, not shown in the table (which prints the float — 0.87), and not usable in a --fail-on expression. The float is the real value — compare against it, not against a band name.

​
Filtering with --min-confidence

--min-confidence takes a float in [0,1] and drops components scoring below it.
High-signal view
What it does:
  • Keeps every component at or above the threshold.
  • Always keeps the application root, so the output still identifies what was scanned.
  • Drops relationships whose endpoints did not both survive — no dangling edges.
  • Leaves assembly untouched. Re-run without the flag and everything is back.
--min-confidence is a per-run setting, not a per-output one. It applies to every output of that run — a -o table -o json=airom.json run writes the same filtered set to both. If you want a quiet table and a complete archival document, run the export a second time without the flag.

​
Be honest about the noise

On general-purpose directories, AIROM’s default output contains low-confidence noise. This is a real limitation, not a tuning preference.
Two detection paths are responsible: These sightings are honest about themselves: they carry the filename and config-analysis methods, and they score accordingly. AIROM reports them rather than hiding them, because a silently dropped dataset is worse than a noisy one. But on a repo that is not AI-focused, they will dominate the component count. The practical filter is --min-confidence 0.8. It clears both classes while keeping anything corroborated by an independent method — a .parquet file confirmed by its magic bytes scores 0.8 on binary analysis alone and survives; a .csv matched only by its extension does not.
Recommended for a first look at an unfamiliar repo
If you want a stricter view still, narrow what runs rather than what prints. --select takes an include/exclude expression whose tokens are detector IDs — so you can drop the dataset detector outright:
Scan without the dataset detector
Selection is per detector, not per rule pack. The low-confidence ai-config rules live inside the ruleengine detector alongside every other rule, so there is no --select token that drops just those — --min-confidence is the tool for that class of noise.
Every token must match a registered detector ID or tag, or the run fails with a usage error rather than silently doing nothing. Check a selection before you scan:
Check what a selection actually enables

​
Confidence in CI

--fail-on compares against the assembled float directly:
Fail only on high-confidence hosted model references
--min-confidence and --fail-on are fully independent. --min-confidence shapes the document; --fail-on decides the exit status, and it evaluates against the complete, unfiltered inventory. Raising --min-confidence to quiet the table will not weaken your CI gate — put the confidence threshold in the --fail-on expression itself if that is what you want to gate on.

Evidence model

The occurrences and methods that feed the score.

What is an AIBOM

The 13 component kinds.