Home

Nodora_

A modern rule engine with a declarative language for writing maintainable business rules.

  • Programming Language
  • Compiler
  • CLI

[ github ] [ live ]

Nodora ruleset code and CLI evaluation output

Nodora exists because of a pattern I kept running into on real projects: the most important logic in the system (who gets approved, what tier a customer lands in, when an account gets flagged) was also the logic in the worst shape. It lived as if statements scattered across services, written by different people in different years. Changing a threshold meant a code change, a review, and a deploy. And the people who actually owned those rules (product, compliance, operations) couldn’t read a single line of them.

That’s a business problem wearing a technical costume, so I built a small language for it.

A Nodora ruleset is a flat, readable file: constants, rules, and the signals a rule can emit. It compiles once, then evaluates against a JSON input and answers two questions: what is true about this input (outputs) and what should happen next (signals).

signal BlockAccount(user_id)

const ALLOWED = ["us", "ca"]

rule AccountApproval {
    is_adult = input.age >= 18
    eligible = is_adult && input.country in ALLOWED

    emit BlockAccount(input.user_id) when !eligible
    out approved = eligible
}

The design decisions all trace back to the pain that started it:

  • No loops, no mutation, no I/O. A rule is a pure function. You can read one and know everything it does: there is nowhere for surprises to hide.
  • Type-checked at compile time. The classic rule-engine failure mode is discovering at 2 AM that someone compared a string to a number. Nodora refuses to compile it instead.
  • Missing data doesn’t explode. Real-world inputs are always partial. Reading an absent field yields undefined, which propagates quietly instead of crashing and simply vanishes from the output.
  • Decisions are separated from actions. Rules emit signals; what a signal does is wired up outside the ruleset. The rule file stays a document of policy, not a script of side effects.

The result is that a rule change is a one-line edit to a file that any developer can easily review: no redeploy, no archaeology through application code. That’s the whole point.