> ## Documentation Index
> Fetch the complete documentation index at: https://docs.operata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Signals and observations

> A signal is a single measurement a collector emits in flight. An observation is the persisted Operata record built from one or more signals and tied to a contact.

A signal is a single measurement a collector emits in flight; an observation is the persisted Operata record that ties one or more signals to a contact. Signals flow; observations are stored.

## How it works

Each of the three collectors emits a different class of signal.

* The [Agent Experience Collector](/docs/collector-overview) emits signals for headset audio levels, network quality, microphone state, page focus, and softphone CTI events — the agent-side measurements no central service can see.
* The [Cloud Collector](/docs/concepts-cloud-collector) emits signals derived from Contact Trace Records (CTRs), Contact Lens, and contact-flow logs.
* The [Cloud Orchestrator](/docs/concepts-cloud-orchestrator) emits signals from each synthetic Heartbeat run.

A signal is small, structured, and timestamped. It becomes meaningful only when joined to the contact it belongs to.

The lifecycle runs in three stages. A collector emits a signal. Operata ingests the signal, joins it to the contact, and persists it as part of an observation. Downstream consumers — the dashboard, [EventBridge events](/docs/concepts-eventbridge), and the [contact endpoints](/docs/api-contact-summary) — read observations, never raw signals. Two signals from two collectors covering the same moment of the same contact land as one observation with two contributing sources.

```mermaid theme={null}
flowchart LR
    A[Agent Experience Collector] -->|signal| O[Operata ingestion]
    B[Cloud Collector] -->|signal| O
    C[Cloud Orchestrator] -->|signal| O
    O -->|persist| D[Observation on Contact]
    D --> E[API + EventBridge consumers]
```

## Why Operata stores observations, not signals

The split keeps the wire format separate from the storage format. Redaction, deduplication, late-arrival reconciliation, and per-tenant validation all run between the two. The value a collector reports is not the value a consumer reads: a signal can be dropped, deferred, or merged; an observation is the post-processing result a consumer can rely on.

The split also makes the data model honest about latency. Some signals arrive within seconds; Amazon Connect CTRs in particular can lag the contact end by minutes. Storing observations means a query for a recent contact returns a coherent partial view that fills in as more signals arrive, instead of a stream of half-correlated events.

## Related

* [Contacts and interactions](/docs/concepts-contacts-and-interactions) — the record observations attach to.
* [Insights](/docs/concepts-insights) — named detections Operata derives from the underlying observations.
* [Customer Journey Trace](/docs/concepts-customer-journey-trace) — observations roll up across the contacts that share a journey.
* [List contact summaries](/docs/api-contact-summary) — each summary row is built from the observations stored against a contact.
* [Get complete contact record](/docs/api-contact-record) — exposes the per-leg observations and their contributing signal sources.
* [Webhooks events](/docs/api-webhooks-events) — fires as new observations land, including late CTR-derived ones.