# Rule Engines and Fixpoint Evaluation A reference for query engines whose core work is inference, recursion, or repeated rule application. --- ## Short answer Not all query engines are centered on SQL-style scans, joins, and aggregates. Some are organized around: - facts - rules - recursion - derivation until no new information appears That is the world of rule engines, Datalog engines, and chase-style systems. --- ## The core idea Instead of asking only for direct data retrieval, a rule engine often asks: - what facts follow from these rules? - what closure or least fixpoint do these inputs imply? - what new values must exist to satisfy constraints? This makes the engine iterative in a deeper way than many classical relational plans. --- ## Fixpoint evaluation Fixpoint evaluation means: 1. start with known facts 2. apply rules 3. add newly derived facts 4. repeat until nothing new is produced That final stable state is the fixpoint. This is central to: - recursive Datalog - transitive closure - many inference systems --- ## How this differs from standard relational execution Relational engines often execute one finite plan over a fixed input. Rule engines often need: - iterative scheduling - duplicate elimination - dependency tracking - recursion support - possibly witness generation or equality merging So the runtime model is often different even when some individual operators overlap. --- ## Why this matters Rule/fixpoint execution is especially relevant when the system needs: - recursive reasoning - closure computation - derivation of implicit facts - chase-like enforcement of dependencies This makes it a natural topic whenever query engines overlap with logic or theorem-like data processing. --- ## Practical mental model Standard query engines answer: - what result follows from this query over this data? Rule engines also ask: - what additional facts become true once the rules have run to completion? That is the essential distinction. --- ## Changelog * **April 1, 2026** -- First version created.