> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pulsedive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Indicators

> Learn how Pulsedive enriches observable entities into indicators, including risk scoring, properties, attributes, and lifecycle tracking.

Indicators are the core intelligence objects in Pulsedive.
When you submit or encounter an observable entity, such as a suspicious domain, Pulsedive processes and enriches it into an indicator object.

### Identity and Type

Each indicator has a value and a type.
The value is the observable entity itself, for example `pulsedive.com` or `8.8.8.8`.
The type describes what kind of observable entity it is.
Pulsedive supports five indicator types:

| Type     | Description     |
| -------- | --------------- |
| `domain` | A domain name   |
| `ip`     | An IPv4 address |
| `ipv6`   | An IPv6 address |
| `url`    | A full URL      |

### Properties

Properties are structured data points that Pulsedive collects about an indicator through passive and active scanning.
They capture what Pulsedive has directly observed, stored as name-value pairs grouped by scan type.
Examples include:

* DNS records
* WHOIS data
* HTTP headers
* SSL certificate details

Each property is timestamped.
By default, the API returns only the latest known value for each property.
You can request historical data to track how an indicator has changed over time.

### Attributes

Attributes are categorical tags applied to an indicator or threat, such as a port, protocol, technology, or detail like a threat's country or industry.

Pulsedive populates some attributes from scan data, but unlike properties, attributes aren't fixed once recorded: contributors can add or update them later, even for details a scan didn't directly observe, such as an open port reported by feed data after the fact.

Enterprise plans can define extensible attribute types beyond Pulsedive's built-in set.

### Lifecycle

Indicators carry a family of timestamps that track their history in Pulsedive:

| Field           | Description                                                                                                |
| --------------- | ---------------------------------------------------------------------------------------------------------- |
| `stamp_added`   | When Pulsedive first added the indicator                                                                   |
| `stamp_updated` | When Pulsedive last updated the indicator record, either through internal maintenance or a scan            |
| `stamp_seen`    | When Pulsedive last observed the indicator, whether through a scan, a feed, or a user submission or report |
| `stamp_probed`  | When Pulsedive last actively scanned the indicator                                                         |
| `stamp_retired` | When Pulsedive retired the indicator, if applicable                                                        |

An indicator becomes *retired* when it hasn't appeared in a feed or submission, or been observed in a scan, for three consecutive months.
You can also retire an indicator manually.
Pulsedive excludes retired indicators from active result sets by default but keeps their other data intact.

If a retired indicator reappears in a feed, submission, or scan, Pulsedive automatically restores it to active status.

### Submissions

Each indicator tracks how many distinct Pulsedive users have submitted it.
This `submissions` count is exposed in the API.

A high submission count is a provenance signal: it suggests the indicator is widely recognized across the community, not flagged by a single source.

### Risk

Pulsedive calculates a risk score for each indicator automatically.
The system-recommended score (`risk_recommended`) reflects Pulsedive's evaluation based on observed data and risk factors.
The active score (`risk`) is what the indicator currently carries, which may match the recommendation or reflect a manual override.

When `manualrisk` is set, a manual override has replaced the system-recommended score.
Risk factors (`riskfactors`) are human-readable explanations that describe why an indicator received its score.

Contributors and admins can override an indicator's risk in several ways:

* Through feed configuration
* Through bulk management in Explore
* By editing an indicator directly
* Through individual or bulk submission via Analyze