How the loop works
From a production event to a verified fix, how Signals detects what matters, attaches context, hands off to Tasks, and then watches the next release to prove the outcome.
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:
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:
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 to turn it on in Pathrule Studio.
- Plans, quotas and retention for limits and lifecycle.