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
└─────────────────────────┘
| Component | Responsibility |
|---|---|
| Event Ingestion | Receives and normalizes events from all source modules |
| Context Enrichment | Adds historical data, vessel/vehicle profiles, and zone context |
| Rule Evaluator | Matches events against the active rule set |
| Action Planner | Determines and sequences the response actions |
| Action Executor | Dispatches actions to target systems |
| Audit Trail | Records 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:
| Strategy | Description |
|---|---|
| Priority | Highest-priority rule wins |
| Merge | Non-conflicting actions from all matching rules are combined |
| First Match | First matching rule in priority order is used exclusively |
| Most Specific | Rule 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 Type | Target System |
|---|---|
open_gate / hold_gate / lock_gate | Gate OS |
dispatch_drone | Fleet Controller |
notify_operator | Command Center |
escalate | Alert Manager |
create_incident | Incident Tracker |
update_risk_score | Risk Scoring Engine |
send_webhook | External integrations |
log_event | Audit 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:
| Mode | Behavior | Use Case |
|---|---|---|
| Shadow | Rules evaluate but no actions execute; results logged only | Testing new rules |
| Advisory | Rules evaluate and recommend actions; operator must approve | Gradual rollout |
| Live | Rules evaluate and actions execute automatically | Production |
See Modes for detailed configuration and transition procedures.
Performance
| Metric | Target | Typical |
|---|---|---|
| Event-to-decision latency | < 50ms | 8--15ms |
| Rules evaluated per event | Up to 500 | 150--200 |
| Events per second | 10,000+ | 500--2,000 |
| Audit write latency | < 10ms | 3--5ms |
Next Steps
- Rules -- complete Policy DSL reference with examples
- Modes -- operating mode configuration and transitions
- API Reference: Events -- subscribe to decision events
- Command Center -- operator interface for decision oversight