Seventeen foundational assumptions. Each one has a refutation criterion.

Per the fair-broker positioning, I keep the criterion in the framework at score null rather than removing it. The reasoning: a customer's actual engineering skill mix is unknowable from outside the engagement, but dropping the criterion entirely would create a silent gap during engagement scoping. The rule is "held null but visible" so engagement teams cannot forget to ask. The central claim is that this is structurally unscorable rather than scorable from public signals.

Refutation. A structural pattern emerges where in-house skill base can be inferred from non-engagement signals at standing-matrix level. For example, vendor official-skills certifications mapped to a known practitioner population, or a third-party labor-market dataset with sufficient granularity.

Dependent MDRs: MDR-0002 (scoring scale), MDR-0006 (engines taxonomy), MDR-0010 (pipelines taxonomy).

This is the most consequential single assumption in the Engines matrix. The H3-PERFORMANCE-01 measurement (ClickHouse 46.8× faster than a schema-on-read SIEM on the five-query average over a 10M-event Zeek corpus, the native arm-pairing of the triple-draw band with the Iceberg arm at 10.1×; 5–62× on the hunting-shaped queries across the native and Iceberg realizations with the index winning the simple lookups; answer-equality verified, single-node Tier B) is the strongest anchor I have on the engine-performance side. The measurement shape is single-node sequential. The inference (that ClickHouse's sharding-plus-replication architecture preserves the per-shard query characteristics under cluster and concurrency) is reasonable but unmeasured. Cluster overhead from network shuffles on cross-shard joins could compress the ratio.

Refutation. The cluster + concurrent-query regime (multi-node, ~30 concurrent queries) is where the two-regime advantage could compress: it might pull the hunting-aggregation multiple over the schema-on-read SIEM baseline (OpenSearch 2.18.0, the canonical foil; the 3.7.0 currency check was performance-neutral) below ~5×, or surface a regime where ClickHouse loses to Trino on the recurring-query envelope of Archetype A. The single-host engine-join bake-off has already run (2026-06-10, Tier B — the open engines answered the SOC suite under 1.5 s); the cluster regime remains the gating event, unmeasured.

Dependent MDRs: MDR-0007 (engines Archetype A weights).

Polaris entered the Apache Incubator in August 2024 and graduated to an Apache top-level project on 2026-02-18; Pinterest's production deployment (presented at Iceberg Summit 2026) remains the first named Tier-A reference. The momentum signals are real. Apache published the first official Helm chart apache-polaris-1.5.0 on 2026-05-18, eight days before this review.

First-party friction characterization (2026-05-25, v1.3 cut). The chart ships, but it requires k8s 1.33+ (bleeding-edge), is not yet on any Helm registry (install from cloned source), defaults to in-memory persistence (no documented production Postgres-backed path in 1.5.0), and the docker POLARIS_BOOTSTRAP_CREDENTIALS env-var pattern silently regenerates root credentials when the realm name is wrong. OAuth client-credentials flow requires bootstrapping a service principal via the management API rather than via env. STS-less S3 backends need X-Iceberg-Access-Delegation: "" as a header override. I read these as friction signals along the maturity trajectory, not refutations. They refine the per-engagement diligence list without contradicting "Polaris is maturing."

Refutation. A 12-month-flat named-production-reference count for Polaris (no new Tier-A references between 2026-06 and 2027-06), or Snowflake reorients the Polaris roadmap toward Snowflake-only integration (i.e., governance capture).

Dependent MDRs: MDR-0008 (formats + catalogs taxonomy), MDR-0009 (Archetype A weights).

The measurement is from my own ENGINE-06-trino-federation post on Zeek conn.log. It is consistent with Trino's coordinator-plus-worker architecture imposing a planning floor regardless of source count. The honest caveat: the measurement may be conflating federation overhead with engine overhead. A single-source isolation test against an Iceberg-only Trino deployment would disambiguate. I haven't run it yet.

Refutation. An independent measurement on a single-source Iceberg-only Trino deployment with no federation shows p50 below 1s on an equivalent Zeek conn.log workload. If this refutes, Trino's lower-bound weighted-total moves from 3.23-3.48 toward 3.50, which cements Trino's #2 slot in the Engines matrix.

Dependent MDRs: MDR-0007 (engines Archetype A weights), MDR-0017 (engines Archetype B weights).

Tenzir's documentation describes OCSF-native normalization without separate packs, and the architecture inspection (Rust, Arrow-first, schema-aware operators) supports the claim. But the public customer count is under 100, and no named Fortune-500 reference at 5+ TB/day has published a fidelity audit. Architectural soundness is high-confidence; production-scale validation is low-confidence. The gap between those two is the central concern.

Refutation. A named Fortune-500 production reference at 5+ TB/day publishes Tenzir OCSF lossiness measurement, or an independent practitioner audit on at least three source classes (Zeek + CloudTrail + EDR) shows lossiness greater than 5%. The Asmin Aktaş WiCyS 2026 talk on resilient log-ingestion is a track-post-conference data point.

Dependent MDRs: MDR-0010 (pipelines taxonomy), MDR-0019 (pipelines Archetype B weights), MDR-0022 (pipelines Archetype C weights).

This window was written for MDR-0014's original three-tier line, under which the scored ordering was to reach the public surface only after a delayed summary. The 2026-07-11 publication ruling dissolved that line: the full scored matrix (methodology, candidate catalog, weighted scores, reasoning, claim-vs-shipped deltas) is public, with only DeWitt/EULA-bound benchmark figures withheld, and the illustrative scored surfaces governed by MDR-0031's five conditions. What survives of MDR-0014, and what this assumption now underwrites, is the disclosure-correctness scrub and the public-correction discipline: every scoring cut still gets its scrub window between the internal cut and the public refresh that carries it.

The convention is no longer fully untested, because the 2026-07-11 publication put real scored material on the public surface and started the refutation clock below against it. If the window proves insufficient, I'll revise upward to 8-10 weeks or add a structured pre-release review step.

Refutation. A disclosure-related correction is required within 60 days of the 2026-07-11 publication, or of any subsequent public scoring refresh.

Dependent MDRs: MDR-0014 (public vs. paid line — superseded 2026-07-11; its disclosure-scrub and correction-discipline clauses survive), MDR-0031 (illustrative worked-example exception).

This is a classic shipped-vs-claim delta. Vendor marketing says one thing; practitioner reports from Huntress engineering and my own engagement experience say another. The ClickHouse operational_complexity score of 3 captures the honest middle: it would be 4-5 on pure ClickHouse Cloud at small scale, and 2 on self-hosted at petabyte scale. Mid-market deployments at petabyte scale still want a dedicated platform engineer.

Refutation. An independent measurement at 10+ TB/day shows ClickHouse Cloud is operable by a one-engineer team without significant on-call burden, or ClickHouse Cloud ships product changes that materially reduce SRE involvement across all deployment shapes (autoscaling and auto-tuning).

Dependent MDRs: MDR-0007 (engines Archetype A weights), MDR-0021 (engines Archetype C weights).

This is a methodology meta-assumption embedded in the evidence-tier system itself, not a state-of-the-world claim. StarRocks's 5-30s multi-table benchmark and Cribl's 70-90% reduction are examples; both stay Tier C until I see practitioner corroboration or a named production reference. The long 24-month review cadence reflects that reviewing more often would just be re-affirming the convention. The convention is what underwrites the credibility of the tier system as a whole.

Refutation. Not applicable in the usual sense. Refuting this would require redesigning the evidence-tier system itself per MDR-0003.

Dependent MDRs: MDR-0003 (evidence tiers A-D).

The gate-capability in MDR-0030 rests on two linked premises. First, that under a named regime (a 17a-4(f) WORM mandate, a residency mandate) a candidate either satisfies the mandated control or it does not, with no partial-credit middle a strong cost score could trade against, which is why the right behavior is disqualification before weighted totals rather than a low score inside them. Second, that the client's applicable regime is knowable at engagement scoping, so the gate can actually be set. The named regimes (SEC 17a-4(f), Reg SCI, DORA) are Tier-A public obligations, but whether a specific requirement binds a specific client as a hard gate, versus being satisfiable by a compensating control or a scoped exception, is a legal judgment made per client, not a property the matrix measures. WORM under 17a-4(f) is close to genuinely binary for a broker-dealer, which is the canonical case the gate is built around; residency and retrieval-SLA are softer, often satisfiable by more than one control, so treating them as hard gates can over-disqualify.

Refutation. A real engagement where a candidate that fails a sub-criterion is nonetheless acceptable to the client's auditor via a compensating control (a non-WORM store fronted by an external immutability ledger, say), which would make that sub-criterion a high-weighted score rather than a hard gate; or a client whose applicable regime cannot be pinned at scoping (multi-jurisdiction, unsettled exposure), which would mean the gate cannot be set until compliance counsel rules.

Dependent MDRs: MDR-0030 (compliance/WORM gate axis).