Configuration Reference

BlazeRules configuration has three layers: runtime settings in EngineConfig, build-time CMake options that select features and SIMD kernels, and environment variables used for AWS and s3:// resources.

📘

Defaults prioritize correctness

EngineConfig() requires no overrides. Runtime settings should be changed only after measuring the target workload.

EngineConfig options

EngineConfig is configured by attribute and passed to RuleEngine. The Python binding exposes the fields below.

Batch execution and models

Result materialization and tracing

Ingest and schema policy

Windows and state

Predicate execution

Hot reload

🚧

output_detail integer values shifted — reference it by name

OutputDetail.COUNTS and OutputDetail.CODES were added before DECISIONS and BITMASKS in the underlying enum, so the raw integer values shifted: DECISIONS and BITMASKS used to be 0 and 1 and are now 2 and 3. Any config that serialized output_detail as a raw integer instead of the named constant — EngineConfig::OUTPUT_DECISIONS in C++, blazerules.OutputDetail.DECISIONS in Python, or a bare number in a hand-rolled config file — will silently resolve to a different, cheaper output tier after upgrading. Always set output_detail by name, never by number. See Decisions & Scoring for what each tier materializes.

Constructing an engine with a config

import blazerules

config = blazerules.EngineConfig()
config.output_detail = blazerules.OutputDetail.DECISIONS
config.ingest_error_mode = blazerules.IngestErrorMode.SKIP_AND_COUNT
config.type_mismatch_mode = blazerules.TypeMismatchMode.NULL_ON_TYPE_ERROR
config.simd_backend_override = "auto"
config.enable_avx512 = False

engine = blazerules.RuleEngine(config)
engine.load_rules("rules.yaml")

import blazerules

config = blazerules.EngineConfig()

schema = [
    blazerules.Field("card_token", "entity_key"),
    blazerules.Field("amount", "float32"),
    blazerules.Field("account_age_days", "int32"),
]

# Pass an explicit schema instead of inferring it from the first batch.
engine = blazerules.RuleEngine(schema, config)
engine.load_rules("rules.yaml")

📘

Constructor forms

RuleEngine() uses defaults and infers schema from the first batch. RuleEngine(config) applies runtime settings and still infers schema. RuleEngine(schema, config) binds explicit field types before evaluation. See Data Model & Schema for inference and drift semantics.

Setting these from the CLI

The commonly used runtime options map to blazerules eval flags:

blazerules ... --config config.yaml accepts the supported CLI configuration keys under an engine: block. Explicit flags take precedence. The complete command and value tables are in API & CLI Values.

Build-time CMake options

These options select compiled features and SIMD kernels during CMake configuration. The project defaults enable the complete feature set.

🚧

BLAZERULES_IO_KAFKA only matters when BLAZERULES_IO=ON

The Kafka, Avro, Protobuf, and S3 sub-options have no effect unless the IO module is built with -DBLAZERULES_IO=ON. Release wheels and default source builds enable the IO module. Python exposes runtime capability checks as has_kafka, has_avro, and has_protobuf. There is no has_s3 attribute; native S3 support is selected at build time and can fall back to the AWS CLI path. See Troubleshooting for connector diagnostics.

Portable Linux, Windows, and cloud builds do not compile generic code with global AVX flags. ISA-specific files are compiled separately and selected at runtime. For ready-made build shapes per platform, use the presets documented in Deployment.

Environment variables

The engine reads exact-object s3://bucket/key URIs for rules, lookup CSVs, and ONNX models. Configure the profile, region, and endpoint with environment variables or the equivalent set_aws_profile(), set_aws_region(), and set_aws_endpoint_url() functions.

export BLAZERULES_AWS_PROFILE=personal
export BLAZERULES_AWS_REGION=us-east-1
export BLAZERULES_AWS_ENDPOINT_URL=http://127.0.0.1:9000

BLAZERULES_AWS_ENDPOINT_URL supports S3-compatible endpoints such as MinIO. Credentials belong in the deployment platform's secret mechanism rather than source-controlled files.

SIMD diagnostics

Two read-only helpers report the selected backend and detected CPU features.

import blazerules

print(blazerules.simd_backend())          # e.g. "neon" on an Apple M1
print(blazerules.cpu_features_summary())  # human-readable CPU feature list

On Apple Silicon, simd_backend() normally reports neon. On an x86_64 host with AVX2 support, it normally reports avx2. A supported simd_backend_override changes the selected backend.

🚧

AVX-512 auto-selection is still runtime-gated

AVX-512 kernels are compiled in full builds, but runtime selection still checks CPU and OS support. Some server CPUs reduce frequency under wide vectors, which can make AVX-512 slower than AVX2 for mixed rule workloads. Benchmark the production ruleset and target hardware before forcing a backend.

Related documentation