Reference · engine by engine
Every engine.
Documented.
CyberCLI ships 27 deterministic subsystems behind the AI agents — the gate, the dispatcher, the audit chain, the substrate. This index is the entry point to a deep doc on each one. Every page follows the same five-section shape: what it does, why you care, how it works, how to configure and observe, and its v1 status.
Looking for what's slated next? The engine backlog flattens every "known limit" from the 27 docs into one view, sortable by release.
Category · 5 engines
Pipeline
The 5 engines that turn a connector event into a decided action with a hash-chained audit row.
Digest → DecisionPacket builder with trust-ladder + risk-lock enforcement.
Per-connector dedupe + normalize before the SocPipeline.
Connector event → CanonicalEvent → SignalStore + DigestPipeline orchestrator.
Operator-acknowledged-noise rules; pattern-drift detector deactivates stale rules.
Per-role-per-target trust calibration with held-step + risk-lock ceilings.
Category · 5 engines
AI
The 5 engines that route signals to the right Guild role + provider and persist the AI policy.
Persists + audits the AI lane (local / byo_server / api / off) per install.
Two-pass routed (gate → triage/deep) AI digest with Guild role charters.
Routes events to Warden / Knight / Marshal / Herald / Scribe / Paladin per purpose. Registry stable; multi-pass invocation (Knight/Marshal/Scribe/Paladin) ships in v1.1.
Maps the enrolled connector roster onto 14 MITRE Enterprise tactics.
Reads [digest.providers.<role>] TOML overrides; v1 fires Warden only (v1.1 = multi-pass).
Category · 11 engines
Delivery
The dispatcher + routing-matrix + ack-loop + 8 adapters that ship the alert out.
Repeats critical-tier notifications until operator acknowledges; SLA timers + audit.
Sink that logs would-be deliveries; for smoke tests + new-install dry-run.
TLS-only SMTP with credential vault + per-recipient throttling.
Operator-supplied script invoked with sanitised JSON payload via stdin.
Push notification via ntfy.sh or self-hosted ntfy server.
Mobile push via pushover.net with priority + sound mapping.
Incoming-webhook + block-kit message formatting.
SMS / WhatsApp via Twilio; 160-char digest summary fallback.
Generic outbound HTTPS POST with HMAC signing + retry-with-backoff.
Signal → recipient → adapter dispatch with rate-limit + audit-on-success.
Per-severity routing rules (which destinations fire on which signals).
Category · 3 engines
Storage
The 3 engines that persist signals, cases, manifests, and the audit chain.
Append-only hash-chained audit log with Ed25519 signatures.
Validates + serves bundled connector manifests for the engine + dashboard.
Signals + cases + triage decisions in SQLite WAL with sqlite-busy retry.
Category · 1 engine
Security
The credential-vault engine that keeps every secret AES-GCM under a master key kept off the engine box.
Category · 2 engines
Substrate
The 2 engines that wire the Vector syslog substrate into the SOC pipeline.
Why we ship docs this way
Every engine deserves a page. Eventually every engine gets one.
Inventory is automatic. The list above is dumped from src/cybercli/engine_components.py on every marketing build, so drift between "what ships" and "what's listed" is impossible.
Deep docs are hand-written. Each five-section reference is written deliberately and reviewed alongside the code it documents. When the code drifts from the doc, that's a defect we fix on the engine — not a footnote we add to the page.
Stubs stay visible. Engines without a deep doc yet still appear as cards with a clearly-tagged stub badge. The card links to a placeholder page so a buyer always lands somewhere, never on a 404.