CI scripts that validate the YAML regulations repo. Each is invoked
from Makefile, from package.json scripts, and from
.github/workflows/validate.yml.
Looking for the TARIC database pipeline? That's a separate subsystem under
taric/— sync, ingest, schema migrations, derived columns, and the local TEI embeddings server. The validators here only deal with the YAML rule files inregulations/,submodels/, andtests/.
| Script | Purpose |
|---|---|
validate_dmn.mjs |
Walk every regulation under regulations/. Validate against docs/schemas/regulation.json. Check no duplicate rule IDs within a file. |
validate_fixtures.mjs |
Walk every fixture under tests/. Validate against docs/schemas/fixture.json. Confirm the referenced regulation exists. |
run_tests.mjs |
For each fixture, confirm every rationale_must_include rule_id exists in the referenced regulation. Catches drift when a regulation is edited but its fixtures aren't. |
lint_layout.mjs |
Layout invariants: filename matches regulation.id and regulation.version, every regulation has at least one fixture, fixture paths follow the convention. |
_lib.mjs |
Shared helpers (file walking, YAML loading, console formatting). Not a CLI script. |
The script validate_dmn.mjs retains its name from the pre-implementation contract. Today it validates the YAML source-of-truth (per docs/SCHEMA.md); when a YAML→DMN compiler exists, this script gains a parity check.
npm ci # install pinned deps
npm run check # everything CI runs
npm run validate # YAML structural validation only
npm run validate:fixtures
npm test # rule_id correlation
npm run lint # layout invariantsTwo reasons. (1) The eventual DMN engine of choice is dmn-eval-js, which is JS, so keeping the validators in the same runtime is one-language-to-rule-them-all. (2) No JVM warm-up keeps CI fast.