Security Data Works

Capability Matrix · Compliance / WORM (cross-cutting axis)

A mandated control disqualifies, it doesn't discount.

For a regulated buyer, failing WORM or legal-hold is a disqualifier rather than a low score a good cost number can outweigh. So compliance is a cross-cutting axis scored like Practitioner-Ownability and Cost-to-serve (1–5 per candidate, stack-wide), with one addition: it is gate-capable. When the client's regime mandates a control, a candidate that cannot satisfy it is filtered out of contention before weighted totals are computed.

This is an illustrative storage/catalog profile under a regulated-FSI regime (a 17a-4 WORM mandate + a region-residency mandate), Tier B from vendor documentation and standard conformance. The per-client regime, gate set, and gate verdict are the engagement work product.

MDR-0030 — five sub-criteria, two gate-capable

The axis, and where it can hard-gate.

WORM / immutability

gate-capable

17a-4(f) / SEC / DORA write-once-read-many

Legal-hold

selective immutability, hold/release without breaking retention

Chain-of-custody / audit-trail

row-level lineage + tamper-evidence; anchored to Iceberg V3 row-lineage

Residency enforcement

gate-capable

data-locality that holds under federation

Retrieval-SLA at cold tier

produce records under a regulator's clock from cheap storage

Scored under the illustrative regime

The gate runs before the weighted total.

CandidateWORM*Legal-holdChain-of-custodyResidency*Retrieval-SLAaxisgate
S3 Object Lock (compliance mode)553434pass
MinIO + Object Lock (on-prem)443544pass
Iceberg + Polaris (managed catalog)444433.8pass
Iceberg + Nessie (OSS path)432433.2pass
Plain S3 (no Object Lock)122432.4DISQ

* gate-capable sub-criterion · DISQ = disqualified under the mandated regime regardless of axis score

Plain S3 (no Object Lock) is disqualified under this regime, because it cannot enforce WORM / immutability and a strong residency or retrieval score does not buy that back. That is the difference between a gate and a weighted criterion: a gated candidate does not appear in the ranked output regardless of its other scores. The two existing cross-cutting axes (ownability, cost-to-serve) only score; this is the first that can disqualify, on the MDR-0024 Go/No-Go lineage.

The audit-trail honest limit

Row-lineage is not free on the open path today.

The chain-of-custody sub-criterion anchors to Iceberg V3 row-lineage, and the regulated buyer's exact need is partially unreachable on the open stack right now: V3 row-lineage is blocked on the OSS pyiceberg + Nessie path (pyiceberg #1551 open; Nessie 0.107.5 silently downgrades V3 to V2; DuckDB iceberg_scan() does not expose _row_id), and is reachable on Spark/Java writers plus managed catalogs (Polaris-recent, Databricks-Unity, Snowflake-Polaris). That is why Iceberg+Nessie (OSS) scores a 2 on audit-trail while the managed-catalog path scores a 4. The matrix states that gap rather than implying lineage is free, because naming the limit is the fair-broker move even though a skeptic can quote it back.

This axis feeds the augment-vs-replace risk gate (Move #2): for a regulated buyer the compliance gate often decides first, disqualifying the cost-cheapest path before the crossover is even read, which is exactly the flip-sensitivity the board read names. Paired with detection-survivability, these are the two security axes that turn the matrix from a lakehouse comparison into a security-data-architecture decision.

Honesty boundary

What this illustrative version holds back.

Decision: MDR-0030. Feeds the decision-path risk gate; the detection half is detection-survivability.