Skip to main content

Glossary

The platform uses a large amount of invented vocabulary: packer, receiver, behavior, facet configuration, EntityInfo table. This glossary gives a one-line definition per term and points at the page that covers it in depth. Look a word up here the first time you meet it.

Naming notes​

Two naming inconsistencies confuse readers before any individual term does. Both are real and current; neither is a leftover from a rename.

Fluency vs. Ingext​

Fluency and Ingext are two live brands from the same company, not an old name and a new one.

  • Ingext (ingext.io) is the streaming data-pipeline and lakehouse product: collection, transformation, routing, and storage.
  • Fluency (fluencysecurity.com) is the AI-native SIEM: detection, behavior analytics, investigation, and response.

Both names appear in product surfaces and in this manual, and the live web interface shows a Fluency logo. Neither is a correction of the other.

FPL: "Programming" or "Processing"?​

FPL is expanded two different ways in official material:

  • Fluency Programming Language: used in the product interface and at fpl.fluencysecurity.com.
  • Fluency Processing Language: used in the Ingext documentation.

Both expansions name the same language.

A​

Action (FPL Action)​

An FPL object that performs an outbound operation (sending an email, posting to Slack, calling an external API) when a rule, notification endpoint, or report invokes it. Managed on Configuration → Processors (v1: Platform → Processors) under the Actions tab. See Processors and Actions.

Application​

An installed unit of platform functionality (a packaged pipeline and its configuration), listed on Applications (v1: Platform → Applications under Installed Applications). Installing one stands up a data source, the processors that parse it, and the sinks it writes to as a unit, which is why connecting a source is a form to fill in rather than a pipeline to build.

Application Template​

The reusable definition an application is installed from. Templates are browsed and installed from the Application Catalog, which groups them into eight categories, and listed by internal ID on Configuration → Application Templates, where a template of your own can also be defined in YAML (v1: the Install Application From Template and Application Templates views). See Integrations for which product each one connects.

Asset​

A tracked host, device, or system record maintained by the platform and searchable on Assets (v1: Platform → Assets → Assets Search). Also the subject of metric alerts. See Assets (v1: Assets) and Ingress Management.

B​

Behavior​

A correlated finding produced by the EventWatch engine from one or more events: the platform's unit of detection output, as opposed to a raw event. See Investigate and Detections.

Behavior Filter​

An exception to a behavior rule: a named, toggleable condition that stops matching behaviors from being raised. Filters are managed from the Behavior Filters page, opened from the Behavior Rules page (v1: the Behavior Filters view of the Behavior Rules page), subtitled Exceptions for Behavior Rules, where each filter carries an Enabled toggle and the list of behaviors it applies to. Use one to suppress a known-good pattern without editing or disabling the rule that detects it. See Behavior Rules (v1: Behavior Rules) and Detections.

Behavior Rule​

The definition that tells EventWatch what pattern to detect and what behavior to emit. Also called a behavior model in parts of the interface. See Creating a Behavior Rule, Managing Rules, and Configuration → Behavior Rules (v1: SIEM → Behavior Rules).

Behavior Summary​

The aggregated view of behaviors grouped by entity and key, used to see which subjects are accumulating risk. See Behavior Summary, and Cases Search with one entity's case on Behavior Summary (v1: SIEM → Behavior Summary).

Behavior Timeline​

The chronological view of individual behavior records, used to reconstruct what happened in order. See Behavior Timeline and Notable Events (v1: SIEM → Behavior Timeline).

C​

Case​

A grouping of related behaviors, events, and analyst notes tracked through an investigation workflow to a disposition. See Ticket for the queue item the interface exposes.

Cloud Collector​

Collection performed by the platform's own cloud-side receivers rather than by software you run: the per-tenant syslog endpoint and the hosted API pollers. Contrast with Collector. See Syslog Import and Syslog Ports.

Collector​

The Fluency Collector: software deployed inside your network to gather data that cannot reach the cloud directly and forward it to the platform. See Fluency Collector and Why Use a Collector.

D​

Data Lake​

The platform's long-term event store and the part of the interface that works with it: Datalake Search, KQL Search, and the indexes and schemas on Configuration → Data Lakes and Schemas (v1: the Data Lake menu, indexes, schemas, search, investigations, and the KQL builder). See also Data Storage.

Data Sink​

The pipeline component that writes records out of a pipeline: to the data lake, to EventWatch, or to an external destination. See Data Sinks.

Data Source​

The pipeline component that reads records into a pipeline from a receiver, a queue, or an external API. See Data Sources.

E​

EntityInfo Table​

A lookup table of entity values (event-ID dictionaries, watchlists, translations) that the SIEM references to enrich or interpret events. See Configuration → Entity Tables (v1: EntityInfo Tables).

Entity / Key / Key Type​

The subject a behavior is tracked against. The key is the identifying value (a username, an IP address, a hostname), the key type declares what kind of value it is, and entity is the resolved subject the key refers to. See Behavior Summary.

Event​

One normalized record in the data lake: the smallest unit of collected data, after parsing and normalization. See Event Data Model and Events Search.

EventWatch​

The real-time correlation and alerting engine that evaluates incoming events against behavior rules and emits behaviors, risk, and notifications. The name is also a menu label in the legacy interface. See Detections.

F​

Facet​

The attribute / value / count breakdown shown beside search results, used to focus or exclude results with a three-state checkbox per value. See Facets.

Facet Configuration​

A named, saved set of facet groups applied to a particular index; the interface ships a general Default plus a per-source configuration for each integrated data source. See Datalake Search and Configuration → Search Facets (v1: Data Lake → Search), and Facets.

FPL​

Fluency Programming Language: the platform's own language for parsing, transforming, correlating, and reporting on data. It is the implementation language of processors, receivers, packers, actions, and rules. Also expanded as Fluency Processing Language in Ingext material; see the naming note above. See FPL.

H​

HEC​

HTTP Event Collector: the Splunk-compatible HTTP ingest endpoint, letting any client that can post to Splunk's HEC send to this platform instead. See HEC (Splunk-compatible).

I​

Index​

A named table of records in the data lake, with its own column set and schema; queries name an index as their starting point. See Configuration → Data Lakes (v1: Data Lake → Management) and KQL.

Ingress​

The inbound side of the platform: the flow of data in, and the volume of it. Used both for the mechanism and for the measured rate. See Integration Matrix, Data Collection, and the Event Ingress Report (v1: Usage).

Integration​

A configured connection to an external product, either to pull its audit data in or to push notifications and actions out. See Integrations and the Integrations page (v1: Integrations).

Investigation​

A costed, asynchronous search run over the data lake, started from the search page with Run Investigation and tracked with its state, cost, and duration. See Investigation History (v1: Investigations and Data Lake → Search).

K​

Key / Key Type​

See Entity / Key / Key Type.

KQL​

The Kusto-style, pipe-oriented query language used by KQL Search (v1: the Data Lake KQL Query Builder) and by the platform's programmatic search and validation calls. Distinct from the Lucene syntax used by Datalake Search (v1: Data Lake → Search), which is the platform's primary event search and is current, not superseded. See KQL and Lucene Queries.

L​

Lakehouse​

The Ingext architecture pattern that combines a streaming pipeline with lake storage, so records are queryable as tables without a separate warehouse load. The term appears in Ingext product material; see Pipeline Components and Data Storage for the two halves.

N​

Notification​

The delivery of an alert to a person or system through a configured endpoint (Email, Slack, and others), governed by notification rules. Endpoints are backed by FPL actions. See Configuration → Notifications (v1: Notifications) and Alerts & Actions.

P​

Packer​

An FPL object type that batches, formats, or encodes records before they leave the pipeline, the counterpart to a receiver on the outbound side. Managed on Configuration → Processors (v1: Platform → Processors) under the Packers tab. See Processors.

Pipe​

An ordered chain of processors inside a router. A router holds one or more pipes; each pipe row on the router shows the pipe's name and how many processors it contains, for example (1 procs). A record entering the router is passed through the processors of a pipe in order. Distinct from the | operator, which chains stages within a single FPL or KQL statement. See Router, Pipeline Components and KQL.

Processor​

An FPL object that parses and transforms events as they pass through the pipeline, the workhorse of normalization. Managed on Configuration → Processors (v1: Platform → Processors). See Processors and Configuration → Processors (v1: Platform → Processors).

R​

Receiver​

An FPL object type that accepts inbound data on the platform's edge and hands it to a pipeline. Managed on Configuration → Processors (v1: Platform → Processors) under the Receivers tab. See Processors and Receiving Data.

Report Processor​

An FPL processor written to produce a report: a scheduled or on-demand query whose output is a table, a dashboard panel, or a delivered document. See Reports → FPL Reports (v1: Reports → Processors) and Reports.

Resource​

A record collected from an integration and held in the account for correlation and lookup: the directory objects behind the events, rather than the events themselves. The Resources page lists them by vendor, one record set per table, and each record can be opened (v1: per integration, with types such as Applications, Devices, Groups and Users, and each record can be opened or exported). Not to be confused with a Resource Sync Group, which is a bundle of content. See Resources (v1: SIEM → Resources).

Resource Sync Group​

A named bundle of platform content (one per integration) that Resource Sync keeps up to date in the account. Groups are named after what they carry, such as Fluency_AWS, Fluency_AzureAD and Fluency_CiscoMeraki; enabling a group brings in the parsers, rules and supporting objects for that integration. It groups content, not tenants. See Configuration → Resource Sync (v1: Resource Sync) and, for the multi-tenant use of the same mechanism, Resource Sync (MSSP).

Risk Score​

The open-ended, accumulating score attached to an entity as behaviors fire against it, used to rank what deserves attention. See Risk Scoring.

Router​

The pipeline component that directs records down different paths based on their content or labels. See Data Routers.

S​

Schema​

The definition of an index's fields, their types, its aliases, and its virtual tables. Managed on Configuration → Schemas (v1: Data Lake → Schemas). See Schemas (v1: Schemas).

Severity Level​

The ranked importance assigned to a behavior or alert, used for sorting, filtering, and deciding notification routing. The interface uses five bands (Critical, High, Serious, Medium and Low), which are also the severity tiles on the Overview Summary page (v1: the Severity Filter). See Overview Summary (v1: Behavior Timeline).

Syslog Port​

A listener port that accepts syslog. On the cloud syslog endpoint the tenant is allocated a small block of ports and one port is used per protocol (Syslog TLS, TLS RFC 6587, Syslog UDP, Syslog TCP), not per data source; the domain and the per-protocol ports are read from Configuration → Syslog Ports (v1: Platform → Administration → Syslog Ports). On a collector appliance the default listeners are 514 for udp and tcp, TLS listeners are added (usually 6514 for tls and 7514 for tls (RFC6587)), and a listener there can carry a Customer Tag, which is how records are attributed to a site or customer. See Syslog Ports and Configuration → Syslog Ports (v1: Platform → Syslog Ports).

T​

Ticket​

The platform's own queue item: the unit of work an analyst opens, acknowledges and closes. Tickets are counted on the Home page's Open Cases and Cases Handled panels and by the OPEN and CLOSED BY AI counters on Overview Summary (v1: on the landing dashboard, as Total Tickets, Tickets Closed By AI and Open Tickets), and carry a status of New, Acknowledged, Closed or Closed By AI. A ticket may additionally be mirrored into an external system such as PagerDuty or ServiceNow by an FPL action, but the record in that system is the copy, not the ticket itself. See Overview Summary (v1: SIEM → Overview Summary), Actions and Notification & Ticketing.

V​

Virtual Table​

A derived table projected from an index by a schema (defined with a name, a root field, and a label selector), so a subset of a wide index can be queried as its own table. See Configuration → Data Lakes and Schemas (v1: Data Lake → Management and Schemas).

  • Reference: the rest of the specification material
  • Page Functionality: where each term appears in the interface
  • FPL: the language reference
  • KQL: the data lake query language