One decision engine, many event streams.
BlazeRules runs YAML and SQL-style rules on incoming data from HTTP, stdin, file tails, Kafka, Arrow, Avro, Protobuf, S3/local files, and nested JSON or Arrow payloads. Each use case below shows where the engine sits, which operators matter, and what teams can route downstream.
Decide before the authorization path moves on.
A payment event carries amount, card, merchant, device, location, and history signals. BlazeRules can combine deterministic rules, velocity state, BIN/watchlist lookups, geo distance, and model scores into one batch decision.
RuleEngine.evaluate_ndjson(...)rules:
- id: payment_high_risk
decision: REVIEW
score: 80
when:
and:
- field: amount
op: gt
value: 2000
- field: billing_country
op: neq_field
other_field: shipping_country
- window: {field: card_token, func: count, duration: 30m}
op: gte
value: 4
- field: merchant_bin
op: in_lookup
lookup: risky_bins
- op: distance_gt
lat_field: billing_lat
lon_field: billing_lon
other_lat_field: shipping_lat
other_lon_field: shipping_lon
value: 500
- model_score: {model: fraud_v1}
op: gt
value: 0.72- Score and reason code in the authorization path.
- Batch velocity without an external query service.
- Grouped indices for bulk routing to review or block queues.
Turn noisy monitoring into compact review streams.
AML monitoring is often dominated by false positives and manual review. BlazeRules keeps deterministic watchlists, rolling sums, ratio windows, and temporal rules close to the transaction stream so candidate alerts are compact before analyst systems see them.
rules:
- id: aml_new_payee_burst
decision: REVIEW
risk_band: HIGH
when:
and:
- field: counterparty_id
op: in_lookup
lookup: sanctions_watchlist
- window: {field: customer_id, func: sum, metric: amount, duration: 24h}
op: gt
value: 50000
- window: {field: customer_id, func: ratio, numerator: foreign_wire, denominator: all_wire, duration: 7d}
op: gte
value: 0.40
- field: event_ts_ms
op: time_of_day_between
value: ["22:00", "06:00"]- Fewer low-signal alerts entering review.
- Same YAML rules for stream and backtest runs.
- Auditable reason codes and risk bands.
Reduce log volume before expensive indexing.
Security teams often pay to store and search every line, then fight alert fatigue. A local agent can accept HTTP logs, stdin, file tail, or Kubernetes container logs, apply regex/CIDR/temporal rules, and emit only compact detections plus DLQ rows.
blazerules_agent --input http|stdin|file_tailrules:
- id: suspicious_auth_log
decision: REVIEW
when:
and:
- field: message
op: regex
value: "(permission denied|token leak|sudo failure)"
- field: source_ip
op: ip_not_in_subnet
value: "10.0.0.0/8"
- field: service
op: not_in_lookup
lookup: service_allowlist
- field: event_ts_ms
op: time_of_day_between
value: ["22:00", "06:00"]- Route high-value detections, not every log line.
- Keep malformed records out of the hot path.
- Observe source health from the dashboard.
Filter bad traffic before bidding or attribution.
Invalid traffic rules depend on fast deterministic checks: user-agent patterns, device fingerprints, proxy ranges, publisher allowlists, and request flags. BlazeRules keeps those checks in the request stream and emits grouped decisions for downstream routing.
rules:
- id: invalid_traffic_prebid
decision: BLOCK
when:
or:
- field: user_agent
op: regex
value: "(bot|crawler|headless)"
- field: device_fingerprint
op: in_lookup
lookup: bad_devices
- field: source_ip
op: ip_in_subnet
value: "198.51.100.0/24"
- field: signal_flags
op: flags_any
value: 12- Suppress invalid requests early.
- Protect attribution and inventory metrics.
- Keep clean requests on the fast path.
Evaluate cart, account, and device risk together.
Checkout and refund events are nested: items, promotions, merchant state, buyer history, and device data live in one payload. BlazeRules can use dotted fields and array_any without forcing users to flatten every item into a separate row.
rules:
- id: refund_abuse_with_risky_item
decision: REVIEW
when:
and:
- field: account_age_days
op: lt
value: 7
- array_any:
path: items
where:
and:
- field: price
op: gt
value: 250
- field: category
op: in
values: ["electronics", "gift_card"]
- window: {field: buyer_id, func: count, duration: 24h}
op: gte
value: 3- Protect refund and promo flows.
- Preserve one order as one decision record.
- Route risky orders without extra ETL jobs.
Catch bonus, device, and withdrawal abuse in the session stream.
Gaming platforms see repeated entities, device clusters, bonus events, and withdrawal attempts. BlazeRules can combine velocity counters, entity keys, vector similarity, and fingerprint lookups before events hit manual review or payout systems.
rules:
- id: bonus_cluster_abuse
decision: THROTTLE
when:
and:
- window: {field: player_id, func: count, duration: 1h}
op: gte
value: 8
- field: device_fingerprint
op: in_lookup
lookup: banned_devices
- vector_distance:
dims: [emb_0, emb_1, emb_2]
reference: [0.10, 0.20, 0.30]
metric: cosine
op: gt
value: 0.92- Throttle repeated abuse automatically.
- Detect clustered device behavior.
- Review withdrawals before payout.
Alert on abnormal telemetry at the edge.
Industrial telemetry creates constant high-volume readings. BlazeRules can run range checks, temporal windows, missing-value checks, model scores, and vector distance near the gateway so only meaningful anomalies move downstream.
rules:
- id: machine_anomaly_edge
decision: ALERT
when:
or:
- not:
field: temperature_c
op: between_including
values: [5, 95]
- field: pressure_psi
op: is_null
- window: {field: machine_id, func: avg, metric: vibration, duration: 10m}
op: gt
value: 0.70
- model_score: {model: sensor_anomaly_v1}
op: gt
value: 0.80- Reduce cloud telemetry volume.
- Keep latency-sensitive alerts local.
- Route bad or missing sensor payloads cleanly.
Reject unsafe orders before they hit the market path.
Pre-trade checks need fast account, symbol, price-band, size, and flag logic. BlazeRules is a good fit when an application already batches order events and needs deterministic allow/reject/review outputs in-process.
rules:
- id: pre_trade_limit_check
decision: REJECT
when:
or:
- field: order_qty
op: gt_field
other_field: max_order_qty
- field: order_price
op: lt_field
other_field: min_price
- field: order_price
op: gt_field
other_field: max_price
- field: symbol
op: in_lookup
lookup: restricted_symbols
- field: account_flags
op: flags_any
value: 4- Reject bad orders before downstream systems.
- Keep policy in YAML instead of scattered callbacks.
- Bulk-route rejects and exceptions by row index.
Replay history before changing production rules.
The same deterministic rules used online can run over local or S3-backed batches for fire-rate checks, candidate comparison, lookup/model validation, and dashboard review. Treat this as a release workflow around the local data plane.
rules:
- id: candidate_high_risk_route
enabled: true
decision: REVIEW
when:
and:
- field: merchant.risk.score
op: gte
value: 85
- field: country_code
op: not_in
values: ["US", "CA", "GB"]
- field: tags
op: contains_any
values: ["new_device", "new_payee"]- Estimate fire-rate movement before activation.
- Validate lookups and model dependencies together.
- Use dashboard panels for release review.
Feature-to-use-case map
The engine features are not abstract checkboxes. They remove specific work from real event pipelines.
| Feature | Payments | AML | Security | Adtech | Marketplace | Gaming | IoT | Capital |
|---|---|---|---|---|---|---|---|---|
| Windows | ● | ● | ○ | ○ | ● | ● | ● | ○ |
| Lookups | ● | ● | ● | ● | ● | ● | ○ | ● |
| ONNX / model_score | ● | ○ | ○ | ○ | ● | ○ | ● | ○ |
| Vector similarity | ○ | ○ | ○ | ○ | ○ | ● | ● | ○ |
| Regex / CIDR | ○ | ○ | ● | ● | ○ | ○ | ○ | ○ |
| Nested / array_any | ● | ○ | ○ | ○ | ● | ○ | ○ | ○ |
| Grouped routing / DLQ | ● | ● | ● | ● | ● | ● | ● | ● |
Pick the first ingestion path that matches your data.
| You have | Use | Best for |
|---|---|---|
| NDJSON bytes or JSON logs | evaluate_ndjson / agent HTTP | payments, security logs |
| PyArrow / Arrow batches | evaluate_batch | pre-trade, backtests |
| Application logs over HTTP | blazerules_agent --input http | SIEM filtering, request filtering |
| Terminal, stdout, stderr | blazerules_agent --input stdin | local log triage |
| Log files or pod logs | blazerules_agent --input file_tail | Kubernetes / node-local logs |
| Kafka topics | blazerules_io consumer loop | AML, gaming |
| Arrow IPC, Avro, Protobuf | blazerules_io decoders | IoT, capital markets |
| S3 or local files | blazerules_io.read_* | offline backtests, lookup/model/rule loading |
Every decision path leaves an operations trail.
The local dashboard reads decision logs, DLQ logs, metrics, benchmark output, and rule summaries. It is an observability surface for decision behavior, not a hidden event processor.
Decision timeline
See decision rate, latency, and match-rate movement after a rollout.
Rule fire rates
Find which rules dominate review queues or block outcomes.
DLQ samples
Group malformed records by error code without flooding logs.
Source health
Inspect watched files, metrics URLs, freshness, and collector state.
Top winning rules
Track which rule IDs most often determine decisions.
Backtest and release panels
Review candidate output, benchmark summaries, and rollout health.