Turn business policies
into deterministic decisions.

The problem

Business policies rarely live in one place.

The solution

One policy. Executable decision logic.

Use cases

Where RuleDSL fits

RuleDSL fits policy domains where explicit inputs should produce a reviewable decision through approved rule logic.

A policy in RuleDSL

Readable conditions. Explicit outcomes.

This compensation example uses the shipped v0.9 language surface: the first matching rule wins, assignments become output fields, and the action is one of the documented decision actions.

rule annual_bonus_eligibility {
  when employment_status == "active"
       and service_months >= 6
       and performance_rating >= 3;
  then reason = "policy_requirements_met",
       allow;
}

rule annual_bonus_ineligible {
  when true;
  then reason = "policy_requirements_not_met",
       decline;
}

{
  "matched": true,
  "action": "ALLOW",
  "rule_name":
    "annual_bonus_eligibility",
  "outputs": {
    "reason":
      "policy_requirements_met"
  }
}

One language, many policy domains. The same language can represent pricing, compliance, risk and approval policies.

Why deterministic

Correct once is not enough.

In regulated and high-trust systems, a decision may need to be explained months or years later. RuleDSL is designed so that the same engine and ABI pairing, verified rule artifact, canonical input and equivalent evaluation options can reproduce the same decision output on supported platforms.

Scope matters. Determinism depends on the documented engine/ABI, bytecode, canonical input, equivalent evaluation options and supported-platform conditions. Published evidence covers the committed DET corpus; it is not a formal proof over every possible rule and input. Inspect the determinism evidence.

Model Context Protocol

AI invokes. The engine decides.

RuleDSL exposes an MCP interface for AI assistants and agents. Clients can discover approved rules, provide structured case data and request an evaluation. They cannot rewrite production rules or replace deterministic execution with model judgment.

# 1. Discover approved identifiers and schemas
list_rules()

# 2. Invoke an identifier returned by list_rules
evaluate_case(
  rule_id="<approved_rule_id>",
  fields={"case_field": "explicit_value"},
  now_utc_ms=1700000000000
)

# 3. Inspect the decision record and any
#    rule-assigned output fields, such as reason

Early access. MCP support is currently experimental early access and is not yet part of the frozen compatibility contract. The AI client remains responsible for rule selection and field extraction; mistakes there are outside the engine's determinism guarantee. Read the MCP quickstart and MCP design contract.

Workflow

Write → Compile → Verify → Evaluate

Technical architecture

Built for embedded decision systems

RuleDSL is integrated into a host application. The host owns deployment, input preparation, persistence, lifecycle and any stateful enforcement around the decision call.

Current documented pairing: engine/binary bundle v1.0.2; language implementation v0.9 with v1.0 as the target specification; Python package 1.2.0; MCP surface 0.2.0 experimental. The raw C API requires one compiler per thread or external synchronization, separate decision buffers and documented lifetime ordering. The Python and C# wrappers serialize calls per instance. Malformed bytecode passed directly to evaluation and invalid pointer, ownership or lifetime use can be undefined behavior; follow the verification and undefined-behavior contract.

Evidence

Claims backed by inspectable artifacts

Published evidence is recomputable for the committed scenarios and artifacts. It is evidence of observed results, not a formal proof over all possible inputs and rules. Broader multi-host and independent third-party reproduction remain open.

Developers

Get started with RuleDSL

Start with the binding that fits your host. Keep the engine library and SDK version pairing explicit during evaluation and deployment.

from ruledsl import RuleDSL

with RuleDSL("path/to/ruledsl_capi.dll") as engine:
    artifact = engine.compile("""
        rule bonus_policy {
          when service_months >= 6;
          then reason = "minimum_service_met", allow;
        }
    """)
    compatibility = engine.check_compatibility(artifact)
    decision = engine.evaluate(artifact, {"service_months": 12})
    if compatibility["compatible"] and decision.matched:
        print(decision.action, decision.outputs)

Separate delivery model. The Python package provides the binding and Workbench. The native engine library is delivered separately in the RuleDSL release bundle.

System boundaries

Clear system boundaries

This public repository contains the SDK integration surface, bindings, examples, documentation and evidence. The native engine is separately delivered as a licensed binary under the applicable evaluation or commercial terms.