Turqoa Docs

Decision Engine

The Turqoa Decision Engine is the automated reasoning layer that evaluates security events and determines responses. It processes every event through a configurable rule pipeline and outputs actions ranging from simple logging to gate lockdowns and drone dispatch.

Architecture

The Decision Engine sits at the center of the Turqoa platform, consuming events from all modules and producing actionable decisions:

                    ┌─────────────────────────┐
Gate OS ──────────→ │                         │ ──→ Gate Actions (open/hold/lock)
Terminal Security → │    Decision Engine      │ ──→ Drone Dispatch
Maritime Security → │                         │ ──→ Operator Alerts
Drone Telemetry ──→ │  ┌─────────────────┐   │ ──→ Escalations
External Intel ───→ │  │  6-Stage Pipeline │  │ ──→ Notifications
                    │  └─────────────────┘   │ ──→ Audit Log
                    └─────────────────────────┘
ComponentResponsibility
Event IngestionReceives and normalizes events from all source modules
Context EnrichmentAdds historical data, vessel/vehicle profiles, and zone context
Rule EvaluatorMatches events against the active rule set
Action PlannerDetermines and sequences the response actions
Action ExecutorDispatches actions to target systems
Audit TrailRecords every decision with full reasoning chain

6-Stage Pipeline

Every event passes through six sequential stages. If a stage rejects or filters the event, processing stops.

Stage 1: Ingestion

Events are received from the Kafka event bus, validated against the event schema, and assigned a processing ID.

ingestion:
  source: kafka
  topics:
    - turqoa.events.*
  validation:
    schema_check: strict
    reject_malformed: true
  deduplication:
    enabled: true
    window_seconds: 5
    key_fields: [source_module, event_type, source_device]

Stage 2: Enrichment

Raw events are enriched with contextual data from Turqoa's databases:

  • Vehicle/vessel history -- past transactions, risk scores, incident records
  • Zone context -- which zones the event location falls within, zone rules
  • Operator state -- current shift, operator assignments, workload
  • Temporal context -- time of day, day of week, holiday calendar
  • Weather conditions -- for drone dispatch decisions

Stage 3: Rule Matching

The enriched event is evaluated against all active rules. Rules are written in Turqoa's Policy DSL (see Rules).

WHEN event.type = "perimeter_breach"
 AND event.severity >= "high"
 AND context.zone.type = "restricted"
THEN
  action: dispatch_drone(mission: "alarm_verification")
  action: notify_operator(priority: "high")
  action: create_incident(severity: "high")

Stage 4: Conflict Resolution

When multiple rules match the same event, the conflict resolver determines which actions to execute:

StrategyDescription
PriorityHighest-priority rule wins
MergeNon-conflicting actions from all matching rules are combined
First MatchFirst matching rule in priority order is used exclusively
Most SpecificRule with the most conditions wins
conflict_resolution:
  strategy: merge
  fallback: priority
  max_actions_per_event: 10

Stage 5: Action Execution

Resolved actions are dispatched to their target systems:

Action TypeTarget System
open_gate / hold_gate / lock_gateGate OS
dispatch_droneFleet Controller
notify_operatorCommand Center
escalateAlert Manager
create_incidentIncident Tracker
update_risk_scoreRisk Scoring Engine
send_webhookExternal integrations
log_eventAudit system

Stage 6: Audit

Every decision is recorded with:

  • The original event
  • All enrichment data considered
  • All rules that matched
  • Conflict resolution outcome
  • Actions taken
  • Timestamps for each stage
{
  "decision_id": "dec_2026040610450001",
  "event_id": "evt_abc123",
  "pipeline_duration_ms": 14,
  "stages": {
    "ingestion": { "timestamp": "2026-04-06T10:45:00.001Z", "status": "passed" },
    "enrichment": { "timestamp": "2026-04-06T10:45:00.004Z", "context_sources": 4 },
    "rule_matching": { "timestamp": "2026-04-06T10:45:00.008Z", "rules_evaluated": 156, "rules_matched": 3 },
    "conflict_resolution": { "timestamp": "2026-04-06T10:45:00.010Z", "strategy": "merge", "actions_merged": 5 },
    "execution": { "timestamp": "2026-04-06T10:45:00.014Z", "actions_dispatched": 5, "all_succeeded": true },
    "audit": { "timestamp": "2026-04-06T10:45:00.015Z", "stored": true }
  },
  "actions_taken": [
    { "type": "dispatch_drone", "params": { "mission": "alarm_verification" } },
    { "type": "notify_operator", "params": { "priority": "high" } },
    { "type": "create_incident", "params": { "severity": "high" } },
    { "type": "log_event", "params": {} },
    { "type": "send_webhook", "params": { "endpoint": "security_soc" } }
  ]
}

Policy DSL

Turqoa's Policy DSL is a declarative language for writing decision rules. It uses a WHEN ... THEN ... syntax that is readable by security operators and auditable by compliance teams.

RULE "High-risk vessel in exclusion zone"
  PRIORITY 90
  WHEN
    event.type = "zone_entry"
    AND event.zone.type = "exclusion"
    AND context.vessel.risk_score >= 70
  THEN
    action: create_incident(severity: "critical")
    action: dispatch_drone(mission: "perimeter_sweep")
    action: escalate(to: ["security_manager", "port_authority"])
    action: notify_all_operators(message: "High-risk vessel in exclusion zone")

See Rules for the complete DSL reference.

Operating Modes

The Decision Engine supports three operating modes that control how decisions are executed:

ModeBehaviorUse Case
ShadowRules evaluate but no actions execute; results logged onlyTesting new rules
AdvisoryRules evaluate and recommend actions; operator must approveGradual rollout
LiveRules evaluate and actions execute automaticallyProduction

See Modes for detailed configuration and transition procedures.

Performance

MetricTargetTypical
Event-to-decision latency< 50ms8--15ms
Rules evaluated per eventUp to 500150--200
Events per second10,000+500--2,000
Audit write latency< 10ms3--5ms

Next Steps