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. That record carries the timestamps it covered, the contributing observations, and any platform-native fields the rule consulted. Insights are derived, not collected. Collectors emit signals; Operata stores observations; the insight engine reads observations and writes insights. Because insights run after observation storage, late-arriving signals can change which insights apply — a contact that looks clean on first read may gain an insight once the Contact Trace Record (CTR) lands. Insights are bounded to a single contact. Cross-contact analysis happens at the journey level (see Customer Journey Trace), which can aggregate insights across the journey’s contacts. The full catalog of every detection Operata runs — names, categories, severities, and matching conditions — lives at Insights catalog.

​
Why insights are separate from observations

Raw observations answer “what happened?” Insights answer “what should I care about?” Keeping them separate means the data layer stays general — every observation is queryable — while Operata ships pattern detection without requiring every API consumer to reimplement it. New detections appear in the catalog over time; the underlying observations do not change shape when they do. Bounding each insight to one contact keeps them composable. Joins, journey rollups, and downstream alerting all assume one insight maps to one contact, which makes the dashboard and EventBridge contracts predictable.