SG/Sentinel Rule Architecture Strategy: Rules As A Fractal Graph
Summary
How the rules are structured: as a fractal graph — rules within rule sets, packs that activate only when a triggering rule fires, rules that select which rules run next — so the cost of a request is proportional to the rules it traverses, not the total rule count. Each rule carries rich metadata (semantic-graph position, compliance mapping, ATT&CK technique, next-rule connections, confidence, layer, data needs) and IDs-everywhere traceability follows every request through its lifecycle. The research half mines the existing body of work: CRS anomaly scoring for combining opinion rules, paranoia levels for tuning, the standard attack categories, and the honest caveat that regex rules are adversarially evadable.
Key concepts
- The fractal graph — the designed structure the MVP's flat list grows into
- Rich rule metadata — attack tags, confidence and actions — present in the registry from day one
- The art-of-the-possible reduction — encrypted objects and static pages make the valid space tiny, so the invalid is obvious
- Reuse vs build — reuse CRS patterns and anomaly scoring; build the app-coupling, the graph, the traceability
Key ideas
- A request for /etc/passwd is never valid; a PHP page on a static site is never valid — the easy wins are easy because the valid space is constrained.
- The deterministic-to-opinion spectrum lets rules express how sure they are; the engine combines confidences instead of treating every rule as binary.
- Our edge over pure-CRS WAFs is the app-coupling plus the async LLM layer that catches what regex misses.
On this site
The rules page's graph section and metadata table; the six MVP rules are this brief's easy-win category, built first as it prescribed.