Rulescript: Multi-Domain Rule Scripting

• Rulescript is a designation for systems that couple compact, domain-specific rule representations with executable control, transformation, or verification mechanisms.
• It spans diverse implementations such as Lua-based 3D mesh generation, executable-English rule wikis, Maude strategy scripting, and formally verified query rewrite DSLs.
• Its design emphasizes real-time execution and formal verification through techniques like runtime synthesis, SMT solving, and error-correcting rule synthesis.

Searching arXiv for the provided topic and related papers to ground the article in current literature. In the arXiv literature, Rulescript does not denote a single standardized language. It names several distinct rule-oriented systems: a Lua-based environment for dynamic 3D mesh generation, an engine-agnostic DSL for verified query rewrite rules, an open-vocabulary executable-English wiki for business and scientific rules, and, in a related Maude context, strategy modules that control the application of rewrite rules. A closely adjacent line of work studies the synthesis of executable rule-checking scripts from natural-language specifications for chip layout verification. This suggests that Rulescript is best understood as a recurring designation for systems that combine declarative rule specification with executable control, transformation, or verification mechanisms across different technical domains (McCormack et al., 2020, Pan et al., 7 May 2026, Walker, 2011, Eker et al., 2024, Kim et al., 15 May 2026).

1. Terminological scope and recurrent design pattern

Across these works, the common element is not a shared syntax but a shared architectural motif: rules are written in a compact, domain-oriented representation and then executed, interpreted, verified, or strategically controlled by a runtime system. In procedural modelling, Rulescript is “the authors’ name for their Lua-based rule scripting” embedded in a live 3D environment (McCormack et al., 2020). In database optimization, RuleScript is an “engine-agnostic domain-specific language (DSL) for developing query rewrite rules” with formal verification (Pan et al., 7 May 2026). In executable English, Rulescript is an online wiki-like system for authoring and running rules in “open vocabulary, executable English” through a browser (Walker, 2011). In Maude, the relevant notion is a strategy language that separates rewrite rules from the control programs that direct their application (Eker et al., 2024). In VLSI verification, the neighboring problem is the translation of natural-language rules into executable DRC scripts and the execution-grounded evaluation of such scripts (Kim et al., 15 May 2026).

Usage	Core representation	Execution model
Dynamic 3D meshes	Lua module plus parametric, timed L-system rules	setup() / update(dt) loop with live rendering
Query rewriting	Core relational operators plus optional custom operators	Match/transform pipeline with one-time formal verification
Executable English	English-like premises, underline, English-like conclusion	Hybrid backward/forward chaining and SQL generation
Maude strategies	Strategy expressions over rewrite rules	Controlled rewrite search in Maude
DRC script synthesis	Natural-language design rule to DRC script	Compilation and execution on private chip layouts

The recurrent design choice is the tight coupling of declarative rule specification with an execution substrate that exposes correctness through runtime behavior rather than through surface-level textual similarity. That emphasis is explicit in the DRC setting, where evaluation is grounded in DRC execution outcomes rather than code similarity (Kim et al., 15 May 2026). A plausible implication is that the term Rulescript has been repeatedly adopted in settings where rule authoring and executable semantics are intended to remain close.

2. Lua-based Rulescript for dynamic 3D mesh generation

In “A scriptable, generative modelling system for dynamic 3D meshes,” McCormack, Porter and Wetter describe Rulescript as a “tight coupling” between a small domain-specific scripting API embedded in Lua, a parametric, timed L-system interpreter written in Lua, a set of dynamic mesh-creation operators built on top of a C++ runtime, and a live development environment with immediate visual feedback (McCormack et al., 2020). Every Rulescript is a Lua module file containing exactly two special functions:

$$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$9

When “PLAY” is pressed in the GUI, the implementation loads the module, calls setup(), and then enters a loop calling update(dt) at a steady rate such as 60Hz. The exposed API is organized into mesh creation, mesh manipulation, and transforms plus scene management. The creation layer includes cube(), sphere(), icosahedron(), iso(resolution, densityFunction), new_lsystem(axiom,ruleList), and turtle primitives for generalised cylinders. The manipulation layer includes extrude(vertex,dir,length), inset(vertex,scale), flattenvl(mesh,vertexList,p,n), mesh:smooth_subdivide(levels), mesh:sync(), loopv(v), and nearbyv(v,n). Scene management includes fgu:add(meshnode(m)), T(vec3), S(vec3), R(angle,axis), Rv(fromVec,toVec), and operator-overloaded vec3, mat4, and quat userdata (McCormack et al., 2020).

Rules are encoded as strings parsed by new_lsystem(). The system tokenizes the axiom, parses each rule string into a Lua table with predecessor, parameters, condition, successor symbols, and successor parameters, and then applies a derive(dt) procedure. In that procedure, each symbol’s age is incremented by dt; a matching rule is located; the condition is evaluated via Lua’s loadstring; and, when the condition holds, the symbol is replaced by its successor with evaluated parameters. A second pass interprets the derived string through turtle commands such as move, roll, add_point, Gs, and Ge, producing a generalised cylinder or driving extrusion.

The geometry layer is mathematically explicit. A generalised cylinder is swept by moving a 2D cross-section curve $f(\theta)$ along a 3D path $P(t)$, with discrete vertex positions

$v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$

and mesh connectivity given by a regular grid on the cylinder sweep. The continuous sweep is written as

$$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$

Under the hood, Fugu uses VCGLib’s half-edge-like storage for vertices, faces and implicit edges, while the Lua side exposes vertexlist(m), facelist(m), and a pos cell-tuple with navigation primitives flip_v(), flip_e(), and flip_f() (McCormack et al., 2020).

The live development loop is central. The user edits a Lua module, presses “PLAY,” a clean Lua VM is created, setup() initializes geometry, update(dt) may derive L-systems or move vertices, mesh:sync() updates normals, VCGLib applies subdivision, and the 3D view is redrawn. The paper states that the cycle takes “a fraction of a second for small to moderately sized meshes (a few thousand faces).” This environment is therefore not only a rule syntax but an executable modelling workflow in which rule changes are immediately materialized as dynamic mesh transformations (McCormack et al., 2020).

3. Open-vocabulary executable-English Rulescript

In Adrian Walker’s “A Wiki for Business Rules in Open Vocabulary, Executable English,” Rulescript is an online system for collaboratively writing and running business and scientific applications as rules in English through a browser (Walker, 2011). A rule consists of one or more English-like premises, a horizontal underline, and a single English-like conclusion. Variables are written as placeholders such as “some-item1,” “that-class,” or “that-email,” while everything else may be any sequence of words or symbols, including jargon, acronyms, ungrammatical fragments, or mathematical notation.

A representative rule from the semantic resolution example is:

$$Facts_{i+1} = Facts_i \cup \{ C\sigma \text{ such that there exists a rule } P_1,\ldots,P_n \Rightarrow C \text{ and a substitution } \sigma \text{ with } \{P_1\sigma,\ldots,P_n\sigma\}\subseteq Facts_i \},$$0

The system enforces several syntactic constraints: every variable in the conclusion must also occur in a simple non-negated premise; every variable in a negated premise must have been introduced earlier in simple premises; and rules must not form a negative cycle. Semantically, the English interface is backed by a model-theoretic semantics “in the style of declarative logic programming and deductive databases.” The least-fixpoint construction is given as

$$Facts_{i+1} = Facts_i \cup \{ C\sigma \text{ such that there exists a rule } P_1,\ldots,P_n \Rightarrow C \text{ and a substitution } \sigma \text{ with } \{P_1\sigma,\ldots,P_n\sigma\}\subseteq Facts_i \},$$

with program meaning

$Facts^\infty = \bigcup_i Facts_i.$

The paper also gives a sequent-style proof rule:

$$\frac{\Gamma \vdash P_{1}\quad \Gamma \vdash P_{2}\quad \dots \quad \Gamma \vdash P_{n}} {\Gamma \vdash C}.$$

Because the engine interleaves forward and backward chaining, the declarative semantics is stated to remain valid regardless of rule order (Walker, 2011).

Execution uses a hybrid backward/forward-chaining method called “backchain iteration.” A user poses a query by selecting or typing a generalized sentence; the engine backward-chains from the goal to identify rules that could produce it; premises matching stored facts are discharged immediately; and the engine may switch to forward search to discover new facts satisfying remaining premises. When all premises are shown true, the consequent is asserted as a new fact. The details state that, because the engine tracks dependencies and avoids negative cycles, it is “terminating, sound and complete with respect to the declarative model” (Walker, 2011).

For larger data, the system automatically synthesizes SQL. Variables become column aliases, sentences become SELECT…FROM…WHERE clauses, and joins arise from repeated placeholders across premises. The same rule base therefore drives both in-memory inference on small fact sets and SQL over networked relational databases on large tables. The paper further emphasizes explanation: every derived result, and every missing expected result, can be explained through hypertexted English justification. Explanations begin with a one-sentence summary and allow drill-down into each inference step, with missing premises marked “missing” and absent conclusions marked “not shown” (Walker, 2011).

This version of Rulescript is notable for making natural-language rule authoring executable without a fixed dictionary or grammar. Its rule language is open-vocabulary, but its semantics are explicitly logical and operationally connected to both inferencing and relational query generation.

4. Strategy-oriented rule scripting in Maude

“The Maude strategy language” presents a different but related sense of rule scripting: a formal language for controlling the application of rewrite rules in Maude specifications (Eker et al., 2024). The core system module provides terms, equations, and rewrite rules; the strategy module specifies how those rules should be applied to reduce nondeterminism, capture goal-oriented behavior, or impose priorities.

The basic strategy expressions are idle and fail. Rule application has the form $$Facts_{i+1} = Facts_i \cup \{ C\sigma \text{ such that there exists a rule } P_1,\ldots,P_n \Rightarrow C \text{ and a substitution } \sigma \text{ with } \{P_1\sigma,\ldots,P_n\sigma\}\subseteq Facts_i \},$$1 where Label selects a rule by name, the optional bracket pre-instantiates rule variables, and the optional braces assign one sub-strategy to each rewriting-condition fragment. By default, matching occurs anywhere in the term, while top(...) restricts matching to the root. Tests include match P s.t. Cond, amatch P s.t. Cond, and xmatch P s.t. Cond. The regular-expression-style combinators are sequential composition α ; β, nondeterministic alternation α ∣ β, and iteration α*, together with derived operators:

• α+ ≡ α ; α*
• α or-else β ≡ α ? idle : β
• not(α) ≡ α ? fail : idle
• try(α) ≡ α ? idle : idle
• test(α) ≡ not(not(α))
• α! ≡ α* ; not(α)
• one(α)

The operational semantics is presented as a small-step SOS over configurations $\langle t @ \alpha \rangle$. For example:

• (Idle) maps $\langle t @ idle \rangle$ to $\{t\}$.
• (Fail) maps $P(t)$0 to $P(t)$1.
• Sequential composition pushes the second strategy onto a continuation.
• Alternation branches nondeterministically.
• Iteration supports both zero copies and recursive expansion into α ; α*.
• The conditional α ? β : γ runs β on every solution of α, otherwise γ on the original term (Eker et al., 2024).

Rule application semantics is stated in terms of matching a labeled rule, executing the rewrite-condition fragments under their associated sub-strategies, composing the resulting substitutions, and returning the instantiated right-hand side. The implementation history is also explicit. The first implementation used Maude’s reflective features, but the strategy language was later implemented in C++ “as an integral part of the Maude system” for efficiency. Runtime execution maintains a set of “processes” in a circular list, where each process carries a current subject term, a stack of pending strategy expressions, and a variable-substitution environment. Breadth-first srewrite uses a fair round-robin scheduler, while depth-first dsrewrite reuses the same machinery with a stack discipline (Eker et al., 2024).

The details report engineering measures for efficiency: hashing (term, strategy-stack) pairs to avoid revisiting identical search states, interning strategy expression lists as shared persistent stacks, and direct inlining for single-definition strategies. Benchmarks on examples including the 15-puzzle, Sudoku, neural-network inference, ambient-calculus simulation, and completion procedures show “speedups of 10×–1000× in total user time, and 5×–30× reduction in peak memory over the metalevel prototype” (Eker et al., 2024).

Although this work does not use Rulescript as a formal product name in the same way as the Lua or executable-English systems, it exemplifies the same broad idea: a rule system augmented with an explicit scripting layer that controls execution while preserving a clean separation between rules and their strategic application.

5. RuleScript as an engine-agnostic, formally verified query-rewrite DSL

“An Extensible and Verifiable Language for Query Rewrite Rules” defines RuleScript as a DSL for logical query plan rewriting that is both engine-agnostic and formally verified (Pan et al., 7 May 2026). The design goals are stated as engine-agnostic specification, universally quantified verification, and lightweight integration. The language separates rule definition from execution infrastructure via a relational algebra-inspired core language and an explicit decomposition of rules into matching and transformation phases.

The core grammar is:

$$Facts_{i+1} = Facts_i \cup \{ C\sigma \text{ such that there exists a rule } P_1,\ldots,P_n \Rightarrow C \text{ and a substitution } \sigma \text{ with } \{P_1\sigma,\ldots,P_n\sigma\}\subseteq Facts_i \},$$2

Here, $P(t)$2 ranges over uninterpreted type symbols, $P(t)$3 over uninterpreted scalar functions, $P(t)$4 over uninterpreted aggregates, and $P(t)$5 over uninterpreted plan symbols. Under the bag-semiring model used by QED, operator semantics are written as

$P(t)$6

$P(t)$7

and equivalence of plans $P(t)$8 is

$P(t)$9

Every rule is a triple $v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$0. Matching traverses a concrete plan top-down and binds uninterpreted symbols to concrete instances. Transformation walks $v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$1 bottom-up and rebuilds a rewritten plan with the same bindings. Pattern-matching primitives include plan symbols such as L:Bag<X>, conjunction flattening and partitioning of predicates by column dependency, and both positional and dependency-based type instantiation strategies (Pan et al., 7 May 2026).

Formal verification is central. Instead of invoking an equivalence solver at runtime, RuleScript verifies each rule once by reducing it to a QED validity check:

$v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$2

Custom operators are expanded into core operators by their semantics definitions; the match and transform patterns yield core-only QED plans; QED lowers them into normalized semiring expressions and calls an SMT solver; and a successful proof establishes soundness for all instantiations. The language is also extensible through user-defined operators with names, signatures, output types, and semantic expansions. The paper’s SemiJoin example is: $$Facts_{i+1} = Facts_i \cup \{ C\sigma \text{ such that there exists a rule } P_1,\ldots,P_n \Rightarrow C \text{ and a substitution } \sigma \text{ with } \{P_1\sigma,\ldots,P_n\sigma\}\subseteq Facts_i \},$$3 Verification in-lines the custom node, whereas execution keeps it opaque and relies on a handler supplied by the engine adapter (Pan et al., 7 May 2026).

Integration supports an interpreter path and a code-generation path. The interpreter path is intended for engines such as DataFusion that expose a generic rewrite(plan)→plan hook; the code-generation path targets engines such as Calcite and CockroachDB that expose native pattern-rule DSLs. The common steps are to write RuleScript patterns, run the verifier, invoke the adapter, and then compile or link the generated rules into the optimizer (Pan et al., 7 May 2026).

The evaluation reimplements 33 Apache Calcite rewrite rules, deploys them to Apache Calcite, CockroachDB, and Apache Data Fusion, and reports both engineering and performance outcomes. A lines-of-code table gives 1051 lines total for RuleScript across 33 rules, versus 3877 lines in Calcite Java and 594 lines in Cockroach Optgen, with a Median/rule of 21, 94, and 18, respectively. The paper states that RuleScript is “on average ~3.7× more concise than Calcite’s Java and comparable to a purpose-built DSL.” Adapter integration totals are 518 LOC for Calcite, 836 for CockroachDB, and 1657 for DataFusion. Per-rule unit tests all passed; 22 TPC-H queries saw “up to 1.5× geometric mean speedup in CockroachDB and similar improvements in DataFusion when RuleScript rules were enabled”; and matching plus transformation overhead is described as negligible relative to cost-based planning (Pan et al., 7 May 2026). In this setting, RuleScript functions as a verified portability layer for optimizer rule engineering.

6. Execution-grounded rule-to-script synthesis and the broader Rulescript landscape

A recent adjacent development is the execution-grounded benchmarking of agents that synthesize executable scripts from natural-language rules in semiconductor verification. “Rule2DRC: Benchmarking LLM Agents for DRC Script Synthesis with Execution-Guided Test Generation” is not itself a Rulescript language, but it addresses a closely related problem: translation from human-readable rules to working executable rule-checking scripts (Kim et al., 15 May 2026).

The benchmark contains 1,000 distinct rule-to-script tasks and 13,921 private evaluation layouts, beginning with 310 real rules from the open-source SkyWater130 PDK, adding 490 synthesized “multi-constraint” rules, and 200 “syntax coverage” rules. The evaluation layouts are private and not visible to the agent. Each generated script is compiled and run by KLayout, and its outputs are compared against those of a reference script. The paper defines a DRC engine

$v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$3

where $v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$4 if script $v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$5 reports a violation on layout $v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$6, otherwise $v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$7. For task $v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$8, with natural-language rule $v_{i,k} = P(t_i) + R_i \cdot f(\theta_k),$9, ground-truth script $$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$0, and evaluation layouts $$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$1, an agent $$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$2 solves the task if

$$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$3

Overall functional correctness is measured by

$$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$4

where $$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$5 only when all evaluation layouts match. The benchmark also defines an error rate and a per-layout score

$$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$6

This is an explicitly execution-based notion of correctness (Kim et al., 15 May 2026).

The benchmark also introduces SplitTester, a two-phase tester agent for Best-of-$$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$7 program selection. It first generates initial test layouts, asks the LLM for expected outcomes, executes all candidate scripts, scores them by agreement with the expected labels, and clusters scripts that are indistinguishable on the current tests. It then iteratively selects the target cluster

$$P(t)\in\mathbb R^3,\quad f(\theta)\in\mathbb R^2,\quad X(t,\theta)=P(t)+R(t)f(\theta).$$8

samples up to K=3 representative candidates, asks the LLM to generate a new discriminative test layout, runs that layout on all candidates, updates scores and reclusters, and early-stops when it fails to split the same cluster P times in a row, with P=1 by default. A final judge takes the top 3 candidates and asks the LLM to select the best one given the layouts on which they disagree (Kim et al., 15 May 2026).

Reported Best-of-20 results, averaged over three runs, are:

• Qwen3-30B: Sample-1 pass@1=14.1%; BoN-20 CodeMonkey=17.2%; SplitTester=18.0% (+0.8 pp).
• GPT-OSS-20B: Sample-1=16.9%; BoN-20 CodeMonkey=41.1%; SplitTester=44.4% (+3.3 pp).
• [GPT-OSS-120B](https://www.emergentmind.com/topics/gpt-oss-120b): Sample-1=32.5%; BoN-20 CodeMonkey=62.7%; SplitTester=63.8% (+1.1 pp).

The paper further states that providing a condensed KLayout API reference of approximately 60 K tokens in context boosted GPT-OSS-120B pass@1 by 20 pp and pass@20 by 40 pp, and that preliminary iterative revision for up to M=3 rounds reduced error from 4.2% to 2.7% on GPT-OSS-120B (Kim et al., 15 May 2026).

Within the broader Rulescript landscape, this benchmark is significant because it shifts attention from authoring rule scripts directly to synthesizing them automatically and validating them through execution. A plausible implication is that contemporary work on rule scripting is increasingly concerned not only with language design and runtime semantics, but also with benchmark construction, execution-grounded correctness, and agentic test generation for selecting among multiple candidate programs.