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 intro call confirms which shape fits. The Migration Assessment is the right shape for a Splunk-anchored exit; the Architecture Assessment is the right shape for the wider input space. A "no-go" finding is 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, ClickHouse runs the hunting-shaped aggregations 21–62× faster than a schema-on-read SIEM (46.8× 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 seven 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 is the engagement detail: the methodology the assessment applies, 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.
The architecture, as a decision you can defend.
The intro call confirms which entry point fits: the Migration Assessment for a Splunk-anchored exit, the Architecture Assessment for the wider input space.