Security Data Works

Methodologies

Practice that spans implementations.

A methodology isn’t a product or a single deployment — it’s a cross-cutting practice or spec that holds regardless of which engine sits underneath: detection-as-code, SQL-metadata lakehouse, MLOps for model-assisted threat hunting. Orthogonal to the validation axis, which is why these sit apart from teardowns and blueprints rather than above or below them.

Methodology

1000+

DetectFlow — detections without operational debt

Detection-as-code architecture pattern for SOCs whose detection backlog grows faster than the team can maintain. Versioned, tested, deployable rules; CI/CD…

Read the breakdown →

Methodology

926×

DuckLake — SQL metadata for the lakehouse

Methodology for managing lakehouse metadata in a transactional SQL database rather than as JSON/Avro manifest files in object storage. Three-layer separation…

Read the breakdown →

Methodology

Level 2

MLOps for threat hunting

Operationalizing Model-Assisted Threat Hunting (M-ATH) from the PEAK framework. A notebook model degrades the moment telemetry shifts or an adversary adapts…

Read the breakdown →

Methodology

3.6–10.1×

Splunk federated integration with the MOAr stack

Integration pattern for organizations with deep SPL investment that need lakehouse economics on 30+ day data. Keep Splunk as the analyst UI; route high-value…

Read the breakdown →

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.