Overview

What BlazeRules is, who it is for, the problems it solves, and when not to use it.

BlazeRules is an embeddable C++20 vectorized decision engine with a Python module named blazerules. It evaluates declarative YAML rule sets over batches of JSON, NDJSON, or Apache Arrow records, and returns decisions, scores, risk bands, and the winning rule per record.

It is a library, not a hosted service — there is no daemon, network listener, or per-record evaluation path in the core. You collect records from a queue, file, API, or in-memory producer, then call the engine once per batch.

📘

In one sentence

BlazeRules turns rule evaluation from a per-record conversation into a vectorized columnar scan — so you can run thousands of rules over streaming batches at hundreds of thousands of records per second.

What it does

  • Compiles YAML rules once into immutable execution plans.
  • Runs columnar SIMD predicates over Arrow buffers and transposed JSON batches.
  • Infers schema from the first evaluated batch when you don't provide one.
  • Supports flat and nested records through dotted field names, plus array_any / SQL any_match(...) over arrays of objects.
  • Emits decisions, scores, risk bands, winning rules, match counts, and optional per-rule bitmasks.
  • Supports windows, lookups, regex, CIDR, temporal, geo, vector distance, and ONNX model_score rules.
  • Uses runtime-dispatched SIMD kernels: ARM64 NEON, x86_64 AVX2/FMA, optional AVX-512, and a scalar fallback.
  • Offers an optional blazerules_io module for Kafka, CDC, Arrow IPC, Avro, Protobuf, and local / s3:// file reads.

Who it is for

BlazeRules fits teams running high-volume, low-latency, deterministic decisioning as a step in a larger pipeline:

Payments & card fraud

Velocity windows, device risk, geo distance, BIN and merchant lookups before ML inference.

AML & transaction monitoring

Thresholds, structuring, watchlists, sanctions, and temporal rules.

AdTech request filtering

Deterministic suppression, blocklists, and brand-safety filters at request volume.

Eligibility & routing

FinTech, insurance, and payments eligibility checks; compliance routing.

What problems it solves

Traditional rule engines evaluate one record at a time through an interpreter, and general-purpose stream/SQL engines aren't built around rule metadata (actions, severity, scores, velocity windows). BlazeRules sits in between: the decision semantics of a rule engine with the execution physics of a columnar engine.

  • Shift-left filtering — drop or route the majority of records cheaply before expensive ML, SIEM, or warehouse hops.
  • Deterministic, explainable verdicts — every decision has a winning rule, a score, and a reason.
  • One engine for stream and backtest — the same rules run live and against historical Parquet/Arrow.

When not to use it

🚧

Know the boundaries

BlazeRules is a decision engine, not a database or a stream processor. Reach for the right tool when you need:

  • Generic SQL analytics, joins, or aggregations — use DuckDB, ClickHouse, or your warehouse.
  • Durable, distributed, exactly-once stream processing — use Flink, Spark, or Kafka Streams. BlazeRules is an operator inside or beside those systems.
  • Case management / investigator workflows — BlazeRules produces decisions; it is not a fraud-ops platform.
  • A hosted HTTP API — BlazeRules is embedded; you own the process.

Where to go next