One compiled decision path from transport to action.

BlazeRules receives event batches, projects only the fields a ruleset uses, computes stateful and model-derived signals, and reduces matching predicates into decisions without routing every record through a callback graph.

C++20 core Arrow columns runtime SIMD batch-first API

HTTP
Kafka
files

→

PROJECT
DERIVE
EVALUATE

→

decision
score
route

The transport changes. The compiled rule plan and result contract do not.

The runtime pipeline

Work is separated into a cold compile path and a repeatable hot path. Rules, regular expressions, lookups, expressions, and model channels are resolved before batches enter the evaluator.

Decode

Read NDJSON, JSON arrays, Arrow IPC, Avro, or Protobuf.

Bind

Infer once or validate against an explicit field contract.

Project

Materialize referenced scalar and nested fields as columns.

Derive

Inject window, lookup, model, vector, and expression channels.

Evaluate

Reuse predicates and combine matches as bitmask operations.

Reduce

Return decisions, scores, risk bands, rule IDs, or bitmasks.

Compile once. Reuse the work.

Rule loading creates a global predicate plan. Repeated conditions are evaluated once per batch and shared by every rule that needs them, while output detail controls how much result data is built.

Rule A

amount > 500 AND country != home

Rule B

amount > 500 AND velocity > 4

Rule C

amount > 500 AND model_score > .8

→

SHARED PREDICATE DAG

amount > 500 once

country

window

model

Shared masks feed rule reduction instead of repeated object traversal.

Input	Adapter work	Engine entry
NDJSON / JSON array	Parse and project referenced paths	evaluate_ndjson / evaluate_json_array
Arrow / Arrow IPC	Align projected typed buffers	evaluate_batch
Avro / Protobuf	Decode into Arrow RecordBatch columns	blazerules_io decoders
Kafka / CDC	Poll, decode, batch, evaluate, commit	blazerules_io run_stream
HTTP / stdin / file tail	Bound and batch incoming records	blazerules_agent

Adapters end at the same columnar contract.

JSON pays a parsing and projection cost. Arrow starts closer to the evaluator. Binary decoders produce Arrow batches before rule execution. That boundary keeps rule semantics consistent across live streams, embedded calls, and backtests.

Compare the measured format paths

Signals become columns, not side pipelines.

Stateful and learned signals join the same batch before decision reduction. A rule can mix deterministic operators with historical, reference, model, and similarity evidence.

history

Windows

Count, sum, average, and ratio channels carry prior-batch entity behavior into the current decision.

manage_search

Lookups

String, integer, and IPv4 CIDR sets turn managed watchlists into reusable membership predicates.

model_training

ONNX scores

Registered numeric-feature models produce score columns that rules can threshold alongside deterministic evidence.

scatter_plot

Vector distance

Dot, cosine, and distance signals compare embedding columns for similarity and coordinated-behavior checks.

State scales with the partition key.

Window state belongs to an engine shard. Routing the same entity to the same shard preserves ordering and avoids a shared global lock while independent partitions evaluate concurrently.

Prior batches are committed to the shard store. The next batch reads that state, evaluates, and then applies its updates.

card_17

card_42

card_91

→

Shard 0

engine + local windows

Shard 1

engine + local windows

Shard 2

engine + local windows

One core, four operating surfaces.

Choose the process boundary that fits the system. All surfaces load the same rule format and converge on the same engine result.

Python SDKEmbed RuleEngine in a service and evaluate NDJSON, JSON arrays, or PyArrow batches.

C++ libraryLink the engine directly where process-local latency and memory control matter.

AgentReceive HTTP, stdin, or tailed files and write compact NDJSON or Arrow result streams.

IO runtimeDecode binary formats, consume Kafka, and feed record batches into the same engine.

The operating trail stays attached.

The read-only dashboard tails decision and dead-letter outputs, reads active rulesets, and presents throughput, custom decisions, model channels, errors, and rule behavior without sitting in the evaluation hot path.

Explore the dashboard

BlazeRules dashboard ruleset validation and collapsible YAML view

See the architecture under load.

The benchmark matrix separates direct decoder ceilings, HTTP transport results, and 504-rule planning medians.

View benchmarks