AxoDetect · In design with partners
Detection where your data lives.
Detections don't break because rules are written too slowly. They break because the data underneath them is fragmented, dynamic, and fragile. AxoDetect starts at the first mile.
The industry is automating the wrong mile.
Rule generation is the last mile of the detection pipeline. Stabilizing the data those rules run on is the first. Almost all of the investment is going to the wrong one.
Faster rule generation doesn't close the gap.
Teams are producing more detection content than ever and still falling behind. When output goes up and coverage doesn't, the bottleneck is somewhere other than authoring — and pointing automation at the last mile only produces more rules that rest on the same unstable ground.
The data layer is fragmented, dynamic, and fragile.
Telemetry arrives from dozens of sources in dozens of shapes, spread across SIEMs, lakes, and cloud storage. Formats change under you when a vendor ships an update. A field silently renames, and a rule that passed review last quarter now matches nothing.
Engineers can't see the data, so the feedback loop never closes.
Writing a good rule requires looking at real telemetry, and that access is gated by another team. Rules get written blind, and nothing flows back from what the detection did in production to the person who wrote it. Breakage is discovered during an incident.
AxoDetect is integrated into the data layer so detection happens in stream and the data engineer, detection engineering feedback loop is closed.
Four beliefs about the first mile
1. Detection goes to the data, not the other way around.
Fragmentation is the starting condition, not a phase to migrate out of. The detection layer meets data where it already sits — SIEM, lake, or cloud storage — so onboarding a new source is a decision about signal rather than about budget and migration windows.
2. Rules should be written against stable ground.
A detection written against a raw vendor format inherits every change that vendor makes. Normalize first, then author against the normalized shape in an open, readable format — so a parser update becomes a pipeline event instead of a silent coverage loss.
3. Fragile means untested. Testing is the fix.
Both sides move: attacker behavior and the telemetry describing it. A rule is a hypothesis about both, so it should be testable against real sample data and versioned like code — making a change routine rather than something nobody wants to touch.
4. Coverage is a data question before it's a rule question.
A technique is only covered if a rule exists and the data feeding it is arriving in the shape that rule expects. Coverage should be measured against both, so a broken source shows up as a gap on the matrix rather than as silence.
An early look at what we're building toward
These are workflow sketches from active design work with partners, not shipped screens. Sequencing is deliberate and undated — first the stable data layer, then everything measured on top of it.
Stabilize the first mile, then write once
Normalize telemetry as it arrives, then author against that shape and target the environments you already run. Maps to pillars 01 and 02.
- Telemetry is collected and normalized on arrival
- Detection is written against the stable shape
- Pick the environments it should run against
- Source changes surface as pipeline events
See coverage, including where the data broke
Coverage measured against attacker techniques and against source health, so drift surfaces as a gap. Maps to pillars 03 and 04.
- PAN-OS Threat / URL
- Windows Security 4104
- Auth brute force · corp-vpn
- Cobalt Strike beacon
The questions a skeptic asks first
What do you mean by first mile and last mile?
The last mile is rule generation — writing and tuning detection content. The first mile is everything the rule depends on: collecting telemetry, normalizing it, and keeping it stable as sources change. Most automation spend goes to the last mile. Our argument is that the first mile is where detections actually break.
Is AxoDetect available today?
Not generally. It is pre-GA and in active design with partners. Nothing on this page is a claim about a shipped feature set — where we describe capability, we describe what we are building toward.
Isn't this just a data pipeline product?
The pipeline is the foundation, not the point. What it buys you is detection logic written against a shape that does not move, and coverage numbers that account for whether the underlying source is still healthy. Pipeline without detection leaves the same gap in a different place.
Who is this for right now?
Teams with detection engineering already in place, running more than one data environment, who have watched a rule quietly stop matching after a source changed. If you are standing up a first SIEM, we are probably early for you.
What happens if the roadmap changes?
It will. Partners hear about it from us first, and the four pillars on this page are the part we intend to be held to — the specifics underneath them are what the program is for.