Conformance matrix

Non-normative. This records what is true today, not what is intended. It is the file to distrust last: if it disagrees with the code, the code wins and this file has a defect.

Assessed: 2026-08-02, against rustc 1.97.1, openehr 0.2.0. Rows touched by A-36 were re-derived 2026-08-20 against openehr 0.3.0 and rustc 1.98.0; the rest carry the earlier date and have not been re-checked since, which is stated rather than papered over (W0.10). The D3.18b/D3.18c rows were derived 2026-08-21 with A-35. The K15.18–K15.23 row was derived 2026-08-30 against openehr 0.8.0, when openehr::am::validate landed. Method: each requirement read against the code that implements it and the test that exercises it; test names below are real and runnable with cargo test <name>.

Key#

Doctests count as tests: they compile and run in CI (T13.8).

Totals#

Counted mechanically from the tables below, with every requirement id in spec/*.md checked to appear exactly once — 344 ids, 344 covered, none missing.

A hand-written total in a file like this is a number nobody rechecks, and this one proved the point: it said 291 of 291 while six requirements added after the assessment had no row at all — S1.18, S1.19, S1.20, L10.9, L10.10, L10.11. "Derived from the rows" was true once and then was not.

CI now re-derives it on every push, expanding the ranges in the Id column and comparing against the requirements the specification defines. A new requirement with no row fails the build; so does a row for a requirement that does not exist, and so does an id covered twice.

Re-derived 2026-08-26, mechanically, from the rows below — and the previous numbers were wrong, which is the second time this table has drifted from its own tables. It said 291 total against 300 in the sentence above while the rows held 311, because CI re-derives coverage and nothing re-derived the tally. A-41 is the finding; the counts below were produced by expanding every Id cell and counting statuses, and re-running that is how they should be checked again.

Re-derived again 2026-08-30, the same way, after K15.18–K15.23 moved from spec to •: six ids, openehr::am::validate. Re-derived a third time the same day, after K15.24–K15.27 made the same move: four ids, openehr::am::repository and openehr::am::validate's validate_with_repository.

The spec rows are §15 plus S1.21, added on 2026-08-26 when S1.4 was withdrawn and the Archetype Model brought into scope. There were 32 of them that day; K15.1–K15.4 — the AOM2 object model — were implemented and tested the same day, leaving 28. K15.18–K15.23 — validating a Reference Model instance against an archetype already held in memory, as a verdict kept separate from L10.x and with no partial pass — followed on 2026-08-30, leaving 22. K15.24–K15.27 — the repository abstraction, and resolving a C_ARCHETYPE_ROOT filler through one — followed the same day, leaving 18. They remain a large block of unsatisfied requirements this crate has carried since 2026-08-26, and they are counted here rather than described elsewhere so that the size of the gap is a number a reader can see.

Three things moved these numbers, and they are not the same thing.

Requirements gained tests. tests/invariants.rs closed A-06: 32 tests, five of them mutation-verified by disabling the check and watching the test fail.

Thirteen were reclassified type — enforced by the compiler, where a runtime test could not fail and writing one would be theatre (T13.2). Calling them type rather than • keeps the verified count meaning what it says.

Twenty-two requirements were added, and this is the part worth reading. The rendered openEHR pages omit every class-definition table — the sources include:: them from a UML export generated at build time — so anything implemented from the prose alone is a guess. All four Reference Model packages have now been read from the published PDFs, and all four times the primary source contradicted what had been implemented: three rules backwards, sixteen invariants missing, five reported under names openEHR does not use, and one place where openEHR contradicts itself (V8.7a). A rising total here is the specification catching up with the one it implements.

The three remaining ? are named individually below rather than lumped: a constant-time claim nobody has timed, an error path that cannot be provoked, and mutation verification being five checks rather than a policy.

§0 Conformance — C0#

Process requirements; they govern this specification rather than the code.

§1 Scope — S1#

§2 Identifiers — I2#

§3 Data types — D3#

§4 Data structures — R4#

§5 Common — M5#

§6 EHR — E6#

§7 Demographics — G7#

§8 Change control — V8#

§9 Serialization — J9#

§10 Validation — L10#

§11 Security — X11#

§12 Paths and query — Q12#

§13 Conformance testing — T13#

§15 Archetypes and templates — K15#

The section was added on 2026-08-26 when S1.4 was withdrawn. Fourteen rows are satisfied and eighteen are not: openehr::am is the AOM2 object model, openehr::am::validate (2026-08-30) checks a Reference Model instance against an Archetype already held in memory, and openehr::am::repository plus validate_with_repository (2026-08-30, same day) resolve a C_ARCHETYPE_ROOT filler through a caller-supplied repository — openehr performs no I/O itself (K15.25). No code in this crate parses ADL, flattens a specialised archetype, or expands a template — so what validate_with_repository checks is the definition each resolved archetype gives as its own, not as a flattened OPT2 would be, and that scope limit is stated in its own module documentation rather than left for the row below to imply more. A bare ARCHETYPE_SLOT stays unchecked even with a repository, because which archetype filled it lives on the instance's ARCHETYPED.archetype_id, an attribute crate::path::Node does not expose — a gap in crate::path, not in this section. A-40 tracks the rest.

This table exists so that the gap is counted rather than described. A row moves off spec when the code implements it and a named test exercises it (C0.7) — not when a parser lands, and not when a README says so (K15.30, K15.31).