Drools / DRL

In short: Drools keeps a living memory of facts and re-evaluates incrementally as they change; Arxo re-evaluates the model from the case at hand. This page is for rule engineers who know RETE sessions and want the exact boundary: which differences are engine properties, and which are genuine semantic gaps.

Key differencesChoosing and combiningEvidence & limitations

What Drools is for

Drools is a business-rules management system: rules in the DRL language run in stateful sessions with insert, update, and retract plus fire-all-rules, or in one-shot stateless wrappers. Its strengths are managed working-memory lifecycle, incremental evaluation with truth maintenance (logically inserted facts retract automatically with cascading justification counts), ordering controls, loop guards, event listeners — and an event-processing extension with stream modes, temporal operators, and windows for monitoring and fraud scenarios where a full model with proof is overkill.

Where it meets Arxo

The shared ground is dependent rules plus change over time: the same insert-fire-update-fire-retract transitions must yield the same fired-rule sequences and final fact sets on both sides. Timing measurements and event streams are explicitly out of scope; backward chaining exists as a hybrid segment for query nodes, confirmed against the docs after an early misread.

Key differences

• Ordering is a Drools property. Salience numbers and agenda focus order rule firing; Arxo has no agenda. Cross-platform verdicts on order are not comparable — order is checked only across Drools revisions. Salience is not a priority between norms.
• Absence in memory is not an unknown fact. Negation over empty working memory diverges from Arxo’s missing-fact handling by contract class, not by defect.
• Logical retract has no Arxo counterpart. Auto-revocation with justification counting compares only by final fact set; the counting mechanism itself stays engine-side.
• Explanation is wrapper-built. There is no built-in proof certificate; listeners and debug loggers supply the trace. Arxo’s derivation graph is the engine’s own output — a genuine asymmetry, priced as such rather than celebrated.

A concrete scenario

The prepared experiment drives a stateful session through fourteen transitions — base firing, update enable and disable, retract, ordering, agenda focus, activation groups, loop guards, absence and blocked negation, stateless execution, query reads — plus three edits: a salience flip, an engine-version move, and dropping the loop guard under a non-termination watch. Fired sequences and final facts are compared against Arxo re-evaluations.

Choosing and combining

Choose Drools for long-lived stateful sessions, incremental updates over large working memories, and event-stream monitoring. Look to Arxo when the model must be re-checked from scratch against pinned sources, when conflicts need named grounds, or when editions date the answer. Combined, Drools can run the operational rule flow while Arxo audits the normative content: same transitions, reconciled fact sets, priced differences.

Evidence and open questions

• Sources checked: September 2026 (rule-engine and language-reference docs, session documentation, Maven-published artifacts, release notes; one cited doc page needed a version fallback after a 404).
• Studied profile: Drools 8.44.2.Final with docs pinned one patch behind; the next major engine line as the edit axis.
• Basis: confirmed by documentation plus a prepared protocol; comparative run not performed, commands unverified.
• Open: the engine-version source delta, one Arxo-side refusal class, and the runtime pin underlying the install instructions.

Sources and reproducible materials

• Companion page: Coming from Drools — rule branches and absence written in Arxo.
• Rule engine and language reference docs: Drools documentation
• Published artifacts: repo1.maven.org