Service Offering 3 · The design track
The architecture work that ends in Performant.
Offerings 1 and 2 make the data trustworthy and well-connected. Offering 3 is the design track: the vendor-neutral architecture decision for greenfield or post-Splunk environments, validated against your workload rather than the brochure. Two paid entry points scoped to where you actually are. This page is the working detail behind that decision: the principles, the detection-strategy call, the economics, and the build sequence.
How to engage
Two entry points, scoped to risk tolerance.
The Migration Assessment was the shape for a Splunk-anchored exit, and the Architecture Assessment was the shape for the wider input space. A "no-go" finding counted as a successful engagement. Under-scoping a deployment that drops the team into operational debt is the failure mode the framework is designed to avoid.
Wedge · 2–3 weeks · $30K–$50K
Splunk-to-MOAR Migration Assessment
The flagship engagement when the stack is Splunk-anchored. The benchmark projected against your workload — on a 10M-event Zeek corpus, the lakehouse engines run the hunting-shaped aggregations 5–62× faster than a schema-on-read SIEM (46.8× native / 10.1× over Iceberg on the five-query average; the index actually wins the simple lookups), answer-equality verified, single-node Tier B — with quantified TCO, workload classification, engine recommendation, risk register, phased roadmap, and executive deck.
Foundation · 2–4 weeks · $40K–$80K
Architecture Assessment
The clean-sheet design engagement for greenfield, post-acquisition, or regulated environments where Splunk isn't the binding constraint. Five-step audit, twelve-scenario decision framework, component selection, three-year TCO, phased roadmap, signed ADR.
What MOAR is
A modular open architecture, not a product
MOAR (Modular Open Architecture) un-bundles the monolithic SIEM into composable layers connected by open standards. The canonical deployment is the same nine components the capability matrix scores. Each component is a deliberate choice from open formats and purpose-fit tools, and each can be swapped without re-platforming the others. I keep the full breakdown (what goes in each component, the candidate tools, where lock-in actually sits) on the MOAR thesis page rather than repeating it here. This section of the site was the engagement detail: the methodology the assessment applied, not the argument for the architecture.
The design track is where that architecture becomes a defensible decision artifact for your specific environment. The four pages below are the working detail behind it, the same analysis the assessment runs, published openly so you can evaluate the depth before you buy the work.
The working detail
The methodology, in the open
Methodology
The five design principles.
Vendor-neutral data layer, storage/compute separation, compression-first design, schema evolution without breaking changes, query-engine specialization. Each one carries the falsifiable validation test the assessment runs.
Methodology
Query-based, pipeline-based, or hybrid detection.
The detection-architecture decision the engagement makes, and why the post-2026 latency reality forces the detection tier to seconds-to-sub-second while hunting and analysis stay on the lake.
Methodology
The cost model, with the unfavorable comparisons left in.
The MOAR monthly decomposition, the SIEM platform comparison, when each platform actually makes sense, query-volume behavior, and the staffing caveat. Procurement-grade, not a pitch.
Methodology
The four-phase implementation roadmap.
Lakehouse foundation, real-time engine, transformation pipeline, optional semantic layer, plus the five pitfalls the engagement front-loads its audit to prevent.
How the design track was scoped.
I'm not taking engagements while I work full-time, so this page stays up as a record of how the work was scoped. The method behind it is public on the lab and the Matrix, and I'm glad to talk about the research by email.