Skip to main content
If you need to troubleshoot risk scoring, explore these solutions to common issues. If you don’t find your issue here, check the Data Model documentation or reach out to Support. In API responses, risk appears in the risk, risk_recommended, manualrisk, and riskfactors fields. Most ways to override a score happen in the Pulsedive console.

How do I find out why an indicator got its risk score?

Check the riskfactors array in the indicator’s response. Each entry includes:
  • description: Human-readable explanation of the specific factor.
  • risk: Risk level that factor contributes.
Pulsedive calculates risk automatically from observed data, and riskfactors is how that calculation gets surfaced back to you in plain language, rather than leaving you to infer it from raw properties alone.

How do I check the underlying data behind a risk score?

Cross-reference the riskfactors descriptions against the indicator’s attributes and properties objects (WHOIS, HTTP, SSL, DNS, and so on). The risk factors reference the same observed data these objects contain, so you can trace a specific factor back to the specific evidence that produced it.
properties.http, properties.ssl, properties.meta, and similar fields are only populated after an active scan (probe=1). If a risk factor references data type you don’t see in the response, the indicator likely hasn’t had an active scan yet.

How do I report a false positive?

If you use Pulsedive Community, contact Support and include any documentation that supports your case. Otherwise, you can override the risk manually using one of these methods:
  • Through feed configuration, if the indicator came from a feed
  • Through bulk management in Explore
  • By editing the indicator directly
  • Through individual or bulk submission via Analyze
A manual override sets manualrisk to 1 and replaces the active risk value, while risk_recommended keeps showing Pulsedive’s original automated assessment. That means overriding a false positive doesn’t erase the system’s reasoning, it just lets your judgment take precedence for that indicator going forward.
Overriding risk changes what your exports and Explore queries return. Both filter on the active risk value, so lowering an indicator from critical to low removes it from any critical pull, and nothing in the export records that it dropped out. If a downstream tool blocks or alerts on your exports, remove the indicator there as well. To learn more, refer to Understand how filtering affects your dataset.