> ## 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.

# How Pulsedive Collects Data

> Learn how Pulsedive enriches indicators through scanning, third-party sources, community submissions, and research, and how to interpret freshness timestamps.

Indicators in Pulsedive are enriched from multiple sources.
Understanding where data comes from helps you evaluate the freshness, coverage, and trustworthiness of what you're seeing.

## Collection Methods

Pulsedive collects and enriches indicator data from four sources: scanning, third-party sources, community submissions, and Pulsedive Research.

### Scanning

Pulsedive scans indicators directly to collect properties.
All scans run from hardened, rotating proxies across multiple countries.
There are two scan types:

* **Passive:** Lookups that do not interact directly with the target, including WHOIS, DNS, and metadata retrieval.
* **Active:** Direct outreach to the target using headless browser instrumentation, which intercepts HTTP requests, TLS certificate data, cookies, and other response data.
  Active scans are more comprehensive but generate more noise than passive scans.

To learn more about scanning through the API, visit [Scan overview](/api/scan/overview).

### Sources

Sources are third-party organizations, research projects, and automated pipelines that contribute curated indicator lists to Pulsedive.
Source data is the primary driver of threat linkage and risk signal for many indicators.

<Note>
  Pulsedive is in the process of standardizing this terminology across the platform.
  You may encounter the term "feeds" in legacy parts of the UI and documentation.
  Note that this refers to third-party data sources ingested into Pulsedive, not the Pulsedive Feeds product, which is a separate bulk export service.
</Note>

### Community Submissions

Registered Pulsedive users submit and report indicators, contributing to the shared dataset.
The submission count on an indicator, which is surfaced through the API, reflects how many distinct users have flagged it.
To learn more about how submissions appear on indicators, refer to the [Submissions](/model/indicators#submissions) section of the Indicators page.

### Pulsedive Research

The Pulsedive team manually curates threats, links indicators to threats, retires stale data, and maintains overall data quality.
This research applies to Pulsedive Community only.

## Enterprise Differences

Pulsedive Community and Enterprise use the same scanning infrastructure, but data sources differ.

| Data Source           | Community                     | Enterprise                                 |
| --------------------- | ----------------------------- | ------------------------------------------ |
| Scanning              | ✓                             | ✓                                          |
| Sources (third-party) | ✓ Historical data from launch | ✓ Historical data from instance setup date |
| Community submissions | ✓                             | ✗                                          |
| Pulsedive research    | ✓                             | ✗                                          |

Enterprise data sources are fully managed by the customer.

## Data Freshness

Indicators carry a family of timestamps that tell you when different collection events last occurred.
Understanding these timestamps helps you evaluate how current an indicator's data is.

| 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                                                        |

`stamp_seen` and `stamp_probed` answer different questions.
`stamp_seen` tells you when any external signal last confirmed the indicator's existence.
`stamp_probed` tells you when Pulsedive last reached out to the indicator directly.
An indicator can be recently seen in a source without having been actively scanned, and vice versa.

To learn more about how these timestamps relate to an indicator's lifecycle, refer to the [Lifecycle](/model/indicators#lifecycle) section of the Indicators page.