Use Cases

The Problem

A receiver pours out a noisy stream of detections — energy at a frequency, a bearing, a power level — many of them spurious. You need to know when a signal appears, how long it persists, when its bearing or range-rate changes, and when it drops out. That is a lifecycle, not a row in a table. Hand-rolling the de-bounce, hysteresis, and per-emitter state is where the bugs live.

How tflo Helps

• Lifecycle events — noisy detections in; appeared / persisted / changed / dropped-out events out.
• Keyed execution — one graph definition, independent state per emitter or frequency bin.
• Glitch and runt detectors — reject transient energy that never becomes a real track.
• Rate-of-change and direction detection — Doppler range-rate, bearing-change alerts via rate_of_change and cross detectors.
• Checkpoint to S3 — crash recovery without replaying the capture from the start.

The Problem

Security and fraud telemetry arrives as a firehose of low-level events: connections, logins, transactions. Any single event is meaningless — what matters is a sustained pattern: a slow rise in failed logins, a transaction rate that crosses a baseline, a host that suddenly behaves unlike its peers. You need stateful, per-entity correlation, not a stateless rule on one record.

How tflo Helps

• Keyed by entity — per source IP, per account, per host, each with its own window state.
• Threshold-cross events — fire when a rate or z-score crosses a learned baseline.
• Pulse and hysteresis detectors — require a pattern to persist before alerting; suppress single-event noise.
• Policy filters — express detection rules in CEL, Rhai, or Rego and update them without recompiling.

The Problem

Thousands of sensors reporting temperature, pressure, vibration, humidity. You need running statistics per device, anomaly detection, and the ability to distinguish real events from transient glitches. Database queries and batch jobs miss the real-time window.

How tflo Helps

• Per-device state via keyed execution — each sensor ID gets its own window.
• Running statistics — mean, variance, standard deviation, z-score, all updated online.
• Glitch detector — rejects transient spikes that revert within a configurable window.
• Pulse detector — fires when a value stays above threshold for a minimum duration.
• Async-native — integrates directly into Tokio-based ingestion pipelines.

The Problem

Audio, radar, radio, and other waveform data streams at high sample rates. You need envelope detection, running statistics, and pattern recognition without buffering the entire signal. Many DSP tools are batch-oriented or require manual buffer management.

How tflo Helps

• Streaming window primitives — duration-based and count-based windows over any iterator or stream.
• Running moments — mean, variance, stddev, correlation, and median over sliding windows.
• Pattern and slope detectors — custom pattern matching and rate-of-change detection.
• Zero-copy keyed execution — process multiple channels independently without per-channel buffering.

The Problem

Running analytics close to the source means tight CPU and memory budgets. You can’t ship a Python runtime with NumPy to a Raspberry Pi or an industrial gateway. You need Rust-level performance and minimal allocations.

How tflo Helps

• Works on Iterator, no async required — use .tflo() on a bare Vec iterator for embedded use.
• Compiled graph — build once, feed data repeatedly. No per-tick allocation overhead.
• Minimal footprint — pull in only tflo-core for the engine; add crates as needed.
• File-based checkpointing — survive power cycles with local flash persistence.

The Problem

Latency percentiles, error rates, throughput, and saturation metrics stream in from hundreds of services. The hardest part isn’t the threshold — it’s the flapping: an alert that fires, clears, and re-fires every few seconds as a metric jitters around its limit. De-flapping is a hysteresis problem, and most alerting stacks don’t model it.

How tflo Helps

• Hysteresis detector — separate arm/disarm thresholds turn a flapping metric into one clean crossed event.
• Running statistical nodes — mean, variance, z-score over sliding windows.
• Window and pulse detectors — alert only when a metric stays in a band for a minimum duration.
• Rego policy integration — define alert policies in OPA/Rego via tflo-rego and evaluate them inline.
• Async streaming — ingest directly from Kafka, gRPC streams, or WebSocket feeds.

The Problem

Most real-world time-series data is not evenly sampled. Clinical measurements happen on clinic visit days, not every Tuesday at 2pm. Real estate transactions close when they close. Ecological field data arrives when a researcher visits the site. Traditional tools force you to resample, interpolate, or pad — distorting the signal before you even start analyzing.

How tflo Helps

• Duration-based windows, not count-based — 30_u64.days() means the last 30 days of data, regardless of how many points arrived.
• No resampling required — timestamps determine window membership. Gaps in data are gaps; tflo doesn’t invent fill values.
• Keyed by entity — track each patient, property, or study site independently with its own irregular cadence.
• Same graph, any data density — works identically whether you have 3 points per year or 10,000 per second.

The Problem

Logs stream in from dozens of services. Buried in the noise are upticks that matter: a spike in 5xx errors after a deploy, a sudden increase in database timeouts, a wave of auth failures that might be a credential attack. Dashboards show you the current count; they don’t tell you the rate of change or whether a burst is a real trend or a statistical blip.

How tflo Helps

• Count-per-window indicators — treat log event counts as a time series; compute SMA, EMA, and z-score over sliding windows.
• Pulse detection — fire when error rate stays above threshold for a minimum duration; ignore single-event noise.
• Slope detection — alert when the rate of increase exceeds a configurable threshold, not just a static count.
• Keyed by log type — track 5xx, 4xx, timeout, and auth-failure trends independently in one graph.