Skip to main content
An insight is a named detection Operata derives from the observations on a contact — a known pattern, surfaced once per contact it applies to.

​
How it works

An insight has four parts: a name (for example, audio_one_way), a category (audio, network, agent, contact), a severity (minor, severe, terminal), and a detection rule that runs over the contact’s observations. When the rule matches, Operata writes one insight record against the contact. Insights are derived, not collected. The Agent Experience Collector, Cloud Collector, and Cloud Orchestrator emit signals; Operata persists them as observations on a contact; the insight engine then reads those observations and writes insights. Late-arriving signals can change which insights apply — a contact that looks clean on first read may gain an insight once its Contact Trace Record (CTR) or Contact Lens record lands. Insights are bounded to one contact. Cross-contact analysis happens at the journey level, where Customer Journey Trace aggregates insights across the contacts that share a journey. The full list of detections Operata runs lives in the Insights catalog — names, categories, severities, and the conditions each rule matches.

​
Why insights are separate from observations

Raw observations answer “what happened?” Insights answer “what should I care about?” The split keeps the data layer general — every observation stays queryable — while letting Operata ship pattern detection without forcing every API consumer to reimplement it. New detections appear in the catalog over time; the observation shapes do not change when they do. Bounding each insight to one contact keeps them composable. Joins, journey rollups, and webhook events all assume one insight maps to one contact, which keeps the dashboard and Amazon EventBridge contracts predictable.