What is Padas?
Padas is a security data company. We help organizations turn security data in motion into governed context they own — customer-owned context with provenance, control, and decision boundaries.
Padas Motion is the security data operations product line. It streams, routes, detects on, enriches, and controls telemetry across the SOC so teams forward signal instead of noise. Padas UI is the console; it manages one or more Motion Engine instances (console: Cores; tree: core/). Getting started installs the console and one engine on one Linux host.
Padas Chronos (emerging) is designed to turn processed telemetry into governed context and memory you own. Chronos is in development and is not generally available. It is not part of the Motion install path.
How to read these docs
If you're new, start with:
- This page (what Padas is, where it fits)
- Core concepts (events, streams, tasks, connectors in the Motion Engine)
- Architecture (how the pieces fit together)
- Getting started (install Padas Motion and run a sample pipeline)
What you can do with Motion today
Ingest from many sources
- Syslog over UDP/TCP (RFC 3164/5424, or raw lines)
- HTTP polling or push-style ingestion
- Kafka topics
- Files (tail / batch read)
- PADAS TCP (MessagePack) for cross-node forwarding
Build pipelines with streams and tasks
- Create streams as durable (WAL-backed) or in-memory channels for events
- Attach tasks that run PDL (Padas Domain Language) queries to filter, transform, enrich, and aggregate
- Run detection tasks that match events against one or more patterns and emit detections
- Send results to one or more downstream streams
Deliver data to destinations
- Syslog, HTTP, Kafka, Splunk — forward to external systems and SIEMs
- Object storage (S3-compatible) — write Parquet or JSON Lines into storage you own
- Engine REST API — consume streams from applications and dashboards
Padas does not replace the SIEM. Motion shapes what you send downstream.
Enrich with context (optional)
- Attach Lookup (nested Motion package; not required for Getting started) to resolve fields (IP → geo, asset → owner, hash → threat intel) without changing the engine schema
- PDL tasks apply enrichment inline during stream processing
How the product family fits
| Layer | Role | Ships in Motion today |
|---|---|---|
| Padas UI | Operator console and control plane: install, enroll, pipelines, monitoring | Yes |
| Motion Engine | Ingestion, processing, detection, routing | Yes (packages/padas-core-*) |
| Lookup | Field enrichment (geo, asset, threat intel) | Nested package; optional |
| Catalog / historical search | PDL over an Iceberg archive | Emerging — not in the Motion install |
| Padas Chronos (emerging) | Entity context, governed assertions, investigation memory, Context Packets | Not this install; not GA |
The Motion Engine stays schema-agnostic. Optional services add richness without a centralized schema at the edge.
Key design ideas
- Schema-on-read: ingest raw data first; normalize and enrich with PDL tasks later.
- Streams are the backbone: connectors and tasks all publish to and consume from named streams.
- Durability is configurable: per-stream WAL enables crash recovery and historical reads; in-memory streams minimize overhead for transient data.
- Operational visibility: metrics and lifecycle events are published as streams (
_padas_metrics,_padas_internal), exposable as Prometheus metrics. - Normalize to any schema: PDL tasks map vendor-specific fields to whatever shape downstream systems expect — OCSF for security analytics, OpenTelemetry semantic conventions for observability pipelines, or your own internal model. Raw data stays intact upstream.
A note on scope
Some ecosystems present streaming as a suite of loosely coupled products (brokers, schema registry, stream processors, connectors, governance layers). Padas Motion integrates the core streaming loop — ingest, process, detect, route — into one engine plus the console. Lookup, long-term search, and Chronos are optional or emerging additions, not prerequisites for Getting started.
When to use Motion (and when not to)
Good fits
- High-throughput log and event ingestion, from simple routing to complex windowed detection
- Real-time transformation, normalization, and field enrichment
- Detection and windowed aggregation with stateful processing
- Forwarding and fan-out to multiple destinations (Kafka, Splunk, S3, syslog)
- Shaping security telemetry before it reaches downstream tools
Not a fit by itself
- Long-term analytics over months of data — object-storage sinks write Parquet today; a catalog and PDL search service over that archive are emerging
- Full schema governance enforced at ingestion — Motion intentionally accepts heterogeneous inputs; schema validation is a downstream or application concern
- Replacing the SIEM — Motion forwards reduced, normalized volume; it does not take the SIEM's place
Next steps
- Read Core concepts to learn the vocabulary.
- Read Architecture to understand components and data flow.
- Install Padas Motion.