What an honest detection inbox says when the answer is “we don’t know”

A detection inbox exists to help a person decide what to do next. Its hardest job is not displaying a suspicious listing. It is describing the absence of one without claiming more than the system observed.

A zero is a measured result. A failed query is not zero. A scan that has not run is not zero. A filter that hides everything is not zero. When those states share the same empty card, the interface converts missing evidence into reassurance.

The empty state must name its uncertainty

Brand Protector’s New tab does not translate an empty result into an all-clear. It says there may be no new threats since the last run, or that the next scan has not fired yet. That wording keeps the observation inside its actual boundary: this queue, at this point in the scan lifecycle.

Search and filter emptiness are handled separately. If the loaded detections contain no match for the current controls, the interface describes the filter result rather than the underlying threat state. Clearing a filter is therefore an action the user can take; waiting for a scan is a different action.

A failed count should not render as zero

The inbox uses one resolver to define the list and its counts. Count results carry a basis: exact, a subset of the loaded rows, failed, or not measured. A failed or unmeasured count renders as unavailable rather than 0. That prevents a transient database or index failure from impersonating a clean queue.

The list follows the same principle. Query errors produce a visible alert. A missing database index is reported as a loading problem, not an empty inbox. The predicates that select rows and the predicates that count them come from the same resolver so a tab label cannot quietly describe a different population from the cards beneath it.

Scope has to be visible

Platform and severity controls change what the inbox is answering. Brand Protector applies the same minimum-confidence threshold to the list and count queries. AI-answer observations are deliberately kept off this marketplace inbox and live on their own product surface. The result is narrower than “everything the company monitors,” and the interface should be read that way.

A search performed over loaded rows is labeled as a subset, not passed off as an exact total for every row in storage. When more rows are available, the loading boundary remains part of the state. This is a modest distinction, but it stops a local view from becoming a global claim.

Human decisions need reversible states

Brand Protector separates New, Escalated, Confirmed, and Dismissed findings. Confirm, dismiss, and escalate actions write audit events. Dismissed detections remain in their own tab instead of disappearing; a bulk restore can move them back to New if the decision was mistaken.

Bulk review also reports partial failures rather than pretending a mixed batch succeeded. The product caps a bulk operation, applies the requested transition to each eligible detection, and returns the items that could not be changed. A visible exception is actionable. A silent miss inside a success banner is not.

Review the inbox as an evidence instrument

When evaluating a detection product, test the states around the happy path. They reveal what the interface believes a number means:

• Open a tenant before its next scan and inspect the empty wording.
• Apply a filter that returns no rows and compare that message.
• Force a query failure in a test environment and inspect the count.
• Dismiss a finding, locate it again, and restore it.
• Run a mixed bulk action and look for item-level failures.

A noisy queue asks the reviewer to spend more attention. A silently incomplete queue asks the reviewer to trust evidence that was never gathered. The honest inbox makes noise manageable, preserves human decisions, and refuses to turn “not measured” into “nothing found.”