Signal events and evidence

A Signal Event is a single detection: one rule, one team, one finding, held open for as long as the pattern keeps recurring. Signal Intelligence at /signals/active lists them; clicking one opens its detail view.

The thing worth understanding is that a signal event is not a log entry. It is a living record that gets updated.

One event per rule per team

There is at most one active event for a given rule and team at a time. When the rule matches again, the existing event absorbs the new detection instead of a second event appearing beside it. The merge is deliberately asymmetric:

Hit count increments. This is the number shown as Detections, and drives Signal Strength.
Confidence takes the higher of the two. A weaker later detection cannot dilute a strong earlier one.
Severity ratchets up and never down. An event that reached Critical stays Critical while it is active.
Source entries are merged, de-duplicated, so the evidence list grows.
Last detected moves forward; first detected does not.

The effect is that a persistent pattern reads as strong rather than frequent, and a signal that briefly spiked doesn’t quietly downgrade itself into invisibility.

Feedback that isn’t attached to a team produces workspace-level events under the same one-per-rule rule.

Reading the metrics

The detail view leads with five numbers.

Metric	What it is
Detections	How many times this rule has matched since the event opened
Confidence	The verified confidence after critique, as a percentage
Evidence	How many feedback entries the event draws on
First Seen	When the pattern was first detected
Last Detected	When it was most recently confirmed

Two of these are easy to conflate. Detections counts evaluation passes; Evidence counts source entries. A signal with 12 detections and 3 pieces of evidence is a pattern that keeps re-confirming from a small base — quite different from 3 detections across 40 entries.

In the list view, the same event is compressed into a severity-coloured left edge, a type badge, a confidence bar, and source and hit counts. Sorting is by Signal Strength, Severity, or Most Recent, and the list can be filtered by team and by signal type. All of that lives in the URL, so a filtered view is a link you can send someone.

Evidence is the point

Every signal event stores the IDs of the feedback entries that produced it, and the interface will show you them — expandable inline in the list, always visible on the detail page.

Evidence is anonymous by design. Each entry shows its content and its date, and nothing else. There is no attribution, no author, no way to reach one from the signal. That constraint is what makes it safe to surface morale and burnout patterns at all: the finding is visible without the person being.

Evidence drawn from a survey answer renders as a labelled Survey Question and Response pair, so you can see what was actually asked rather than a floating sentence.

You will sometimes see a line reading that some entries are no longer available. That happens when a source entry has gone since detection — deleted, or aged out under data retention. The count is honest about the gap rather than silently shrinking, because a signal built on ten entries of which three are now unreadable is a weaker claim than one built on seven.

Actions: recording the response

A signal describes a situation. An action records what you did about it.

Actions are created inline on the signal detail page — a title is all that’s required — and move through Open, In Progress, and Resolved. They belong to a team as well as to the signal, and they deliberately outlive the signal that prompted them: if the underlying pattern cools and the signal is archived, the action remains. A commitment made in response to a finding shouldn’t disappear because the finding did.

That is also why actions are separate from automations. An automation is a standing rule about what should happen; an action is a record of what someone actually took on.

When signals go away

A signal event that has not been re-detected for seven days is archived automatically. It stops appearing in Signal Intelligence, and the rule becomes free to open a fresh event if the pattern returns — with a new first-detected date, which is usually the more useful reading anyway.

Nothing is deleted; archiving only removes the event from the active view.

A note on older links

Signals used to live under /feedback/signals. Those URLs, including individual signal links, now redirect to the signals section. Old bookmarks will land you in the right place, though a link to a specific signal will not preserve which signal it was.

Signals overview — how detection and severity work
Signal catalog — the rules that generate events
Automations — pairing conditions with actions