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

# Runs and signals

> What happens on a schedule, and what a run found.

## Runs: what happens on a schedule

Each run does the same four things:

1. **Searches** every source the listener uses, with the queries in its plan.
2. **Pulls the post text** wherever the platform allows it, rather than judging a search result.
3. **Filters**, cheaply first: page shape, off-topic, your exclusions, blocked domains, anything outside the data window, and duplicates. All of this happens before any model is called, so filler costs nothing.
4. **Judges** what survives: a reranker scores every candidate against the listener's intent, and only the best reach a classifier that labels intent, scores it, and writes one line on how you might reply.

A run that dies is marked as failed rather than left looking like it is still going. Every run records its step logs — sources searched, hits kept, results skipped as too old or duplicated, signals saved — and those are visible in the listener's Activity tab and on the Run history screen.

**Rescanning further back** is possible when you first set a listener up, so a new listener is not staring at an empty screen until its window fills.

## Signals: what a run found

A **signal** is one public post, judged. Signals live with the listener that found them, because the vocabulary and the useful columns differ per objective.

### The classes

Each objective has its own labels. The first group is what you see by default; the rest are stored and filed behind their own tabs rather than thrown away.

| Objective                   | Shown by default                        | Filed behind tabs                |
| --------------------------- | --------------------------------------- | -------------------------------- |
| Find customers / Situations | `high intent`, `evaluating`, `relevant` | `competitor`, `content`, `noise` |
| Competitor dissatisfaction  | `switching`, `frustrated`, `comparing`  | `praise`, `noise`                |
| Local prospects             | `pain confirmed`, `at risk`             | `healthy`, `noise`               |

Local prospect signals also carry the review's **star rating** and a list of **themes**. The star rating and the score are deliberately drawn differently: they are two different numbers, and a one-star review about parking is a one-star review and a ten-score signal.

### What you can do with one

* **Rate it.** Thumbs up or down. This is not cosmetic — rated signals are fed back into that listener's next classification as worked examples.
* **Save it.** Saving adds it to your workspace's *Saved* list. Saved is visible to the whole workspace on purpose: a star is a statement to your team, not a private bookmark.
* **Add it to a list.** Named collections, so "Q1 outreach" works the same way Saved does.
* **Write a note.** Notes are keyed to the signal and follow it everywhere, including onto its pipeline card.
* **Assign it** to a teammate.
* **Add it to the pipeline**, one at a time or in bulk — see [The pipeline](/guides/pipeline).
* **Draft outreach** from it — see [Outreach drafts](/guides/outreach-drafts).
* **Open the source**, which is always one click away. Nothing here is a summary you have to take on trust.

Signals are marked read as you open them, so a busy morning leaves a clear line between what you have triaged and what you have not.

### Filtering and search

The filters above the table are applied **in the database**, not in your browser, so the counts above the list always describe the list below it:

* **Classification** — the tabs
* **Source** — one platform, or all
* **Theme** — for review-based signals
* **Search** — matches words, with stemming, so `report` finds `reporting`
* **Saved** — your workspace's starred signals

Lists page as you scroll, newest post first, with undated posts after dated ones.

### Roll-ups

Where one row per post is the wrong shape, there is a roll-up: one row per **rival**, per **account**, or per **place**, with the signals underneath. A competitor losing eleven users is one row, not eleven mentions.

Programmatic access to signals and roll-ups is described under `search_signals` and `get_rollup` in [MCP & agents](/mcp/tools).


## Related topics

- [Listeners: what you are watching for](/guides/listeners.md)
- [Tools](/mcp/tools.md)
- [Scoring and quality](/guides/scoring-and-quality.md)