Installation

The zeroth way installs nothing: the official instrument at console.veredictum.eu browses the catalogue and drives runs against a publicly reachable CDR, and a run there produces an official record. Everything below is for running the instrument yourself, which publishes your own claim and works offline.

Four ways end at the same place: a veredictum you can point at a catalogue. Pick by what you already have installed. Whichever you pick, you also want a clone of the repository, and the next section says why.

What you need, and why a clone is part of it
With cargo
With Docker: the web console
From a release binary
From source
Checking that the install works

What you need, and why a clone is part of it

The instrument reads three things at run time: the catalogue, the vendored specification oracle, and your own declaration of the deployment under test. It reads all three as paths you pass on the command line, so the code and the data travel separately.

That split is deliberate. The catalogue and the specification oracle together are over 300 MB of data, which no package registry accepts, and an operator may legitimately want to point the instrument at a catalogue of their own. So the published crate and the published image carry the code, and a clone of the repository is where the data lives:

git clone https://github.com/Vernum-Projecten/Veredictum
cd Veredictum

The four ways below all run the same subcommands against that clone.

With cargo

The binary is on crates.io. Take this path if you want the command on your PATH.

cargo install veredictum --locked
veredictum validate --root artifacts --specs specs/openehr

--locked is worth understanding rather than copying: it builds against the Cargo.lock the release was tested with. Leave it off and cargo resolves fresh versions of every dependency, which is a different build from the one the project’s gates ran.

The library target is published with the binary, so you can consume the typed artifact model and the published JSON Schemas directly rather than reimplementing the format.

With Docker: the web console

The container image is the web console: a browser frontend over the same instrument, served by its own binary. The CLI is deliberately not distributed as an image: a static binary needs no container, and the release binaries below are its no-toolchain path.

The fastest start is the operator compose file, which pins the image to the version it shipped with and binds the console to loopback on port 3210:

curl -LO https://raw.githubusercontent.com/Vernum-Projecten/Veredictum/main/docker/docker-compose.yml
docker compose up

Open http://127.0.0.1:3210. Releases cut after v0.1.1 attach the same file to the release page, pinned to that release’s image. The equivalent docker run, if you would rather not use compose:

docker run --rm -p 127.0.0.1:3210:3000 -v "$PWD:/work" \
    ghcr.io/vernum-projecten/veredictum:<tag>

Substitute a published tag from the package page for <tag>. The image is multi-architecture and is pushed by digest, with its tags applied only after a smoke run and a vulnerability scan of that digest have passed.

The catalogue and the specification oracle are not baked into the image either, so the data you grade against is the data you can see in your own checkout: run compose beside a clone and the /work mount carries artifacts/ and specs/openehr/; run it beside an empty directory and the console comes up and says what it is missing. The console has no login, so both invocations above bind it to loopback; exposing it further is the operator’s decision, behind their own gate. The console chapter shows what it does today.

From a release binary

Prebuilt binaries for x86_64 and aarch64 Linux are attached to every release. Each tarball ships with a sha256sum, a CycloneDX dependency SBOM and a Sigstore bundle.

Verify the bundle before you run the binary. The check that matters is not just “this file is signed” but “this file was built by the workflow in this repository”, which is what --signer-workflow asserts:

gh attestation verify veredictum-<tag>-<target>.tar.gz \
    -R Vernum-Projecten/Veredictum \
    --signer-workflow Vernum-Projecten/Veredictum/.github/workflows/release-build.yml

A release is created as a draft and published only once every expected asset is attached, so you never meet a release whose binaries are still uploading. Its tag is signed, and a repository rule refuses to delete one, so a tag is never re-pointed at different code. The recovery path for a bad cut is the next version.

From source

The toolchain pins itself from rust-toolchain.toml, so you do not choose a Rust version:

cargo run -- validate --root artifacts --specs specs/openehr

The declared minimum supported Rust version is 1.96, verified in CI against that floor rather than assumed. The only extra tool is cargo-nextest, and only if you intend to run the project’s own test suite.

Checking that the install works

validate is the check to run first, because it needs no server:

veredictum validate --root artifacts --specs specs/openehr

A working install over an intact clone prints one line and exits zero:

1146 case(s), 249 binding(s), 43 capability row(s), 0 finding(s)

Any finding count above zero is a failure of the catalogue, not of your setup, and the findings printed above that line say which artifact is at fault. A missing --specs tree is the common first-run mistake: the citation and Service-Model gates are skipped without it, so the case count is reported while the checks that make the count meaningful never run.

Keyboard shortcuts