Signals runs a five-step loop: **detect → explain → hand off → observe → report**. The first two steps are fully deterministic, no model call is needed to notice a problem or describe it.

## 1. Detect

Signals reads your product's real runtime events. Repeats of the same thing are coalesced into a single logical incident, identified by:

```text
workspace + environment + kind + fingerprint
```

The release is treated as observation state, not identity, so the same error in a newer release stays **one** incident rather than spawning duplicates. An incident becomes card-worthy only when it crosses a policy threshold, for example, a production error that reaches a repeat count.

## 2. Explain: the Context Brief

When an incident first becomes card-worthy, Signals attaches a compact **Context Brief** built from facts Pathrule already holds:

```text
Pathrule Signals detected a production error.

What happened
- TypeError: checkout response was empty
- First observed in release 1.8.0
- Seen 3 times in production

Where
- Resolved context: /apps/web/checkout
- Flow: checkout

Why this became a task
- Production error reached the 3-occurrence threshold

Relevant Pathrule context supplied
- Rule: Refresh auth before retrying payment [strict]
- Memory: Checkout recovery decision
```

Alongside it, Signals stores a versioned **Context Receipt**, the exact rules and memories, at the versions they were when the card was created. The receipt proves *which context was supplied*, not that the AI semantically followed every rule. The label is always **Context supplied**, never *Rules followed*.

## 3. Hand off

Signals creates the same kind of Tasks card you already use, with the Context Brief in its prompt. That is where Signals stops. Everything after you start the card (investigation, code, tests, commit, review) is the existing Tasks flow, unchanged.

One canonical incident creates **at most one** card. Later occurrences and releases can never create a second one.

## 4. Observe

Once a newer production release appears, Signals starts watching it. Accepted production events act as coverage pulses; it does not keep a raw heartbeat history, only bounded aggregate coverage.

## 5. Report: the honest outcome

Signals reports one of four states, and it never overstates the evidence:

| State | Meaning |
|---|---|
| **Observing** | A different, newer release is connected and coverage is accumulating. |
| **Recurred** | The same fingerprint appeared again in the candidate release. The incident reopens on the same card. |
| **Quiet** | Healthy coverage passed the minimum window with no recurrence. Weaker than verified, it never marks a fix as done. |
| **Verified** | The same flow succeeded enough times under healthy coverage, with no recurrence. The incident resolves and you get one notification. |

Silence alone never counts as success. Only positive success evidence can verify a fix, and only within the same workspace, environment, flow, and candidate release.

## What happens to the linked card

- **Verified** completes the linked Signals card (if it is not running) with a runtime-verified marker.
- **Recurred** reopens that same card and never starts AI on its own, you approve it by starting it.
- A **running** card is never interrupted or moved; its marker updates and the safe projection retries after the run settles.
- **Quiet** and archived states never touch the card.

## What to read next

- [Setting up Signals](/docs/signals/setup) to turn it on in Pathrule Studio.
- [Plans, quotas and retention](/docs/signals/plans-and-limits) for limits and lifecycle.