Rule engine boundary

Rules turn selected broker events into ordered, bounded actions. The current runtime supports topic matching, optional schema validation, bounded JSON enrichment, internal republish, and bridge dispatch.

Configuration ownership

The required nginx module export exists, but its public directive surface is not release-ready. Rule definitions are currently referenced from nginz-iotd:

[rules]
enabled = true
config_ref = "file:/etc/nginz-iot/integration-edge.rules"

[schema]
enabled = true
config_ref = "file:/etc/nginz-iot/integration-edge.schemas"

[bridges]
enabled = true
config_ref = "file:/etc/nginz-iot/bridge.toml"

Keep all three generations coordinated. Candidate replacement is atomic and a malformed reload retains the last good rule and schema set.

Failure policies

The production grammar exposes only implemented retry and dead_letter bridge failure policies. Every queue, action list, transform, and payload is bounded. A rule does not run a blocking sink client inside nginx or the broker loop; external side effects go through nginz-iot-bridge.

Grammar sketch

rule sensor-validate
  event publish
  topic factory/+/telemetry
  schema plant.telemetry latest
  action enrich site=line-4
  action republish factory/normalized/telemetry
  action bridge postgres plant-telemetry retry
end

Actions run in listed order. Enrichment supplies literal metadata; expression evaluation is outside this dialect. Republish stays inside broker bounds. Bridge actions enqueue work for nginz-iot-bridge; they do not open a client from nginz-iotd.

Max and Enterprise include the rules capability; Pro/Core omits it. Inspect loaded generations from the operator console Rules page or the operator CLI (ngz-iot rules).