Thirty-seven scoring decisions. On the record.

Decision. Every criterion is scored 1 (architectural mismatch) through 5 (best available for this criterion in this archetype). Null is a legitimate state when evidence does not support a defensible score. A validation rule requires at least one citation on every non-null score.

Why this won. A 0–100 NPS-style scale offers false precision. Practitioners anchor on round numbers, and defending a 73 versus a 76 is harder than defending a 4 versus a 4. Likert scales fit opinion surveys, not capability assessments. Pass / Conditional / Fail collapses "good but not best" and "the best" into one bucket, losing the differentiating information the matrix exists to expose. The 1–5 scale matches the granularity I can actually defend in writing, and null is honest about evidence absence rather than fabricating a 3.

Decision. Every component is scored separately for each archetype. Criterion definitions stay constant; weights vary by archetype. A candidate's score on a given criterion may also shift across archetypes when the archetype reframes the criterion's relevance (concurrency under federated workload differs from concurrency under single-source). Archetypes are pre-set per component, not negotiated per engagement; engagements are assigned to their closest archetype.

Why this won. This is the single most important methodology choice in the matrix. Without it, the matrix collapses to a global ordering with no defensibility ("ClickHouse wins all workloads" or "Trino wins all workloads", both demonstrably wrong). The same criterion (raw_analytical_query_performance) is the dominant value driver for one workload and an afterthought for another. An engagement that does not fit any published archetype is itself a finding: either I add a new archetype or score the engagement with custom weights and an explicit "deviation from standard archetype" note.

Decision. If any criterion has a null score, the weighted total is null. Instead of a point estimate, two bounds are computed: a lower bound (treats every null as 1, the scale floor) and an upper bound (treats every null as 5, full credit). Customers see "ClickHouse 3.65 – 3.85," not "3.72 ± something I am not telling you."

Why this won. Skipping null criteria silently re-normalizes weights and breaks comparability across candidates with different null patterns. Collapsing null to a single point estimate distorts either way — 0 over-penalizes, "average" (3) is false precision — since the entire reason for null is that I cannot honestly score. Bounds preserve the unknown explicitly by spanning the full 1-to-5 score range. Sensitivity analysis becomes straightforward: if the ranking changes when nulls fill at the low versus high end, the ranking is not v1-publication-ready.

Superseded 2026-07-11. The publication ruling makes the full per-criterion scores, citation tiers, weighted totals, and shipped-vs-claim deltas public; they are the flagship evidence asset, not a withheld work product, and what clients pay for is the services engagement that applies the matrix to their environment. The disclosure-scrub delay and the public-correction discipline below survive; the three-tier withholding of scores does not. The original decision is kept here as the record.

Decision. Three-tier split. Methodology is fully public: criterion set, weight tables per archetype, evidence tiers, validation rules, archetype definitions. Ordering is public with a 4–6 week delay after the engagement-internal v1 completes (the delay exists for disclosure-correctness scrub). Per-criterion 1–5 scores, citation tiers, weighted totals, shipped-vs-claim deltas, and cross-component bundles are the engagement work product. They are not published.

Why this won. Publishing full scores destroys engagement economics; there is nothing left to engage for. Publishing nothing destroys the brand surface; the matrix has nothing to demonstrate. Publishing scores at coarse granularity (Pass / Conditional / Fail) collapses the differentiation the matrix exists to provide. The three-tier split makes the public surface "enough to evaluate the method" without becoming "enough to substitute for the engagement." If disclosure flags an issue post-public-release, the response is a public correction, not a silent edit.

Decision. The structure is mandatory; the content is null when nothing exists to disclose. When a relationship exists, the block names the nature (explore / active partnership / former employer), the scope in plain language, and the impact_on_score. One disclosure is currently on file: the Delta+Unity candidate carries nature: explore in all three F+C scoring files for an in-progress conversation with Databricks about Lakewatch go-to-market, recorded with no score-altering effect. No commercial partnership exists with any scored candidate, and no other candidate carries a filled block.

Why this won. Fair-broker positioning is the practice's central differentiator. A customer auditing the matrix has no way to detect partnership bias without explicit disclosure. Hiding partnerships would be the most damaging credibility hit available. Disclosing only when commercial would under-disclose; in-progress conversations are also signal. Optional disclosure invites inconsistency. Mandatory structure with conditional content is the rule that lets a reader trust the score even where partnerships exist.

Decision. Score query engines on: raw analytical query performance, Iceberg native versus connector, semantic layer / materialized views support, federation breadth, operational complexity, SPL dialect distance, concurrency and multi-tenant behavior, and existing in-house skill base (plus, since the v1.3 MDR-0023 addition, native IP type support — nine criteria current). The skill-base criterion is held null at standing-matrix level (filled at engagement scoping), and that pattern caps standing evidence completeness at 0.889.

Why this won. Cost-per-query as a separate criterion is entangled with operational complexity (managed vs self-hosted) and the downstream storage tier; folded into qualitative notes instead. Latency versus throughput as separate criteria is a premature split; most workloads do not care about the distinction until they care a lot. Iceberg V3 / V4 currency as a separate criterion would be a stand-in for "which engine ships new versions fastest"; captured inside the iceberg_native_vs_connector caveats per candidate; revisit at v2 if V4 ships and engines diverge sharply.

Decision. For the second engagement shape (multi-source federated lakehouse at 10–100 TB/day with federated joins across CMDB, EDR, identity, and Zeek), the weight distribution shifts substantially. Iceberg-native lifts to 25 (from A's 15); raw performance drops to 20 (from 30), re-split at v1.3 into 15 + 5 native-IP per MDR-0023; federation_breadth lifts to 20 (from 5), the largest single weight shift in the matrix. Semantic layer lifts to 15; operational complexity drops to 10; SPL distance drops to 5; concurrency drops to 5. The in-house skill base weight drops to 0; the criterion stays in the set but does not affect scoring under B (the matrix presumes greenfield-class hiring at this engagement scale).

Why this won. The Archetype A weighting produces nonsense rankings under federated workloads. Trino's federation strength scored a 5 at A but only contributed weight 5 to the total. At B, federation IS the archetype's name; Pinterest's Trino + Gravitino + Iceberg at 17k+ nodes anchors at Tier A. The weight-0 convention is itself a decision: criteria can be retained in the set but score-neutral in archetypes where they do not apply. The convention propagates to MDR-0022 (Pipelines Archetype C).

Decision. Add native_ip_type_support as a 9th criterion to the Engines taxonomy. Scoring 5 means both IPv4 and IPv6 are first-class types with type-aware functions likeisInSubnet and cidr_match; 4 means native types with limited functions or IPv4-only; 3 means extension-available; 2 means string-only with auxiliary functions; 1 means string-only with no IP-aware functions. ClickHouse and Trino score 5; Athena scores 4 (Presto/Trino IPADDRESS lineage); DuckDB scores 3 (inet extension loadable, not default); StarRocks scores 2 (string-only). The criterion is funded from the raw-performance budget (A 30→22+8, B 20→15+5, C 15→11+4) and re-ranks the field: the native IP type criterion lifted Trino to #2 at Archetype A in the v1.3 cut, which the v1.4 concurrency re-score narrowed but did not overturn on the published table, and confirms Athena at #1 at C.

Why this is now Accepted (v1.3, OG-4). Vern Paxson cited Zeek's choice to treat IP addresses as first-class types (not abstracted to integers) as one of the most important performance optimizations in Zeek's design. A 2026-05-25 technical conversation exposed the gap. The criterion is architectural and binary — an engine either ships native IP types or it does not — so it is scoreable from documentation at Tier B today, which is what the v1.3 cut accepts. The Tier-A storage-size and predicate-latency measurement (the Q3 / cluster benchmark generators currently emit src_ip as a string and need to emit native types) is still owed, and it will revalidate the weight rather than the yes/no score. Folding the dimension into raw query performance would conflate an architectural choice (binary) with a continuous performance measurement (different dimension), which is why it is its own criterion.

Decision. Components 1 (table format) and 2 (catalog) are scored as paired choices (Iceberg+Polaris, Iceberg+Nessie, Iceberg+Glue, Delta+Unity), not independently. Ten criteria: multi-engine query support, multi-engine federation, open governance, catalog ecosystem maturity, RBAC and column-level security, schema evolution and time travel (format), time travel and branching (catalog), cloud-native versus self-hosted, cost model (OSS versus licensed), and cloud / on-prem flexibility. No in-house-skill-base criterion; catalog choice is a platform decision, not a per-analyst skill match.

Why this won. Scoring formats and catalogs independently produces operationally undeployable pairs ("Unity 5/5 + Hudi 4/5"). The choice is structurally coupled: Unity ties to Delta, Polaris is Iceberg-first, Glue is AWS-bound, Nessie is Iceberg-native. The bundled framing is what engagements actually need. Scoring only catalogs with formats as an attribute would collapse Iceberg versus Delta, an essential dimension. Bundling further into Component 3 (engines) would create too many simultaneous decisions and lose the locality that makes scoring defensible.

Decision. For "already on Databricks or similar; optimize for operational simplicity within the vendor ecosystem; accept some portability tradeoff," RBAC lifts to weight 25 (from A's 15), because the production access-control gate is the design center under a managed single-vendor lakehouse. Cloud-native versus self-hosted lifts to 15 (from 5); multi-engine query support drops to 10 (from 20); cost model lifts to 10 (from 5); federation drops to 5 (from 15); open governance drops to 5 (from 10). The honest finding: Polaris narrowly leads Delta+Unity, 4.10 to 3.95, under B. Iceberg+Glue lifts from 2.70 to 3.45, above Nessie's 3.25 and closer to its AWS-native home but not there yet.

Why this won. Pushing RBAC to 30 would tilt decisively to Delta+Unity and predetermine the winner; 25 is already at the high end of the anchoring rule. Polaris narrowly leading Delta+Unity at B, 4.10 to 3.95, is a finding worth flagging: Delta+Unity's expected dominance at its home archetype is partially offset by Polaris's broad strengths (multi-engine 5, OSS cost 5, on-prem flexibility 5) that hold up even when downweighted, so the gap closes to a 0.15 near-call rather than the wide Delta+Unity win the home archetype predicts. Without per-archetype scoring this nuance would be invisible.

Decision. A storage_layer_maintenance_status metadata flag (not a scored criterion, a per-candidate annotation) attaches to F+C scoring entries where the candidate's default or commonly-paired deployment includes a specific named storage layer. Values: ACTIVE, MAINTENANCE, or ARCHIVED, shown as a Go/No-Go gate ahead of the weighted score rather than buried in qualitative notes. The owner ratified the flag design and its backfill table on 2026-06-23 on Tier-A GitHub-API verification (MinIO ARCHIVED, the repo archived with last push 2026-04-24; SeaweedFS, Ceph, Rook, and Garage ACTIVE). The flag is not yet written into the scored YAMLs: application is deferred to the next refresh trigger per MDR-0015, so the scored matrix is not amended mid-version, and each backend's status gets re-verified at application time.

Why this won. The MinIO archive event made the need concrete: UI removed from OSS (2025-05-25), Docker images stopped (2025-10-23), README to maintenance mode (2025-12-03), repo archived 2026-02-13. A customer reading a v1.2 F+C score for a MinIO-paired deployment in May 2026 would not see the maintenance risk without this flag. Ratifying now while deferring application splits the decision from the amendment deliberately, because the external evidence is Tier-A complete and benchmark-independent (MinIO is archived and that will not reverse, so waiting teaches nothing), while writing the field into scored files mid-version would break the revalidation cadence the matrix committed to. Adding it as a scored criterion would spend a dimensionality slot on a binary state better shown as a Go/No-Go footnote.

Decision. Score pipeline platforms on: default reduction ratio, aggressive reduction ratio (the ceiling), OCSF normalization fidelity, cross-source schema correlation, lines of config to express a SOC ruleset, resource consumption (CPU and memory), pricing model, vendor lock-in / portability, and in-house skill base (held null at standing-matrix level). Default reduction and aggressive reduction are split deliberately. Vendor marketing collapses them; the matrix should not.

Why this won. A single reduction-ratio criterion would let vendor marketing inflate scores; Cribl markets 70–90% but A-02 (Cribl 70-90 is tuned, not default) anchors that the marketed ceiling requires ongoing tuning. Latency-to-detection as a separate criterion is Tenzir-favoring (pipeline-based detection at 15–50 ms versus query-based 5–30 s) but generalizes weakly across the four candidates; captured in qualitative notes instead of a weighted criterion. Cross-source schema correlation is a Tenzir differentiator that would be lost if dropped; kept at 5.

Decision. For 200 GB/day from 10+ sources writing OCSF-conformant events to Iceberg with 2–3 engineers: OCSF normalization fidelity carries weight 30, the largest single weight in any archetype in the matrix. Config LOC and cross-source schema correlation each weight 15. Resource consumption and default reduction each weight 10. Aggressive reduction, pricing model, vendor lock-in, and in-house skill each weight 5. Tenzir's OCSF-native architecture wins decisively at B; Cribl holds middle ground via Packs; Vector and Kafka Connect drop further.

Why this won. Under Archetype B, schema normalization is the workload itself. OCSF at 25 instead of 30 would understate the shift; the archetype's name carries authority. Combining OCSF normalization with cross-source correlation would collapse two distinct dimensions (per-source normalization quality versus join enrichment); kept separate. Dropping default reduction to 0 would predetermine that reduction does not matter at B, but Archetype B still ingests 200 GB/day and the downstream SIEM may still benefit; kept at 10.

Decision. Four standing paths compete on one surface: P0 Stay (the status-quo SIEM, the do-nothing baseline every other path is scored against), P1 Augment (keep the SIEM for hot and detection, offload cold and retention to the lakehouse), P2 Hybrid-tiered (ClickHouse hot plus Iceberg long), and P3 Full-replace. The breakeven is computed, never asserted:crossover_months = migration_cost ÷ (monthly_cost(stay) − monthly_cost(path)), where monthly cost reconstructs from the cost-to-serve-at-retention cells that already exist and migration cost is the one new input, labeled the softest term (Tier C/D judgment until a client's source inventory is scoped). The output is a breakeven curve over the buyer's horizon, not a bare point estimate.

Why this won. The 2026-06-17 maturity assessment found, across all four expert lenses, that the Matrix answered "which open stack if I move" and underserved "should I move at all," so a CISO could not take it to a board for a go/no-go. Hand-asserting a breakeven would have been faster, but a technically-literate client recomputing from the published cost-to-serve cells would find a number that does not reconstruct, which is the exact integrity failure the audit-not-opinion rule exists to prevent. The risk gate rides on Move #3: a path that fails a detection-survivability or compliance gate is not eligible to win the crossover on cost alone, because a full-replace that drops 30% of detections is not cheaper, it is broken.

Decision. Component 5 becomes a scored component, and detection-survivability enters as its sixth criterion (from five, inside the 3–14 bound): what fraction of the client's existing detection corpus survives the move, under a three-band model. Survives means the target executes the rule with correct semantics. Silently degrades means the rule compiles and ports but loses a primitive, so it runs while no longer enforcing its own logic, and that band is scored worse than a clean cannot-port failure because nothing downstream announces the loss and the dashboard stays green. The engagement-internal score runs against the client's actual corpus, so client numbers stay with the client; the public surface carries the method, the three bands, and the silent-degradation evidence.

Why this won. "Ports cleanly" is easy to fake, because a rule that compiles on the target looks ported, and the first-party SIGMA-EXEC evidence (Tier B, single host) shows compiling is not executing: pySigma compiles a correlation rule's count logic to a windowless query that over-fires while the dashboard looks healthy. Scoring silent degradation equal to a loud failure would actively mislead, since a loud refusal gets seen and redesigned while the invisible loss just runs wrong. Losing detection coverage mid-migration is the catastrophic risk for a SOC, the one no cost advantage offsets, so the Matrix has to score it to be a security-data-architecture instrument rather than a lakehouse comparison.

Decision. A scored illustration could appear on the public surface only when five conditions held together: illustrative archetype inputs, never a client's; the vendor-claim-versus-shipped delta redacted; no real-client scored ranking; labeled illustrative at the point of use with evidence tiers carried; and method shown, not verdict substituted. It wrote the boundary the worked scorecard and the Move-2/3 demonstration pages already relied on into the rule, so each new illustration stopped being a fresh judgment call.

Why the record stands. The 2026-07-11 publication ruling then made the full matrix public (scores, reasoning, and deltas), so the public/paid line this exception refined no longer exists and the record stands as history rather than an active rule. What survives it is the discipline it encoded: illustrative inputs are still labeled illustrative, evidence tiers still travel with every grounded cell, and the only figures withheld now are the DeWitt / EULA-bound benchmark measurements, which is a legal constraint on naming vendors in published measurements, not a paid gate.

Decision. The owner ratified Matrix Move #3: detection-survivability (MDR-0029) and the compliance/WORM axis (MDR-0030) fold into the scored Matrix as first-class dimensions, weights folded into archetype totals under the standing rubric (dimension band 3–14, weights sum 100). With MDR-0032 this closes the assessment's scored-decision gap. As with Move #2, the record here is summary-level on purpose: the per-client corpus survivability fraction and the per-client gate verdict are engagement work, so this page carries the ratification and the method, not those numbers.

Why this won. A security buyer defends detection and compliance to an auditor or a board, so they have to carry weight in the total rather than sit beside it as context. Scoring them as one combined security-fit dimension was considered and rejected, because detection survivability and compliance WORM gates fail independently and on different evidence, so they score as two axes, not one.

Decision. A positive control the original measurement lacked: the SigmaHQpySigma-backend-athena plugin (v0.2.0) emits a real enforced window (a RANGE frame over a 600-second interval) for event_count, and executed over the same planted corpus it fires the 20 true bursts at precision 1.0 with zero decoy false positives, while removing only the window frame reproduces the windowless over-fire. So the window-drop is a property of the backend plugin's templates, not of the engine or of SQL, and a single engine can land in different survivability classes depending only on which plugin compiles its rules. The proposed re-score (raise the Presto-family engines whose available plugin emits the window) was surfaced to the owner and declined; no scored cell moved, and the finding is recorded as a capability note in the scoring files.

Why the owner declined. The positive control is deliberately weighed as too thin to move a paid band: it covers event_count only (the plugin leaves value_count andtemporal_ordered unimplemented), it ran on in-process DuckDB with two disclosed dialect adaptations rather than production Athena or Trino, against one synthetic corpus, on a backend with no PyPI release. The scoping ruling underneath is the durable part: survivability scores configuration-as-deployed, the floor a typical client gets through the generic windowless backend, not capability-available, and the flip-conditions for revisiting are named in the record (a windowed backend covering the full count family, run on a production Presto-family engine, at released maturity, against a real client rule mix).

Decision. StarRocks concurrency_multi_tenant_behavior moves from 2 at Tier C to4 at Tier B at Archetypes A and B, on the first-party concurrency-multiuser bench that ran 2026-06-15 (QPS ceiling 6.79, tail p95/p50 about 1.16 at N=16, 1.27× headroom, zero errors, the best-behaved arm in the run). The same cut brings every other engine's concurrency cell current to the measured record rather than moving its score: ClickHouse and Trino gain the first-party citation with the single-host caveat stated and their 4s holding, the Dremio cells note that the arm ran with its figures withheld under that vendor's benchmark-publication terms, DuckDB's cells note its architecture-driven exclusion from the concurrency bench, and the Trino Archetype-B cell re-tiers from B to A on the named-operator Pinterest production citation that MDR-0003 treats as Tier A. Component 3's evidence vintage is now 2026-06-15, and the stale engines evidence-completeness figure rides the same cut from 0.875 (7 of 8, pre-v1.3) to 0.889 (8 of 9 after MDR-0023).

What it moves. StarRocks at Archetype A goes from bounds of 2.57–2.77 to2.87–3.07, and because the new lower bound clears DuckDB's upper bound of 2.83 cleanly the published ordering changes rather than merely tightening: ClickHouse (3.65–3.85) leads, Trino (3.41–3.61) follows, and StarRocks now sits above DuckDB (2.63–2.83) instead of below it, which moves StarRocks to third on the four-candidate public table. At Archetype B the total moves from 2.70 to 2.80 with the ordering unchanged, and the Archetype C cells were already 4 at Tier B, so they only gain the first-party citation.

Why this won. The 2 rested on a stated ground ("no published data on concurrent Archetype A workload") that stopped being true the day the bench published, and Archetype C had already carried StarRocks at 4 on vendor production references, so the A and B cells sat two points lower on the claim that the evidence C accepted did not exist. Holding at 2 with a refreshed citation was rejected as indefensible, since the new evidence removes the cell's own justification and points up rather than sideways. A 3 under-credits the arm the bench measured as best-behaved. A 5 was refused because a single-host, single-shape, closed-loop, OSS-edition result with 1.27× headroom does not establish design-center concurrency, and MDR-0002 reserves 5 for that. The transfer assumption, that single-host closed-loop behavior on one scan-aggregation shape is informative for an archetype's mixed scheduled and interactive load, is written into every re-scored cell as a caveat rather than left implicit. The falsifier named here landed the same day: the Trino cell did come under pressure and moved, which MDR-0038 below records.

Decision. A verifiable product-spec fact counts as Tier A, and the definition is deliberately narrow: it has to state the existence, structure, or licensing of a shipped capability rather than its performance, it has to be checkable at a primary source the reader can reach, checking it has to be one step with a yes-or-no answer, and it has to be version-bound. Trino's connector listing, DuckDB's embedded-library architecture, and Athena's native Glue integration all qualify. Anything about how fast, how large, how cheap, or how reliably that capability performs does not, and falls back to the ordinary rules.

Why this won. The tier-enforcement pass rewrote every legend on the site to state MDR-0003 faithfully, which was right, and it exposed a category the record had never addressed: a number of cells carried Tier A on product-structure facts that are neither peer review, nor a standard, nor a named-operator production reference. The retired vendors-page legend had covered them with a spec-fact clause, and that legend was removed because the rest of it was wrong. Re-tiering all of them to B was the obvious alternative and it was rejected, because it would put a fact anyone can verify in one step in the same tier as a conference talk, which inverts the credibility ordering the scheme exists to express. Adding a fifth tier was rejected too, since the five-tier scheme had just been retired for good reason.

What it moves. No score changes, because tier and score answer different questions. The rule cuts both ways and demoted more cells than it protected on the day it was written: a first-party SDW essay is never the Tier-A basis for a cell, which took three Cribl cells and the Glue Archetype-C cost cell down to B, and an anonymized reference is not a named operator, which took the Dremio Archetype-B raw-performance cell down to B however large the deployment behind it. The falsifier is built in — if a cell tiered A this way rests on a capability that turns out not to exist as described, or existed only in a version the cell does not name, the category should collapse into Tier B.

How the parts fit together.

Foundational MDRs (1–5, 12–16) set the structure. Per-component criterion sets (6, 8, 10, and 29 for Component 5) define what gets scored. Per-archetype weight tables (7, 9, 11, 17, 18, 19, 20, 21, 22) are where the workload-conditional "best" claim lives. The three v1.3 additions close evidence gaps (23 and 24 now Accepted, with 24's YAML application deferred to the refresh trigger; 25 still Proposed). The migration-instrument records (26–31) add the decision instrument, and the records after them (32–37) ratify the two Moves, apply the two measured re-scores, settle the registry's data custody, and stamp the v1.4 engines evidence cut of 2026-07-20.

The Q3 2026 catalog benchmark, the remaining slices of the OLAP bake-off (the single-host engine-join slice ran 2026-06-10; the cluster, federated-join, and AWS-native scenarios are still open), and the ~Q1 2027 H1-COST-02 pipeline benchmark are the primary refresh anchors. If any of those shows a weight is over-rewarding a candidate that fails in practice, the relevant MDR gets superseded, not amended silently.