A
AggregationOne of the three core concepts of Guardian Ops. The process of combining multiple related abuse reports or events into meaningful groups (customers / cases) for easier management and response. API Caller Node
A playbook node that makes HTTP requests to external systems with configurable payloads. Used for integrating with customer APIs and external services during case processing. API Resolver
A powerful resolver type that sends queries to a specified endpoint to identify customers and contracts. Can integrate with external APIs to link abuse reports to identifiers and data from your customer relationship management. Automation
One of the three core concepts of Guardian Ops. The use of playbooks and workflows to automatically handle routine tasks and responses in abuse management.
C
Case A structured container that groups related abuse events for investigation and resolution. Cases are created based on configurable rules and can aggregate multiple reports affecting the same customer or contract. Case GroupA collection mechanism that organizes cases based on specific rulesets. Case groups act as buckets where cases are categorized depending on attributes like abuse type, customer, or contract. Case Group Node
An inbound processing node that assigns events to cases based on configurable rules. Groups related events together and adds case IDs to event payloads. Case Rule
Logic that defines how cases are created or associated with events. The default rule creates one case per customer, but this can be customized for different workflows. Contract
A customer’s specific resources or services (e.g., mobile vs. DSL connections, servers, domains). Multiple contracts can belong to a single customer. Contract ID
A unique identifier for contracts. Customer
An individual or company entity with a unique identifier. In Guardian Ops, customers represent the parties responsible for IP addresses or resources generating abuse reports. Customer ID
A unique identifier to identify your customers. Can be a real customer ID or pseudonymized. Customer Resolution The process of linking abuse reports to the correct customers, contracts, and tenants.
D
Draft The initial state for new flows where configurations can be modified freely. Events or cases are not processed by draft flows, allowing you to build and test configurations without affecting live processing. Draining A flow state that occurs when a new inbound processing or playbook flow is activated. The previous flow continues to process remaining events until completion, ensuring no events are lost during the transition. Only applies to inbound processing flows.E
EventA single instance of reported abuse activity, typically parsed from an abuse report email or submitted via API (e.g., XARF). Events contain details about the abuse incident and are processed through inbound processing flows. Event Type A classification assigned to events during inbound processing to categorize the nature of the abuse (e.g., spam, malware, copyright, phishing). Guardian Ops supports 43 distinct event types, some with additional subtypes for granular classification.
F
Flow States The operational states that determine whether flows process events or cases and whether they can be modified. States include Draft (editable, not processing), Active/Live (processing, read-only), and Draining (inbound processing only, processing remaining events).I
Inbound ProcessingThe configurable workflow that determines which events reach Guardian Ops and how those events are enriched. It includes filtering, resolver application, and routing to appropriate case groups. Incident IP Resolver A resolver type that sets the subscriber ID to the IP address if available in the event data. If no IP is found, the event remains unresolved.
M
Manual Node A playbook node that allows abuse desk agents to make manual decisions in automated workflows. When a case reaches a manual node, it pauses until an agent selects one of 2-4 configured decision paths. Cases requiring decisions appear in the Manual Decision tab.N
NodeIndividual components in inbound processing flows or playbooks that perform specific functions like filtering, resolving, or routing events and cases.
O
OrchestrationOne of the three core concepts of Guardian Ops. The coordination and management of abuse response workflows across different teams, systems, and processes.
P
Playbook Automated or semi-automated workflows that define how cases should be handled. Playbooks operate on cases and must be attached to case groups to execute. Multiple playbooks can be live simultaneously, and each playbook can have multiple versions. Playbook Version A specific configuration of a playbook. Each playbook can maintain multiple versions, with one version active per playbook. Versions allow you to iterate on workflows, test changes, and maintain configuration history.R
ResolverA component that identifies and enriches events with customer and contract information. Types include Static, API-based, Domain, Header-based, and others. Resolver Data
Additional metadata attached to events during the resolution process, providing context about customers, contracts, or other relevant information.
S
Static String Resolver A resolver type that assigns a predefined static ID to all events passing through it. Static Resolver Node An inbound processing node that maps any event field to customer, tenant, or contract identifiers. Particularly useful for forwarding custom data through XARF or handling non-standard customer identification.T
Tag NodeAn inbound processing node that adds custom tags to events for categorization and filtering. Tags help with event classification and routing decisions. Task
Individual actions within playbooks, such as delays, API calls, notifications, or conditional logic operations. Tenant
A way to distinguish between subsidiaries or divisions that might have overlapping customer identifiers. Tenants help organize customers in multi-organizational environments. True/False Node
A conditional logic node used in inbound processing, cases, and playbooks. Routes workflows along different paths based on evaluated conditions.
U
Unresolved EventAn event that couldn’t be matched to a customer or contract during inbound processing. These events require manual review or configuration updates to the active inbound processing flow.
W
Wait Until NodeA playbook node that waits for a specific condition to become true or until a maximum timeout is reached. Provides conditional waiting with true and timeout output paths.