The Atoms of the Score: Record-Level versus In-Engine Composite Evaluation of Clinical Quality Language Angelo Kastroulis Carrera Group [email protected] Draft v2 — July 2026
arXiv:2607.23619v1 [cs.DB] 26 Jul 2026
Abstract Clinical Quality Language (CQL) engines serve two axes of clinical computation: decision support — evaluate one patient, now — and quality measurement — score a population against a measure. Quality measurement is itself multidimensional: the composite score is rarely the end product, because the individual determinations that make it up are what allow a score to be inspected, attributed, and acted on. Two engine architectures follow from where that aggregation happens. One computes the composite inside the engine over the whole store — no data movement, maximal aggregate throughput. The other evaluates individual records and lets the composite be totaled externally, keeping every intermediate determination available. Mercury is a purpose-built CQL database engine of the second kind: it treats CQL evaluation as a database problem — FHIR resources stored in a compact binary encoding keyed patient-first, indexes derived from what CQL retrieves filter on, a planner selecting access paths, and CQL itself as the query language — rather than as in-memory interpretation over a generic FHIR store. We evaluate Mercury 2.0.1 against Blaze 1.10.1 — an engine of the first kind and among the fastest CQL evaluators available, which is precisely why it is the right benchmark — using Blaze’s own published suite on identical AWS hardware over a 100,000-patient Synthea corpus (112.3 M resources). The engines disagree by orders of magnitude in both directions: Mercury answers record-level queries 7.5–25.7× faster at the median (1.0–9.7 ms vs. 26.8–72.6 ms) and sustains 7.3–9.1× higher extraction throughput, while Blaze computes in-engine composites 13–1,082× faster. Correctness is held to a record-level standard, not merely count equality: a 10,000-pair per-patient agreement gate across engines reached 100.000 % after uncovering — and driving fixes for — two ingest bugs that composite-count comparison provably could not detect, because the aggregates were accidentally correct while individual answers were wrong. Ingest also favors the purpose-built path (74.7 min vs. 4 h 36 m to query-ready). We attribute both regimes to a single architectural choice, quantify a “store hygiene tax” in which a correctness fix sped up every lookup 1.2–2.8×, and argue that record-level agreement gates should be standard practice in engine benchmarking.
1
Introduction
CQL execution in production systems runs along two axes. The first is decision support: a CDS Hooks call, a point-of-care gap check, a patient-facing application — one subject, a millisecond budget, an answer that must arrive while someone is waiting. The second is quality measurement: scoring a population against a measure for reporting, improvement, or payment. The second axis 1
is more layered than it first appears. The composite score — a numerator over a denominator — is rarely what an organization actually needs; the atoms of the score, the per-patient determinations, are what make the score explainable and actionable. A rate without its members cannot tell you whom to call, what documentation is missing, or why the number moved. Where the aggregation happens therefore divides engine architecture. One family computes the composite in the engine, scanning the whole store: no data movement, one compiled plan, maximal aggregate throughput — and the intermediate determinations are a byproduct the caller may or may not be able to afford to extract. The other family evaluates individual records and leaves totaling to the caller: every atom is first-class and inspectable, decision support and measurement share one execution path, and the composite is a trivial external sum — at the cost of paying per-record evaluation overhead as many times as there are records. Neither choice is free. This paper measures both sides of that trade with one corpus on one machine class. This paper also takes a position: an atom-level methodology is more useful than an aggregate totaling machine. Three observations carry the argument. First, the atoms serve both axes — the same record-level evaluation that answers a decision-support call is the path to a quality measure totaled externally — while a composite-only result serves one. Second, the information flows one way: the composite is recoverable from the atoms by trivial summation, but the atoms are not recoverable from the composite. Third, and most consequentially for benchmarking, correctness is only checkable at the atom level: Section 6 presents two bugs that left aggregate counts exactly correct while individual answers were wrong — a failure mode no amount of composite validation can detect. The price of this position is measured rather than hidden: when the composite truly is all that is needed, the in-engine scan is dramatically faster (Section 5), and we report that with the same prominence as our wins. Why a purpose-built CQL database engine. The prevailing reference stacks do not translate CQL to SQL. They interpret it — compiled to ELM — in memory, typically on the JVM, against FHIR resources fetched from a generic FHIR server. What they do not do is treat evaluation the way a database would: store the data compactly in a form chosen to optimize retrieval, then build the machinery needed to locate and compute — indexes over the properties retrieves actually filter on, a planner selecting access paths, an execution layer that owns its storage. The engine is a calculator bolted to a store that knows nothing about it; every retrieve is a roundtrip into somebody else’s data layout, parsed from JSON on arrival. Building the engine as a database instead lets CQL evaluation inherit what decades of data-systems research made routine — compact binary encodings and compression, zero-copy reads, indexing, access-path selection, query planning — with the healthcare-specific nuances baked in: the FHIR resource as the native record, the patient partition as the unit of physical locality (matching CQL’s unit of evaluation, the subject context), and index keys derived from CQL retrieve shapes. Blaze took this database turn for the population axis — it owns its store and compiles queries against it, which is why it is fast. Mercury takes the same turn for the record axis, and is deliberately an engine of the recordlevel family. That makes Blaze the appropriate benchmark: if the record-level design cannot hold its own against the best database-shaped engine of the other family, the design is not interesting. This paper makes five contributions. (1) A two-regime benchmark design — interactive recordlevel latency, concurrent record-level extraction, and in-engine composite aggregation — layered on Blaze’s own published query suite and protocol: the defender’s home field. (2) Head-to-head results on identical hardware and corpus in which each engine wins its regime by one to three orders of magnitude; both results are true simultaneously and follow from one storage decision. (3) A record-level cross-engine agreement gate (10,000 paired booleans) as a correctness methodology, 2
with case studies in which it caught bugs invisible to aggregate-count equality — including one where the aggregate was accidentally correct. (4) A complete failure taxonomy: both engines fail the same terminology-dependent queries loudly; one disclosed DNF; zero silent wrongs after fixes. (5) Ingest-path attribution isolating allocator policy (∼8×), lock removal (∼4× parallel-phase, 1.3× end-to-end), and a merge-operator experiment (≈ nil).
2
Background
CQL and measure evaluation. A FHIR Library carries CQL source; a Measure references it; $evaluate-measure evaluates an initial-population expression per subject (reportType=subject) or over the store (reportType=population). The two report types are the API surface of the two axes above. The CQF operation surface is wider than $evaluate-measure. The CQF framework defines a family of record-level operations beyond measure evaluation: Library/$evaluate (evaluate any named expression for a subject), the system-level $cql operation (ad-hoc expressions), $data-requirements, and $package. These are where CQL is used as a language — the substrate of decision support and application logic — rather than as a measure-report generator, and a benchmark centered on CQL arguably ought to make them its focus: $evaluate-measure is one case, and for record-level workloads a marginal one. Blaze’s published suite, which we adopt verbatim as the defender’s home field, exercises $evaluate-measure only; a dedicated cross-engine benchmark of the full CQF record-level surface (CQF-Bench) is in development by the authors and is out of scope here. Blaze. A Clojure FHIR server that compiles CQL once per evaluation and iterates the patient axis in a tight scan; amortized per-patient cost on that axis is sub-microsecond. Blaze publishes its benchmark suite (queries, Synthea recipe, timing protocol, an eval-duration extension) in its repository; we adopt all of it. Mercury. A Rust engine over RocksDB, version 2.0.1 evaluated here. Every clinical row is keyed patient|type|id with index postings patient|property|value; the store is physically partitioned by subject. Evaluation binds one subject’s context and reads only that subject’s keys. Around that storage core Mercury carries the full database toolchain: a query planner with access-path selection (index routes vs. scans, chosen per retrieve), a compact FHIR-shaped binary record format with zero-copy reads, intelligent valueset-and-code matching (terminology resolved to direct code filters at compile time, unresolvable references failing loudly), and the CQF operation surface ($evaluate-measure, Library/$evaluate, $cql, $data-requirements, $package). The design intent is the record-level family: O(1) subject workflows, simple deletion and compaction, atoms as the primary product; in-engine composite scans were the known unoptimized path.
3
3
Method
3.1
Test setup: corpus, hardware, physical footprint, load time
Table 1: Test setup. One engine resident at a time on the same instance class; stores snapshotted to object storage for reproduction. Ingest paths differ by design and are declared: Blaze ingests FHIR transaction bundles over HTTP (blazectl, 16-way concurrent); Mercury ingests NDJSON through its bulk path — the same resources, reference-rewritten per the FHIR transaction rules. Corpus Raw corpus NDJSON (Mercury path) Hardware Blaze Mercury Store on disk Load time Protocol
Synthea (seed 3256262546): 100,000 patients, 112,322,471 resources 100,000 gzipped transaction bundles, 17.8 GB 20 gzipped shards, 10.4 GB AWS r6i.8xlarge: 32 vCPU, 256 GB RAM; gp3 1 TB, 16 K IOPS 1.10.1, documented benchmark config: 64 GB heap, 64 GB block cache 2.0.1, community engine: 32 GB block cache, 30 eval threads Blaze 127.3 GB; Mercury 185.0 GB (binary FHIR + patient-scoped postings) Blaze 4 h 36 m (≈6,800 res/s); Mercury 74.7 min (≈25,100 res/s) — 3.7× Blaze’s 9-run protocol, first two discarded; container restart between queries
Table 2: Resource-type profile (exact counts). Observation-dominated — Synthea’s longitudinalrecord shape — averaging ∼1,123 resources (∼640 observations) per patient. Consistency check: the Condition row count equals the stratifier-condition-code strata total both engines reported (Table 4). Resource type Observation DiagnosticReport Procedure Encounter Condition MedicationAdministration Medication Patient Total
Count
Share
63,950,790 17,237,029 15,615,811 9,551,864 5,658,095 104,441 104,441 100,000
56.9 % 15.3 % 13.9 % 8.5 % 5.0 % 0.1 % 0.1 % 0.1 %
112,322,471
100 %
Tables 1 and 2 summarize the setup and corpus. Declared deviations: Mercury lacks the FHIR transaction interaction for artifact creation (individual POSTs); Mercury received reportType=population explicitly; and unscoped composite evaluation — disabled and reported not supported in Mercury as shipped — was explicitly enabled for the Regime-B runs.
3.2
Before the test: the ingest observation
The timed protocol begins at a loaded store, so ingest is not part of the benchmark — but getting both engines to that starting line was itself instructive, and we report it as an observation. Blaze ingested the corpus the way its documentation prescribes: 16-way concurrent FHIR transaction 4
bundles over HTTP, sustaining ≈6,800 resources/s for 4 h 36 m end-to-end. Mercury ingested the same resources through its bulk path at ≈25,100 resources/s — 74.7 minutes to queryready, 3.7× sooner on wall clock, including the FHIR-transaction-rule reference rewriting. The paths differ by design and the comparison is observational, not protocolized; but the operational difference is real for anyone who must stand up, refresh, or replay a store. Mercury’s ingest surface also extends beyond what this exercise used: bulk FHIR $import, asynchronous ingest jobs with progress reporting, and direct NDJSON file reads that bypass HTTP entirely — the modalities a database offers because loading is part of its job, not an inconvenience in front of it. The trade is disclosed in the other direction too: Mercury pays more disk for what it builds (185.0 vs. 127.3 GB) — the patient-first key space plus per-property index postings are the physical price of the millisecond read path measured in Section 4.
3.3
The two regimes
Regime A (record-level). A seeded-random sample of 1,000 patients (seed 42; sample SHA256 published). A1 interactive: sequential per-subject $evaluate-measure, three passes, first discarded; wall p50/p95/p99/max and server-side evaluation time via the eval-duration extension (implemented in Mercury for parity). A2 extraction: the same subjects fanned out at concurrency 16 — the compute-the-atoms-and-total-externally path to a quality measure. Full fan-out: all 100,000 subjects at c=16 for one query; the externally-totaled composite this produces is cross-checked against both engines’ in-engine composites. Regime B (in-engine composite). Blaze’s own regime: unscoped evaluation over the store, 9-run protocol.
3.4
The agreement gate
Count equality is necessary but not sufficient — it validates the composite, not the atoms. For every Regime-A query we record each engine’s per-patient initial-population boolean and join across engines (10 queries × 1,000 patients). Cross-engine subject identity is itself non-trivial — Blaze assigns new server ids at transaction ingest — so the join key is the Synthea identifier (map published). Section 6 shows this gate catching two bug classes that composite comparison could not.
4
Results: Regime A (record-level)
Mercury is 7.5–25.7× faster at the median and 3.2–12.1× at p99 (Table 3); on eight of ten queries Mercury’s p99 (≈2.4–2.7 ms) sits an order of magnitude below Blaze’s median. The worst single Mercury call in ∼20,000 timed calls was 59 ms — roughly Blaze’s median for condition-all. Server-side, Mercury’s typical evaluation is ≈0.65 ms (the remaining ∼0.9 ms of wall time is HTTP/JSON envelope).
5
Table 3: Regime A on the 100 k store: 1,000-patient sample, three passes (first discarded), concurrency 16 for throughput. Agreement is per-patient boolean equality across engines. A1 p50 (ms) Query condition-450-rare condition-all condition-ten-frequent condition-ten-rare condition-two observation-17861-6 observation-44261-6 observation-72514-3 observation-788-0 observation-8310-5
A2 (patients/s)
Mercury
Blaze
Speedup
Mercury
Blaze
Speedup
9.72 6.26 1.57 1.23 1.07 1.04 1.08 1.57 1.06 1.17
72.63 52.45 27.91 27.82 27.13 26.86 26.75 26.81 26.81 26.80
7.5× 8.4× 17.8× 22.6× 25.3× 25.7× 24.9× 17.0× 25.3× 22.8×
986 1,618 2,397 2,442 2,506 2,523 2,528 2,306 2,531 2,463
132 178 305 306 314 326 318 315 312 321
7.5× 9.1× 7.9× 8.0× 8.0× 7.7× 8.0× 7.3× 8.1× 7.7×
Agreement gate: 10,000/10,000 = 100.000 % (every query 1,000/1,000). Full 100 k fan-out (o-17861, c=16): Mercury 41.0 s vs. Blaze 313.2 s (7.6×); both 2,515 true, 0 errors.
4.1
The structural finding: a latency floor vs. proportional cost
A1 median latency (ms, log)
Blaze’s median is ∼27 ms on eight of ten queries — within 1 ms of each other regardless of selectivity or result size: a fixed per-evaluation orchestration floor, rising only when the retrieve itself is heavy. Mercury has no comparable floor; its latency tracks data touched (1.04–9.72 ms). Figure 1 is that finding in one chart: a flat line crossing a proportional one. 102 Blaze 1.10.1 Mercury
101
100 re
45
ra 0-
c-
ll
q
fre ne -t
c-a
c
re
-ra en t c
wo c-t
61 78
1 o-
1
26 44 o
4
51 72 o
88
7 o-
10 83
o-
Figure 1: Median single-subject latency by query. Blaze pays a ∼27 ms per-evaluation floor — eight of ten medians land within 1 ms of each other regardless of selectivity — rising only when the retrieve itself is heavy. Mercury has no comparable floor; its cost is proportional to data touched. The same architecture inverts in the composite regime (Table 4). Figure 2 extends the finding to the tails: the two engines’ latency bands (p50–p99) do not overlap on any query.
6
Blaze p50 Mercury p50
Blaze p99 Mercury p99
latency (ms, log)
102
101
100 50
c4
ll
ca
0f
c1
0r c1
c2
61 78 1 o
61 42 4 o
14 25 7 o
88
o7
0 31 o8
query (ordered as Table 3) Figure 2: The tail ladder: p50 (solid) and p99 (dashed) per engine. The bands never overlap — on eight of ten queries Mercury’s p99 sits below Blaze’s p50 by roughly an order of magnitude. The one visible Mercury tail (o-72514, p99 9.1 ms) is a single 59 ms call among 2,000.
5
Results: Regime B (in-engine composite)
Blaze is 13–1,082× faster (Table 4) — this regime is what its architecture is for, and the numbers show it. Mercury matches its composite counts exactly on all seventeen countable queries, including the 5.66 M-strata stratifier. One asymmetry deserves emphasis: unscoped in-engine composite evaluation is not a supported mode of Mercury as shipped — the operation is disabled and reports not supported; we enabled it explicitly for this comparison so the regime could be measured rather than merely declared out of scope. We did not attempt to tune it (Section 9).
7
Table 4: Regime B: unscoped in-engine composite evaluation, Blaze’s 9-run protocol. Every countable query matches exactly. The three valueset (-vs) queries fail loudly on both engines (no terminology service in either documented configuration). One disclosed Mercury DNF: stratifier-observation-laboratory-code (41.65 M strata). Query condition-450-rare condition-all condition-ten-frequent condition-ten-rare condition-two observation-17861-6 observation-44261-6 observation-72514-3 observation-788-0 observation-8310-5 obs-body-weight-10 obs-body-weight-50 obs-body-weight-100 calcium-date-age hemoglobin-date-age inpatient-stress stratifier-condition-code
Blaze n
Mercury n
Blaze avg (s)
Mercury avg (s)
Slowdown
391 99,777 96,397 391 8,589 2,515 35,996 99,815 2,242 60,092 6,701 47,953 99,807 18,698 13,781 1,628 5,658,095
391 99,777 96,397 391 8,589 2,515 35,996 99,815 2,242 60,092 6,701 47,953 99,807 18,698 13,781 1,628 5,658,095
0.070 1.543 0.121 0.060 0.066 0.063 0.087 0.119 0.056 0.092 0.072 0.097 0.130 0.096 0.077 1.133 3.063
75.71 44.73 4.70 3.10 1.63 1.33 1.71 11.73 1.32 1.23 7.60 7.84 8.61 13.56 4.13 110.82 41.98
1,082× 29× 39× 52× 25× 21× 20× 99× 24× 13× 106× 81× 66× 141× 54× 98× 14×
Figure 3 superimposes both regimes on a single signed log-ratio axis: the mirror image is the finding.
8
Mercury wins → (log ratio)
10× 1× 0 10×
← Blaze wins
100× Regime A: record-level (Mercury/Blaze speedup) Regime B: composite (Blaze/Mercury speedup)
1000× 50
c4
ll
ca
0f
c1
0r c1
c2
61 78 o1
61
42 o4
14 25 o7
88
o7
0 31 o8
Figure 3: Two regimes, one architecture. For each query, Mercury’s record-level speedup is plotted upward and its composite slowdown downward (signed log10 ratio). The same storage decision produces both halves; no query escapes the mirror. The downward half measures a mode Mercury does not even ship enabled — unscoped composite evaluation is off by default and reports not supported; it was switched on for this test. The deepest bar (c450, 1,082×) is the 450-code retrieve — the shape Future Work item 4 targets from both directions at once.
6
The correctness journey
The first campaign scored 10/21 exact-count matches. Every failure traced to three root causes. (1) Dropped code filters: named code/concept definitions were never bound, and unresolvable valuesets fell through unfiltered, so retrieves matched everything; counts were wrong loudly and count comparison caught them. The fix also made unresolved terminology a hard evaluation error, matching Blaze’s honesty. (2) urn:uuid split-keying at ingest: Synthea transaction bundles reference subjects as urn:uuid:X; Mercury keyed clinical rows under the literal string and Patient rows under the bare id. Record-level evaluation under the bare id found no data — yet in-engine composites were accidentally correct because the registry enumerated both key forms. Composite comparison could never catch this; the agreement gate did (59.97 % agreement is an unmistakable alarm). (3) Un-rewritten intra-bundle references: FHIR transaction rules require urn:uuid references to be rewritten to Type/id; Mercury stored them literally, so reference-string joins (C.encounter.reference = ’Encounter/’ + E.id) matched nothing and inpatient-stress returned 0 against Blaze’s 1,628 — silently wrong, the worst class. A related evaluation gap (choice-type value[x] compared against a Quantity hard-erroring instead of yielding null per ELM cast semantics) was fixed with spec-compliant null-coercion while keeping genuinely ill-typed comparisons loud. After fixes and a full re-ingest: 17/17 exact composites and 100.000 % record-level agreement. The store-hygiene bonus: repairing the split-key layout made every per-patient lookup 1.2–2.8× faster (e.g. 2.82 ms → 1.04 ms p50) and the full fan-out 48 s → 41 s — the bug had been taxing every read with double-key resolution. 9
7
Attribution: why both regimes are true at once
sustained ingest (resources/s, log)
Measured on the live 112 M-resource store, Mercury’s single-subject evaluation costs p50 227 µs, of which storage reads are ≈1 % (patient-scoped point-gets, 2–5 µs); the remainder is per-subject environment, terminology binding, and AST interpretation — repeated once per subject. Blaze compiles once and pays ≈0.63 µs per patient amortized on the population axis, but ≈27 ms per call on the subject axis. One architectural choice, two mirror-image bills. Ingest attribution on the same corpus (Figure 4): glibc malloc arena policy (MALLOC_ARENA_MAX 2→64) ≈8×; global-lock removal ≈3.5–4× in the parallel phase but 1.3× end-to-end (a shared single-threaded tail — Amdahl’s law applied twice in one experiment); RocksDB merge-operator vs. read-modify-write ≈ nil. Final ingest: 112.3 M resources in 74.7 min including spec-required reference rewriting (Blaze: 4 h 36 m via transaction bundles — different paths, declared as such).
104
19,183/s
25,100/s
+lock removal
final engine
2,330/s
103 102 101
4.2/s
100 naive config
+allocator arenas
Figure 4: The ingest journey (log scale): a ∼6,000× path from the naive configuration to the final engine. The largest single factor was the memory allocator’s arena policy, not any database code. Blaze’s sustained transaction-bundle rate on the same corpus is ≈6,800 res/s (4 h 36 m end-to-end) — Mercury’s final NDJSON path lands 3.7× faster end-to-end. Figure 5 compresses every measured ratio into one view of the regime boundary.
10
o8310 M 10×
o788 o72514
1×
o44261 o17861
B 10×
c2 c10r c10f
B 100×
call c450
50 1p
A
A
99 1p
hru 2t
A
B ime
B 1000×
g
Re
Figure 5: Every measured ratio in one view (signed log10 ; blue = Mercury faster, gray = Blaze faster). The regime boundary is a vertical line: three record-level metrics are uniformly blue, the composite column uniformly gray. No query crosses it — the tradeoff is architectural, not query-specific.
8
Discussion
Regime-match, not engine-superiority. Decision support and atom-level measurement (millisecond budgets, inspectable individual determinations) fit record-level engines; whole-store composite reporting (minute budgets, no data movement) fits compiled scan engines. The procurement question is “which regime am I buying for?” — and, within quality measurement, “do I need the atoms or only the score?” Methodology. Run the defender’s own suite under the defender’s protocol; add record-level agreement gates (two of our three bug classes were invisible to composite comparison); publish the failure taxonomy with the same prominence as the speedups. Threats to validity. Single corpus generator (Synthea); cohort-scoring boolean measures only; Blaze measured once on its documented configuration without further tuning (its published numbers are consistent with ours); Blaze’s $cql endpoint (beta) was unavailable in this deployment, so the CDS-surface comparison rests on $evaluate-measure; engines measured serially on the same box class, not simultaneously; one Mercury latency-tail note (a single 59 ms call among 2,000 on observation-72514-3, p95 3.8 ms).
9
Future work
In-engine composite aggregation is not what Mercury is for — but we thought it would be fun to find out, and it shows: Blaze does an excellent job in that regime. The gap is closable without abandoning the patient-first layout, in escalating order of ambition: (1) hoist per-subject
11
setup (estimated 227 µs → 20–50 µs per subject); (2) composite-shape recognition in the planner, answering boolean code-exists forms from index postings (≈100 k point-gets ≈ 10–50 ms parallel — competitive with Blaze’s 63 ms on the 2.5 % query); (3) a value-first auxiliary index (type|property|value→patients) making population enumeration a single prefix scan, backfillable through the existing reconcile machinery; (4) multi-code retrieves via ordered prefix scan (removing the 450-point-get shape behind both the 1,082× composite outlier and the 9.7 ms Regime-A entry); (5) stratifier streaming (removing the disclosed DNF); (6) streamed result output: large evaluations currently pay full materialization and serialization of the report before the first byte returns — the cost behind both the subject-list report shape and the stratifier DNF. A streaming mode would return the aggregate immediately and then serialize matches and perstratum intermediates incrementally, so an analyst can obtain the answer and re-run the same query streaming out its intermediate matches for inspection — without the engine ever holding the full result set in memory. This composes with (5), and it is the natural API for an engine whose thesis is that the atoms matter: intermediate results become an analysis feature rather than a memory liability. Beyond the engine: CQF Ruler as a third subject, CV/ratio measures, non-Synthea corpora, and CQF-Bench — a cross-engine benchmark of the full CQF record-level operation surface (Section 2) that $evaluate-measure-centric suites, this one included, leave unmeasured.
10
Conclusion
Two engines, one corpus, one machine class, and the defender’s own benchmark suite — and each engine wins by one to three orders of magnitude in the regime it was built for, with record-level answers agreeing 10,000/10,000. The tradeoff is architectural, predictable, and measurable — provided benchmarks test both regimes and hold correctness to a record-level standard. Data availability. Engine and harness: carreraGroup/mercury (scripts/blaze-native-bench/). Query suite and protocol: samply/blaze docs/performance, used verbatim. Result artifacts (9run raw durations, per-patient booleans for both engines, identifier map, sample checksums, store snapshots, full pipeline logs) are archived in S3; release mode (public bucket vs. on-request) to be finalized with the preprint.
12