> ## Documentation Index
> Fetch the complete documentation index at: https://docs.findtempo.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Create a signal
> Describe a signal in the Deal Brain app, or draft, preview, activate, and backfill one over MCP.
This walks through building one signal from scratch. It takes a few minutes.
## Two ways to work with signals
Signals have two surfaces. They act on the same org-wide signals, so a signal created on one is visible on the other.
| Surface | Use it for |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **The Deal Brain app** | Describing a signal in plain language, browsing what's configured, and reading the observations your signals have collected. |
| **Your [AI platform](/integrations/mcp) over MCP** | Agent-driven configuration — drafting a candidate, previewing it against named artifacts, activating, and backfilling. |
Start in the app if you just want a signal running. Use MCP when you want an agent to do the work, or when you want to preview against specific artifacts before anything goes live.
## Create a signal in the app
Open **Signals** from the left sidebar. The page has two tabs: **Manage Signals** and **Collected Signals**.
**Manage Signals** lists every signal in your org as a card showing its status pill, name, artifact scope (for example, "All artifacts"), and signal key. Use **Find signal…** to search by name, and the **All statuses** dropdown to filter by status. Each card has a **…** overflow menu.
Type into the box prompting **Describe a signal to monitor…**. Write it the same way you'd write it for a colleague: what counts, what doesn't, and examples of both. That description is the whole configuration — see [writing instructions](/signals/writing-instructions) before you write it.
You can also start from the **New Signal** button at the top right.
Read the draft before it goes anywhere. Check that the wording excludes the near-misses you don't want — your own reps speculating, generic mentions of the topic, anything already covered by another signal.
A signal that isn't active is stored and evaluates nothing. Once you activate it, every new eligible artifact is evaluated as it's ingested. The status pill on the card reads **Active** or **Inactive** — see [lifecycle](/signals/lifecycle) for how those labels map to the underlying states.
## Create a signal over MCP
You do this by talking to Deal Brain through your [AI platform](/integrations/mcp). You need the `configure_signals` permission.
Drafting and saving are two separate steps. Deal Brain drafts a **candidate** first — a structured proposal that isn't stored anywhere. Nothing exists in your org until you explicitly save it.
### 1. Draft a candidate
Describe what you want to find. Deal Brain turns your description into a structured set of extraction instructions.
```text wrap theme={null}
Draft a new signal for our org called "Security review required". It should find cases where a buyer-side stakeholder tells us a formal security or compliance review is required before they can purchase. Include positive and negative examples.
```
This calls `generate_signal`, which returns a candidate for you to read. It does **not** save anything. If you stop here, the signal doesn't exist.
Ask for positive and negative examples explicitly. They do most of the work — see [writing instructions](/signals/writing-instructions).
### 2. Choose which artifacts it applies to
A signal only runs against document types you select. Pick the ones where the pattern would realistically appear, and get them right on the candidate before you save it.
```text wrap theme={null}
Revise that candidate so it only applies to email, transcript, gong, and granola artifacts. It won't show up in research or brain-dump notes.
```
The available document types are:
`gong` · `transcript` · `granola` · `email` · `document` · `chat` · `brain-dump` · `research` · `generic`
### 3. Save the candidate as a disabled signal
Saving is what creates the signal in your org. Deal Brain saves it through `manage_signals` using the `upsert_disabled` action, so it lands in a **disabled** state — it's stored, it has a signal key, and it evaluates nothing.
```text wrap theme={null}
Save that candidate as a disabled signal, and tell me the signal key it was saved under.
```
Hold on to the signal key. You need it for the next step, and for every later edit.
### 4. Pick the artifacts to preview against
Preview doesn't run against "recent artifacts" or your whole history. You choose the artifacts, and you name them by ID — between 1 and 20 of them per preview.
So before you preview, go get some IDs. Ask for artifacts on a deal where you'd expect the pattern to show up:
```text wrap theme={null}
List the artifacts on the Acme deal from the last quarter with their IDs, types, and titles. I'm looking for calls and emails where a security or compliance review would plausibly have come up.
```
Do the same on a deal where you'd expect the signal to stay quiet:
```text wrap theme={null}
Now list the artifacts on Jaffle Inc from the same period, with IDs. Security never came up on that deal as far as I know.
```
Deliberately mix in artifacts you expect it to *skip*. A preview that only contains likely matches tells you nothing about false positives.
### 5. Preview
Hand Deal Brain the saved signal and the specific artifact IDs you collected.
```text wrap theme={null}
Preview the "Security review required" signal against these artifacts: . Show me what it matched, what it skipped, and why.
```
Read the misses as carefully as the hits. If it's catching seller-side speculation rather than buyer statements, or matching generic mentions of "security," tighten the instructions and preview again.
### 6. Refine
Refining works the same way as creating: generate a revised candidate, then save it over the existing signal.
```text wrap theme={null}
Draft a revised candidate for "Security review required" that only matches statements from buyer-side stakeholders, not our own reps speculating that a security review might be needed. Add that as a negative example. Then save it over the existing signal.
```
Saved edits keep the signal disabled, so you can loop through steps 4 through 6 as many times as you want before anything goes live.
### 7. Activate
Activate only once a preview looks right.
```text wrap theme={null}
Activate the "Security review required" signal.
```
From here, every new eligible artifact is evaluated as it's ingested.
### 8. Backfill your history
Activation only affects artifacts going forward. To catch what's already there, run a backfill.
**Backfills must be bounded** — by a time window, an artifact cap, or both.
```text wrap theme={null}
Backfill the "Security review required" signal across artifacts from the last 90 days, capped at 2,000 artifacts.
```
| Bound | Limit |
| ------------ | ---------------------------------------------- |
| Time window | Any `occurred_after` / `occurred_before` range |
| Artifact cap | Up to 10,000 artifacts per backfill |
| Batch size | Up to 100 |
### 9. Track how it's doing
Backfills run asynchronously. Listing your signals reports three counts for each one — how many artifacts are eligible, how many have been evaluated, and how many observations came out of them.
```text wrap theme={null}
List our signals and show me the counts for "Security review required" — eligible artifacts, completed artifacts, and observations so far.
```
Those counts tell you a signal is working. To read what it actually found, go to the app.
## Read what a signal found
Observations live on the **Collected Signals** tab of the Signals page. It's a table of the observations your signals have recorded, with four columns: **Signal**, **Observation**, **Context**, and **Source quote**.
The source quote is what makes the table worth reading. You see the language each observation was drawn from, so you can judge a match instead of trusting it — which is also how you tell a noisy signal from a precise one.
Use **Find collected signal…** to search the table, and **Filters** to narrow it down.
Read observations here, not over MCP. No public MCP tool returns the observations for a given signal — `list_signals` gives you counts, not the matches behind them.
If what you read tells you the signal is wrong or too noisy, you can disable it (stops evaluation, keeps observations) or deprecate it. See [lifecycle](/signals/lifecycle).