Conformance matrix

Non-normative. This records what is true today, per port, against the normative core. It is the document C0.9 requires a conformance claim to be justified against, and step 4 of §13's audit procedure.

Measured 2026-07-31 by reading each port's store crate surface, ddl.rs binding, test directory, and CI configuration; refreshed after the same day's audit-remediation pass, and again 2026-08-06 (F-74 — nine cells had gone stale against the code, most in the "the former scaffolds have no store" direction).

Test counts below name their unit explicitly: a bare number is the port's store crate unless it says whole-port. (An earlier revision mixed the two without saying so: mysql/mariadb "102" is whole-port — gen 13 + map 49 + store 40 — while mssql "33" and oracle "7" are store-crate counts.)

Where this file and a README disagreed, this file was right — that was audit.md F-01, now fixed, so the six READMEs should agree with this table. If one does not, the README is the defect.

Conformance level#

Per C0.8. The level is a claim about what has been verified for that port, not about what its code contains.

fhir-mssql moved from Scaffold to Store in the same pass that gave it a store at all: search/search_full/search_page were built and live-tested alongside the existing put/get/delete/history/vread/verify_audit/ purge/log_access, and five real defects surfaced by running that work live were fixed (F-65) — a cross-column collation conflict that broke every chained reference search, verify_audit never checking the keyed tag it wrote, connect returning Ok for an unreachable server, purge double-counting erased versions, and a torn read under concurrent writers (R4.5). The last of those needed two tries: READ_COMMITTED_SNAPSHOT alone was tried live first and did not stop the torn read, and SET TRANSACTION ISOLATION LEVEL SNAPSHOT (backed by a dedicated database, since master refuses the option) is what actually did. C0.9 requires the level be justified by tests that ran: all of the above did, and the live suite is green with nothing #[ignore]d.

fhir-oracle moved from Scaffold to Store the same way: F-66 had recorded a store that compiled but had never connected to a database, on the honest grounds that no Instant Client existed on this host. That blocker is gone — Oracle Instant Client for macOS arm64 downloads directly, no login required — and running the store live against gvenzl/oracle-free:23-slim-faststart found four real defects no amount of reading would have surfaced (F-68): Oracle folds an unquoted username to uppercase for session identity regardless of how CREATE USER quoted it, so a lowercase schema (M14.5's "three users" decision, as written) made every DDL statement ORA-01031 against a session that was really "R5" — fixed by creating users unquoted and setting the map's schema to match, uppercase; a speculative SET TRANSACTION READ ONLY for R4.5 (M14.19) turned out to fail with ORA-01466 on any session that had ever run DDL, reproduced with a minimal 3-statement probe, and was removed rather than shipped broken — R4.5 regresses from "believed addressable" to a confirmed, open gap; two insert_row call sites double-qualified the schema (ORA-00926, from passing an already-qualified table string alongside a separate schema argument); and timestamp/date columns bound as plain strings relied on Oracle's session NLS_TIMESTAMP_FORMAT rather than ISO 8601 (ORA-01843), fixed by binding real chrono types instead. A fifth defect — token search binding the string "true" against a NUMBER(1) boolean column (ORA-01722, Oracle does not coerce 'true'/'false' to a number the way SQL Server/MySQL do) — was found by the same live test suite and fixed by adding an i64 bind path (Bind::I64) used whenever the target column is ColTy::Bool.

Store operations#

• implemented · ~ implemented with a stated limitation · — absent

The remaining — in the init --upgrade/backfill_norm rows is fhir-oracle, which has a store (F-68) but no upgrade built on it yet.

put_audited and delete_audited have their own rows as of 2026-08-06: an earlier revision folded each into one cell with its plain sibling and showed the union as • for all six, while the _audited variants exist only in fhir-postgresql and fhir-sqlite — as this file's own port paragraphs already said (F-74). (search_page's pg cell was briefly challenged during the same audit on the theory that pg pages by offset only — checked against the code, search_page takes after_id: Option<&str>, a keyset cursor for the default id ordering, so • stands.)

fhir-mssql is • in both rows as of this revision, closing this port's share of F-15: MsSqlStore::upgrade/backfill_norm diff the installed map asset against the current one, apply the DDL, and backfill folded search columns, live-verified against azure-sql-edge by tests/upgrade.rs (9 tests). Until this revision every statement of the upgrade DDL itself was rejected by SQL Server — MySQL's ADD COLUMN spelling (F-25), and a NOT NULL column with no default added to tables that by definition have rows (F-26). Both were fixed and unit-tested at the map layer but had never been executed against a server; this revision is what finally executed them, live, for the first time. Two more defects surfaced doing it, neither anticipated by the DDL emitter's own unit tests: DROP TABLE on a table a live FOREIGN KEY still references fails with error 3726 regardless of destructive-table drop order (fixed by ordering children before their base table, M14.36), and this port's init previously stored only a bare checksum, not the map asset an upgrade needs to diff against — now fixed to store map_asset/fhir_version alongside it. Unlike fhir-mysql/fhir-mariadb, the DDL apply is one transaction: SQL Server's DDL is transactional, so a failed upgrade rolls back rather than half-applying (M14.35).

fhir-sqlite's transact_audited returns Unsupported rather than emulating atomicity by compensation, which is the right answer: a FHIR transaction Bundle is atomic by definition, and a compensating unwind is not — readers between ops observe a half-applied bundle, and a process dying mid-unwind leaves partial state permanently.

fhir-mssql's get is •: R4.5 was confirmed violated under concurrent writers by a live torn read, then fixed in a same-day follow-up pass — see M14.25 and F-65. put/delete were always •: the requirement they carry, H5.4 write serialization, was live-verified from the start (8 of 8 racing writers got distinct consecutive versions and a chain that still verifies); it was specifically the multi-statement read that tore.

fhir-oracle's get is • despite R4.5 being an open gap there (see Core requirements below): the operation itself works and is exercised live by every test in the suite, it simply carries no snapshot-isolation protection under concurrent writers — the same distinction the table draws for P6.4a, a •/~ operation cell is not a claim about every requirement that touches it. search_page is ~: the function exists and is exercised transitively (search calls into the same query builder), but no test calls it directly with a cursor, so its paging-specific behaviour is unverified. put/delete use SELECT … FOR UPDATE for H5.4 (M14.20 discharged in code), but — unlike mssql — no concurrent-writer test exists for this port, so the mechanism is present and unverified under contention rather than live-confirmed.

Core requirements#

• satisfied · ~ partially · ! violated · ? unverified · — not applicable

A correction#

An earlier revision of this table marked T11.8 as ? for sqlite, mysql, and mariadb on the reasoning "audit.rs on pg only". That was wrong: all three assert chain verification, disclosure logging, append-only enforcement, and erasure — inside their *_store.rs files rather than in a file named audit.rs. Judging coverage by filename over-reported the gap.

The row now reads ~ with the specific remaining gaps named. Over-reporting a gap is a smaller error than under-reporting one, but it is the same kind of error, and this table is the document that is supposed to be checkable.

How to read the ? column#

? is not a soft •. It means the requirement is plausibly satisfied by shared code and nothing in that port's test suite demonstrates it. R4.5, H5.4, T11.6, T11.7, and T11.8 are the ones that matter most: they are the concurrency and audit guarantees, they are the requirements §13 maps to HIPAA §164.312(b) and (c), and outside fhir-postgresql there is no test file that exercises any of them.

A port at Store level with ? in those rows can hold data. Whether it can hold patient data is the question those tests exist to answer, and for four of the six ports it is currently unanswered rather than answered yes.

The documentation pass did not change a single ? in those rows — it fixed documentation, metadata, annexes, and pipelines, none of which is evidence about concurrency or audit behaviour. Writing the tests did. Porting roundtrip_types.rs, concurrency.rs, and redaction.rs to sqlite, mysql, and mariadb turned eleven ? cells into • and found five defects doing it (F-20 to F-24), four of them High.

The ? cells that remain outside fhir-postgresql are now concentrated in T11.8 and T11.9, and in fhir-oracle's concurrency rows (H5.4, T11.6) — no port remains at Scaffold; fhir-oracle reached Store the same way mssql did, by connecting a store and running it (F-68).

What would move each port up a level#

• fhir-sqlite → Reference. concurrency.rs and redaction.rs are done (and found four defects doing it), and upgrade + backfill_norm now close this port's quarter of F-15. Remaining: the two T11.8 gaps above, chain_witness, and resolving transact_audited by splitting put/delete so their bodies run inside a caller-supplied BEGIN IMMEDIATE.
• fhir-mysql, fhir-mariadb → Reference. All four suites are ported and green; doing so found F-20, F-21, F-23, F-24, and — writing the upgrade path — F-28. upgrade and backfill_norm now exist and are verified live, closing F-15 here. What remains is missing features rather than unverified ones: no put_audited and no expected_version anywhere in either crate, so there is no optimistic concurrency to test; likewise no transact_audited, no conditional create/delete, no emit_checkpoint. Also the T11.8 gaps shared with sqlite.
• fhir-mssql → Reference. Reached Store this pass (F-65): a real tiberius store with search, live-tested, including R4.5 — fixed in a same-day follow-up once the first attempt (READ_COMMITTED_SNAPSHOT alone) was tried live and found insufficient; SET TRANSACTION ISOLATION LEVEL SNAPSHOT backed by a dedicated database is what actually works. O10.7's verification mechanism is now confirmed live (F-67), but the same pass found the four TLS advisories deny.toml had been ignoring now reach the shipping store crate, not just a dev-dependency as previously believed — native-tls was tried as a fix and fails the handshake on this host, so this is a standing risk needing an owner decision, not the last item on a checklist. upgrade/backfill_norm are also now done, closing this port's share of F-15 — live-verified by tests/upgrade.rs (9 tests), and genuinely atomic (M14.35) unlike fhir-mysql/fhir-mariadb's equivalent, since T-SQL DDL is transactional. What remains, in rough order: the M14.34 decision above; verification against full SQL Server rather than azure-sql-edge (M14.31); and the unindexable-column decision (M14.16).
• fhir-oracle → Reference. Reached Store this pass (F-68): Oracle Instant Client installed on the host, a real scripts/db.sh and tests/oracle_store.rs built, and four real defects found and fixed by running the store live for the first time (uppercase-schema case-folding, R4.5's SET TRANSACTION READ ONLY failing with ORA-01466, a double-schema-qualification bug, and a timestamp-binding bug). What remains, in rough order: an actual R4.5 fix (the annex now needs a new answer, not just a name — M14.19); a concurrency.rs to verify H5.4 under contention, which the code already attempts via FOR UPDATE; a redaction.rs; upgrade/backfill_norm; and O10.7 transport security, currently undecided (M14.22).
• fhir-postgresql → clean Reference. The chain pre-image now comes from canon.rs (F-07 fixed, M14.12), the dead _norm SQL function is gone (F-18 fixed), and the TLS default verifies (F-17 fixed 2026-08-03, tests/ssl_default.rs — an earlier revision of this bullet still called it an open owner decision while the O10.7 row above said it was fixed, F-74). What is left: the shared T11.8 gaps (truncated-chain-vs- checkpoint is the one pg itself lacks a direct test for) and deeper chained reference search.

Part of the fhir-databases specification.