Security Data Works

Reference architectures

What’s actually working in production.

Once an architect sees what good infrastructure looks like, the next question is always the same: who has actually shipped it? This is the public catalog, sorted into four classes by how much you can trust each pattern. Internal client engagements aren’t here; those are anonymized and gated in case studies.

Reference catalog summary

Today: pick two. Need: focused, evidence-based advocacy on every one.

Why this order

Sorted by how much trust each class can bear.

A named, validated teardown carries more weight than a vendor blueprint with no production validator yet. The fifth class — the gated internal case study — slots second by evidentiary weight even though it lives off this public catalog.

  1. 01

    Public production architecture teardowns

    Real, named, production-validated deployments reconstructed from the public record — conference talks, engineering blogs with measured outcomes. The strongest evidence in the catalog.

    Carries the most weight — independently verifiable, named, validated.

  2. 02

    Internal case study (gated)

    SDW's own client engagements, anonymized and gated in case studies. The matrix scoring that justified each architecture is the paid deliverable. The line is drawn at attribution, not at a password.

  3. 03

    Component references

    A single engine or store, isolated: what it does, where it fits in the pipeline, what it composes with, and what's brittle at scale.

  4. 04

    Vendor blueprints

    Vendor-proposed patterns with no named production validator yet. What ships today, what doesn't, what it changes for architects, and the honest critique.

    Explicitly unproven until a named production validator exists.

  5. 05

    Methodologies

    Cross-cutting practices and specs that span implementations — detection-as-code, SQL-metadata lakehouse, MLOps for model-assisted threat hunting.

    Cross-cutting practice — orthogonal to the validation axis, listed last.

Case study · public reference · analyzed by SDW

Atlassian’s Project Banyan on Databricks + OCSF.

A close case study of Atlassian’s Project Banyan: a lakehouse-native security data platform on the Databricks medallion architecture — security telemetry normalized to OCSF on the Silver layer, Unity Catalog governance, more than 21 billion events queryable in under a minute. Atlassian built and operates it; this page analyzes the architecture, drawn from their public Databricks story. Internal numbers beyond the published record stay Atlassian’s.

Read the case study →

How the catalog grows

Public knowledge, not vendor IP.

A new entry lands only when the source material is publicly attributable — a conference talk, an engineering blog with measured outcomes, a vendor case study with the customer named — and when the architecture is mature enough that the failure modes are visible in the public record, not just the marketing one. That gate is why a teardown can be trusted and a vendor blueprint is labeled as unproven rather than dressed up as a deployment.

The split is deliberate: the public catalog is free thought-leadership, the engagement work and the matrix are the IP. That is why the gated internal case study sits off this catalog while still ranking second by evidentiary weight above.

Working patterns also get contributed upstream to the CISA Joint Cyber Defense Collaborative, where the fair-broker thesis lands at industry scale. Patterns become public knowledge, not vendor IP.

See how the pattern lands on your workload.

The matrix scoring that justified each reference architecture's tool choices is the paid deliverable. The benchmark behind it is public — reproduce it on your own workload, then book a call to scope the work.