What each openEHR CDR did when the catalogue was driven against it
Every row below is a registry entry somebody added by pull request. The entry carries the catalogue revision that ran, the statement the claim was judged against, the machine, what was switched on, and the artifacts the numbers come out of. CI validates all of that before a maintainer looks at it, and the merge is the publication.
An entry is a report, never a certificate. It says what happened when one version of one system was driven by one version of this instrument. It is not a certification, not a mark, and not a statement of fitness for any purpose. Certification belongs to openEHR governance, and this registry is shaped to hand over: public rules, self-carrying evidence, no proprietary step.
Two tiers, labelled on every row
A reproduced row was produced by the workflow in this repository. It composed the deployment from a recipe committed here, drove the catalogue, and attested the artifacts from that workflow identity through Sigstore. No signing key exists anywhere in this repository, so there is none to steal. A self-reported row was produced by the submitter and signed with their own key or identity, and the row prints the command that checks it.
Percentages are taken over cases that were actually driven. A case the claim did not select, or that the deployment could not offer, is neither a pass nor a failure, so the row prints driven against selected beside the share.
No conformance entry has been merged yet. The first one to arrive will be the first row.
Written for someone who has never seen the instrument
What a verdict is. The catalogue is a set of small cases, each citing the released openEHR section that assigns its expected answer. A run drives them against a live deployment and records the exchanges; the verdicts are pure functions over those recordings. A failed case names one behaviour, which is what makes a red row worth reading.
Inconclusive is not failure. An exchange that errored in transport, or a step that could not be resolved, proves nothing about the behaviour under test. Those rows are counted separately and never folded into the failure count.
What a profile verdict means. CORE, STANDARD and OPTIONS are capability
tiers. A tier passes when every capability it requires passed. A tier the party
never claimed reads not_claimed rather than failing.
Why the disclosure matters. Two runs of the same catalogue against the same product can differ because the deployments differ. Every row states what was switched on, which statement the claim was judged against, and which interest the submitter holds in the outcome.
Superseded rows stay. Entries are append-only. A correction is a new entry naming the one it replaces, and the replaced row keeps its place with a pointer forward, so the record of what was published never quietly changes.
Run the catalogue, open a pull request
Point the instrument at your deployment through an IXIT that describes its topology, judge the results against your statement, and commit the entry beside the artifacts it stands on.
$ veredictum run --root artifacts --ixit ./my-ixit.json \
--sut-name my-cdr --sut-version 1.2.3 \
--statement party/my-cdr/statement.json --out ./run
$ veredictum verdicts --statement party/my-cdr/statement.json \
--results ./run/results.json --root artifacts --out ./judgementThen copy results.json and verdicts.json
into registry/records/<system>/<entry-id>/, sign one of them, write
the entry under registry/entries/conformance/<system>/ and open a pull
request. The submission rules, in full →