Author — detections for any source you onboard

Detections built on the data you actually have.

Most detection content fails quietly: rules written for fields your telemetry doesn't populate. Qvasir grounds every rule in measured reality.

Field-aware authoring — the editor knows which fields your sources actually populate, with what values, at what rates.
Validated against the real schema — structural, semantic and field-level checks run on demand, with a quality score and every error located in the rule. "That field does not exist here" is caught while you write it, not by silence in production.
Backtesting & calibration — replay a rule against your historical events before deploying it, and see expected alert volume up front.
A deliberate path to production — rules move Draft → Testing → Production on your say-so, and the engine reports back whether each one is actually loaded and firing.

Detection editor: readable rule text on the left, configuration, tuning, and calibration panels on the right — The detection editor: readable rule text, source-bound schema context, tuning and calibration side by side.

Where detections come from

Four ways to start, because good ideas arrive in four shapes.

A detection rarely begins with someone opening a blank editor. It begins with a source you just connected, a gap on a coverage matrix, a hunch after an incident, or a CVE that landed on a Friday. Qvasir can start from any of them, and each one produces rules written against the fields your sources actually carry.

From a source

"I just onboarded this. What is worth detecting in it?"

It reads the source's actual telemetry and proposes concrete detection ideas — each naming the technique, the specific fields that make it feasible here, and the events it would target.

From a gap

"The matrix says we cannot see this technique."

Start from an ATT&CK technique and it builds toward that coverage, using the sources in your estate that could witness it.

From an idea

"I want to catch this behaviour."

Describe it in your own words. Your guidance is binding on the generation, not a hint it can quietly ignore.

From a vulnerability

"This CVE affects us. Would we see it?"

A CVE, a scanner export, or a purple-team result becomes candidate detections — the worked example below.

The first one is the one that matters most, and it is the least discussed. For Windows and Sysmon there is a decade of community content to borrow from. For a Proxmox cluster, a UniFi firewall, a building-management system or an application your own team wrote, there is nothing — no rule pack, no blog post, no Sigma rule to adapt. Writing detections for those sources means learning the data first, and that is exactly the work Qvasir does before it proposes anything. The less common your estate, the more this is worth.

What "generated" means here

It writes the rule, then tries to prove the rule is wrong.

Most AI rule generation ends at plausible text. This one ends at a rule that has been checked against your schema and fired against the real engine — or at an honest refusal.

It picks its own context

Where a source carries dozens of event shapes, the relevant ones are chosen before generation begins — by inspecting the catalogue rather than taking the highest-volume ones, because the low-volume tail is where most attack telemetry lives. It also checks what you already have, so it is not rewriting a rule you wrote last month.

It validates, corrects itself, then audits the result

Every candidate goes through the same validation an authored rule does — against that rule's own cluster schema. What fails goes back for correction with the field catalogue attached, so "use fields that exist" is actionable rather than an instruction. A separate pass then audits each survivor cold, and any fix it makes is reverted if re-validation finds a new error.

It proves the rule actually fires

A rule that matches nothing is the most common failure in detection content, and it is invisible on inspection. So the platform constructs an event the rule should match — solved from the rule's own logic, not invented — and runs it through the same engine that will evaluate it in production. A rule that does not fire gets one more attempt, then is discarded with the failing selections named.

Then it checks the logic against your real events

Firing on a purpose-built event is a low bar: a condition that could never match your actual data still passes it. So each branch of the detection is replayed separately against real events from that rule's own cluster. Branches that cannot match the value shapes your source produces are reported — the rule still ships, because hunting for what history lacks is legitimate, but you are told which half of it is currently unreachable.

It is allowed to decline

"No rule" is a valid outcome with a stated reason, not an error and not an empty result dressed up as success. If your telemetry cannot support the detection you asked for, that is the finding.

Nothing is fabricated to fill a field

Detection conditions, ATT&CK tags, false-positive notes and triage guidance are never invented to make a rule look complete — and any allowlist value the model tries to add is stripped outright, because a generated exception is a blind spot nobody asked for.

The dependency, stated here too. Generation needs a reachable model provider — OpenAI, Gemini or Claude. Everything around it does not: writing and editing a rule by hand needs nothing but you, and the validation, calibration and deployment path those rules travel is deterministic either way.

A worked example

From a vulnerability to a detection, without waiting for a vendor.

A CVE lands on a Friday. The traditional path is to wait for your SIEM vendor to ship content for it, or to write the rule yourself against documentation and hope your telemetry carries the fields it assumes. Qvasir does neither.

01

Bring the finding

A CVE, a scanner export, or a purple-team result — whatever put the weakness on your radar.

02

Qvasir enriches it

What the weakness is, how it is exploited, and what that exploitation would look like in telemetry.

03

It names the sources

Which of your onboarded log sources could actually witness exploitation — and says so plainly when none of them can.

04

It drafts the detections

Candidate rules written against your real fields and validated against their schema — ready to calibrate against your history before you deploy them.

Step 03 is the one that matters most, and it is the one a content pack can never do: a detection is only as real as the telemetry underneath it. If nothing you collect could see the exploitation, the honest answer is a visibility gap — and Qvasir tells you that instead of shipping a rule that will never fire.

Rules are text, and the text is yours.

Readable, versioned, diffable

Every detection is human-readable FDL in git — reviewable in a pull request, diffable, and versioned per rule with its own history. No opaque rule store between you and your own logic.

See the grammar, with real rules →

One grammar, all three layers

Correlation, aggregation and low-and-slow detections are expressed in the same grammar as a simple match — so the hard rules are as reviewable as the easy ones.

Assisted, not automated away

Drafting is AI-assisted end to end and every generated rule is yours to accept, edit or reject. The model proposes; the validator checks it against your schema; you decide what ships.

Next: what runs those detections.

03 · Detect — the real-time engine →

Onboarded this morning.Detecting this afternoon.