When a scan finds something that might belong to you, it doesn't go straight into your inventory. It becomes a **candidate** and passes through a confidence gate.

This matters because discovery is inherently inferential. A subdomain in a Certificate Transparency log, or a hostname in reverse DNS, is evidence that something exists — not proof that it's yours.

## The confidence gate

Each candidate gets a confidence score from the source that found it. A DNS record resolved directly from your domain is stronger evidence than a favicon hash matching an unrelated IP address.

- **High confidence (85 or above)** — promoted to your inventory automatically and marked auto-approved.
- **Medium (60 or above) or low** — held in the **Discovery** review queue for a human decision.

> **IP addresses are the exception: an IP is never promoted automatically, whatever its confidence.** An A record scores 90, which would auto-approve anything else — but the address it points at is very often a CDN or a shared host you don't own and nobody may scan. Ownership of an address is a judgment for a person, so every IP candidate waits in the queue.

Sources **accumulate**. If a candidate is first seen by one weak source and later corroborated by a second, its score rises and it may cross the threshold on its own. Nothing is thrown away for lack of evidence — it just waits for more.

Only promoted assets are enriched and evaluated. A candidate sitting in the queue is never scanned for vulnerabilities.

A single scan promotes a bounded number of new assets, so a large estate settles over several scans rather than all at once. If your contract records a maximum asset count, a discovery that would exceed it is reported as a gap on the scan's coverage record rather than silently dropped.

## The review queue

Open **Discovery**. The queue shows each candidate's type, value, confidence badge with the numeric score (for example "high (92)"), how many sources found it (hover for the list), and when it was first and last seen.

Filter by confidence level — at least one level must stay selected — and by type.

## Approving and declining

**Approve** promotes the candidate to an asset, after which it will be enriched and evaluated by subsequent scans.

**Decline** removes it from the queue. You can record an optional reason of up to 500 characters. Write one — six months later, "why isn't this being scanned?" is much easier to answer if the reason is there.

Use the header checkbox to approve or decline in bulk.

## History

The **History** tab shows every decision: type, value (linking to the promoted asset where relevant), status, who decided, when, and the reason given.

Declined candidates have a **Re-approve** action. Decisions are reversible — if you declined something that turned out to be yours after all, you don't need to re-add it by hand.

## What to look for

Candidates worth a careful look:

- **Subdomains you don't recognise** — often forgotten staging, marketing or vendor-hosted systems. These are exactly what an external attacker finds first.
- **IP addresses from reverse DNS** — a hostname pointing at an IP doesn't mean you control that IP. Shared hosting produces plenty of false candidates. This is why they always wait for you.
- **Anything on a cloud provider range** — verify it's your account before approving.

Approving an asset means Perimeter will actively collect against it. Only approve what you own or are authorized to test — see [Security and acceptable use](security-and-acceptable-use).