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

# Lifecycle and backfill

> Signal statuses, transitions, and running a signal across your history.

## Statuses

Every signal is in exactly one of these states.

| Status               | Evaluates new artifacts? | Existing observations | Can return to active? |
| -------------------- | ------------------------ | --------------------- | --------------------- |
| **Draft / disabled** | No                       | Kept                  | Yes — activate        |
| **Active**           | Yes                      | Kept                  | —                     |
| **Disabled**         | No                       | Kept                  | Yes — activate        |
| **Deprecated**       | No                       | Kept                  | No                    |

Use **disable** when you want to pause a signal you might bring back. Use **deprecate** when you're retiring it for good.

Observations are never deleted by a status change. Disabling a signal stops it finding new matches; everything it already found stays on your deals.

### What the app calls these

The statuses above are the ones the MCP contract uses. The status pill on a signal card in the app uses shorter labels:

| Pill in the app | Lifecycle state                                |
| --------------- | ---------------------------------------------- |
| **Active**      | Active — evaluating new artifacts              |
| **Inactive**    | Draft or disabled — stored, evaluating nothing |

So a signal these docs call "disabled" reads as **Inactive** on the **Manage Signals** tab. Nothing differs underneath; only the label is shorter.

## Transitions

```
draft ──activate──> active ──disable──> disabled ──activate──> active
  │                    │                    │
  └────────────────────┴────────────────────┴──────> deprecated
```

**Editing configuration always returns a signal to disabled.** If you change instructions or document types on an active signal, it stops evaluating until you activate it again. This is deliberate — it stops a half-edited signal running against live data.

## Versions and concurrent edits

Each signal carries a version and a revision identifier that looks like `my-signal-key:1`. When you change a signal, you pass the revision you expect it to be at, and the change is rejected if someone else has edited it in the meantime.

If you hit a revision conflict, re-list the signal to get its current state and try again. Don't force past it without looking at what changed.

## Backfill

Activating a signal only affects artifacts ingested from that point forward. A backfill runs it across artifacts you already have.

**Every backfill must be bounded.** You must give a time window, an artifact cap, or both.

| Bound                                | Limit               |
| ------------------------------------ | ------------------- |
| `occurred_after` / `occurred_before` | Any range           |
| Max artifacts                        | 10,000 per backfill |
| Batch size                           | 100                 |

```text wrap theme={null}
Backfill the "Security review required" signal over artifacts from Q2, capped at 5,000 artifacts.
```

Backfills are queued and run asynchronously. They don't block anything, and you can keep working while one runs.

### Watching progress

Listing your signals reports three counts per signal:

* **Eligible artifacts** — how many artifacts match the signal's document types
* **Completed artifacts** — how many have been evaluated
* **Observations** — how many matches have been found

A signal that's evaluated 681 of 1,330 eligible artifacts and produced 115 observations is mid-backfill and matching about one artifact in six.

<Tip>
  Start with a narrow backfill — 30 days, a low cap — and look at what comes back before running it over everything. It's much cheaper to fix instructions after 200 artifacts than after 10,000.
</Tip>

## Deleting a signal

There's no hard delete. Deprecate is the terminal state, and it preserves the observation history so past analysis stays intact.