Overview#
An analyst monitoring a high-value target needs continuous alerting without writing complex query logic. They type "alert me when this entity appears in any new financial transaction above $50,000 flagged medium or higher", and the Monitor domain turns that sentence into a running intelligence monitor, complete with a safety review step if the specification touches sensitive thresholds.
Key Features#
- Natural language monitor creation from user prompts
- Safety flag detection and approval workflows for sensitive monitors
- Configurable threshold sensitivity levels: low, medium, high, and critical
- Alternative proposal generation: conservative and aggressive options
- Monitor lifecycle management: draft, pending approval, approved, active, and paused
- Idempotency key support to prevent duplicate monitor creation
- Multi-tenant isolation for all monitoring configurations
Use Cases#
Relevant sectors include intelligence agencies, financial crime investigation, and law enforcement.
- Creating automated intelligence monitors using plain language descriptions
- Setting up surveillance monitors with appropriate safety review workflows
- Configuring threshold-based alerting for specific investigation domains
- Managing monitor lifecycles with pause, resume, and approval controls
Integration#
The Monitor domain integrates with Observability for system monitoring, Intelligence for intelligence gathering, Search for query execution, and Performance for performance monitoring.
Open Standards#
- GraphQL (June 2018 specification): the entire Monitor API surface is exposed as a typed GraphQL schema, using queries and mutations for lifecycle operations (create, update, approve, pause, resume) and returning strongly-typed response objects.
- JSON (RFC 8259): monitor configurations, threshold parameters, safety flags, alert configuration, and execution statistics are all stored and exchanged as JSON or PostgreSQL JSONB documents.
- Cron expression syntax (Vixie cron / POSIX): schedule cadences are represented as standard five-field cron expressions (e.g.
0 0 * * *), evaluated at runtime via the croniter library to calculate next-run timestamps. - RFC 4122 UUID: every monitor and monitor-execution record is identified by a version-4 UUID, ensuring globally unique, collision-resistant identifiers across tenants.
- ISO 8601: all datetime values (created_at, updated_at, last_run, next_run) are stored and serialised in ISO 8601 format with UTC timezone offsets, enabling unambiguous temporal reasoning across locales.
- BCP 47 (IETF language tags): monitor locale fields accept and return standard IETF BCP 47 language codes (en, es, fr, de, ar, zh, ru, sw, hi, pt), allowing multi-lingual source scoping.
- OAuth 2.0 / Role-Based Access Control: monitor operations are gated by an authenticated identity context, and the approval workflow enforces a SUPERUSER role check consistent with OAuth 2.0 scope-based authorisation patterns.
Last Reviewed: 2026-02-05 Last Updated: 2026-04-14