detect Framework

Design decisions

Framework v0.3.0, updated September 19, 2026.

Six decisions shape everything else.

One schema drives the site and the repository. Stage names, gate wording, metric definitions, and the score model live in framework.json. The website renders that file, and the repository's lint step validates every rule record against it. When the framework changes, both change from the same edit.

Every stage has one exit gate that can be counted. "The rule is validated" is not a gate. "Replay passed in both engines, the converted query matches the approved copy, and a second engineer approved the change" is a gate, because a CI run can report whether it happened.

Prioritization is a scored backlog. Each candidate carries six numbers and a note saying where each number came from; CI computes the score and refuses a score typed in by hand. The site's prioritize page runs the same formula in the browser so a leader can move the weights and watch the order change.

The Sigma status field marks the stage. A rule with status experimental is in build, test means validate, stable means deploy or tune, deprecated means retired. Nothing else has to be kept in sync to know where a rule stands.

Detection zero is the log source silence alert. Every other rule depends on its data arriving, so the first rule a program ships is the one that notices when a source goes quiet. Coverage by that alert is one condition for the highest readiness score.

Coverage is weighted by robustness. Each live rule counts as its Summiting the Pyramid level divided by 5, so seven rules that match tool names can add up to less coverage than four rules that match the behavior.