regelrecht

Machine-readable Dutch law execution. regelrecht takes legal texts, encodes them as structured YAML, and runs them as deterministic decision logic.

What does it do

• The engine takes a regulation and a set of inputs, evaluates the decision logic, and returns a result with a full explanation trail
• Laws are tested against real-world scenarios using BDD (Gherkin) tests, many derived from legislative explanatory memoranda. The vocabulary those scenarios speak lives in bdd/grammar.yaml and every engine's step bindings are generated from it
• A harvester downloads and tracks Dutch legislation from the official BWB repository
• Regulations can be edited through a web UI with live execution preview

Components

Rust packages

Package	Description
packages/engine/	Law execution engine (also compiles to WASM)
packages/law-model/	The Rust representation of the law format, conforming to schema/
packages/harvester/	Downloads Dutch legislation from BWB
packages/pipeline/	PostgreSQL job queue for law processing
packages/admin/	Harvester-admin API; its dashboard UI lives in the editor
packages/editor-api/	Backend API for the law editor
packages/corpus/	Git integration for the regulation corpus
packages/auth/	Shared OIDC/SSO authentication
packages/github/	Shared GitHub REST client
packages/shared/	Shared domain types across crates
packages/arch-extract/	Derives the architecture model from the code (just arch-explore)
packages/tui/	Terminal dashboard (Ratatui)

Frontends and sites

Directory	Description
frontend/	Law editor UI (Vue 3 + Vite)
frontend-lawmaking/	Law-making process visualization (Vue 3 + Vite)
packages/frontend-shared/	Shared frontend primitives (auth, colour scheme, API fetch)
docs/	Astro site: landing page + documentation

Data and testing

Directory	Description
corpus/regulation/	A working set of regulations in machine-readable YAML, plus synthetic test_* laws
schema/	Versioned JSON schema for the law format (schema/latest points at the current version)
bdd/	The Gherkin vocabulary (grammar.yaml) and the engine-conformance suite
corpus/regulation/**/scenarios/	Law-validation scenarios, next to the law they test
packages/grafana/	Grafana monitoring dashboards (provisioning, not a crate)

The full corpus lives elsewhere

corpus/regulation/ in this repo holds a couple of dozen laws: the ones the tests and BDD scenarios run against, plus synthetic test_* laws for the conformance suite. The harvested body of Dutch legislation is far too large to carry here and lives in its own repository:

MinBZK/regelrecht-corpus — currently some 22,000 YAML files under regulation/nl.

Which branch you want depends on what you are after:

Branch	What is on it
development	The working branch, and what corpus-registry.yaml points this repo at. Harvested laws land here first
main	Only moves when development is merged into it, so it lags
enrich/*	Output of the enrichment runs, one branch per enricher (enrich/claude, enrich/opencode)

Short-lived prN and editor/* branches belong to preview deployments and editor sessions; they are not meant to be read directly.

Deployed services

Service	URL
Editor	https://editor.regelrecht.rijks.app
Landing page	https://regelrecht.rijks.app
Documentation	https://docs.regelrecht.rijks.app
Law-making	https://lawmaking.regelrecht.rijks.app
Harvester admin	https://harvester-admin.regelrecht.rijks.app
Grafana	https://grafana.regelrecht.rijks.app

The pipeline API and the harvester and enrich workers deploy alongside these but have no web UI of their own.

A PR gets a preview environment once it carries the deploy:preview label; taking the label off, or closing the PR, cleans it up again.

Getting started

Prerequisites: Rust (stable) and just.

just check           # everything CI runs (format, lint, build, validate, tests)
just test            # every Rust test in the workspace
just test-no-docker  # the same, minus the container-backed suites
just bdd             # the BDD suites: law scenarios and engine conformance

just test and just check start PostgreSQL containers for the crates that need one, so they want a Docker daemon. Without one, just test-no-docker covers everything else. just bdd runs separately: it executes against the real corpus and is deliberately not part of just test.

Faster builds (recommended)

Run just dev-setup once. It does three things:

1. Points every worktree at one shared target dir — a new worktree reuses the already-built dependency graph instead of cold-building ~600 crates.
2. Puts that target on fast local storage when the repo lives on a slow mount. A Rust build writes tens of thousands of small files; on a 9p/NFS/SMB mount (e.g. a WSL2 or Docker-Desktop dev container where the repo is a Windows drive) that I/O dominates build time — often more than everything else combined. dev-setup detects this and relocates the target to ~/.cache/regelrecht/ (local disk). This is usually the single biggest win.
3. Installs mold + sccache. mold (wired into packages/.cargo/config.toml) speeds up linking and is a hard requirement for the dev recipes; sccache is installed but left off locally.

sccache is disabled locally because it requires CARGO_INCREMENTAL=0 and so disables incremental compilation — which hurts the just dev edit-rebuild loop. Enable it only for cold or flag-varying builds:

export RUSTC_WRAPPER=sccache CARGO_INCREMENTAL=0

CI uses both mold and sccache (see .github/workflows/ci.yml).

Running a dev stack

just dev               # full native dev stack (admin + both frontends + grafana/prometheus)
just dev-frontend            # all frontends (editor 7300, admin 7400, lawmaking 7500), no observability
just dev-frontend editor     # just the editor (editor-api + editor UI + DB)
just dev-frontend admin      # just the admin API + admin UI + DB
just dev-frontend lawmaking  # just the lawmaking UI (no backend)
just dev-down          # stop whichever of the above is running

dev-frontend with no argument starts every frontend; pass editor, admin, or lawmaking to start just one. Either way it starts only the components those frontends need — no grafana, prometheus, or workers. The editor runs with real SSO against the central Keycloak, so it needs .env.sso-local (copy .env.sso-local.example). It and just dev are mutually exclusive (they share .dev-pids and ports) — run one at a time.

Vite ports default to 7300/7500 (overridable via EDITOR_PORT / LAWMAKING_PORT). When a native backend can't reach Postgres on localhost (e.g. a WSL2/Docker-Desktop dev container, where Postgres is published on the Docker host), point it at host.docker.internal: for the admin / just dev paths set DB_HOST=host.docker.internal in .env; for the editor that host comes from DATABASE_URL in .env.sso-local (the .env.sso-local.example already uses host.docker.internal).

See the docs site for full development instructions.

License

EUPL-1.2