Policy as reasoning: writing WAF rules without writing regex.
1 Matrix Systems Innovations Ltd, Cardiff CF10
Abstract
We describe the MatrixGuard specification language, its deterministic compiler, the thirty-day simulator that gates promotion, and the runtime that emits a per-block English explanation rather than a regex match. Across fifteen months at a Cardiff specialty retailer that rewrote eleven of twenty-eight enforced rules from regex into specifications, false-positive blocks on the rewritten rules fell by seventy-three percent and stayed there; the overall block rate did not change. The point of the rewrite is not to block more; it is to know what is being blocked, and why.
Why regex WAFs degrade.
A regex WAF answers one question well — does this request match this string? — and a great many other questions only by accident. The rule that was meant to block credential-stuffing also, accidentally, blocks the internal monitoring tool. The rule that was meant to catch SQL injection also catches the URL-encoded characters in a perfectly legitimate query string. Each rule is written once, never re-read, and accumulates over years into a 2,400-line file no one quite wants to touch.
The degradation is not in the regex; the regex does exactly what it says. The degradation is in the gap between what the regex says and what the operator meant. A specification language closes the gap, not by being smarter, but by making the operator's intent the artefact under version control.
The specification, the compiler, the simulator.
A MatrixGuard policy is a specification in English with a thin DSL frame. The English is what the security analyst writes. The DSL handles what English is bad at — rate windows, set membership, cryptographic predicates, time arithmetic. The compiler reads both, produces an enforcement bytecode, and is deterministic: the same input yields the same output across builds, signed against the release tag.
The simulator runs the compiled bytecode against the last thirty days of your production traffic on the WebMatrix data model. The output is the false-positive delta, the false-negative delta, and the per-rule sample of blocked sessions with the explanation each block would have emitted at runtime. The promotion gate is the simulator output. No exception path.
The runtime, with explanation.
At runtime, MatrixGuard evaluates the compiled bytecode against the request, the session state and the data-model attributes the spec required. On a block, the runtime emits the request to the customer's tenanted incident log with an English explanation interpolated from the spec's explain field. The explanation cites the predicates that triggered, with their actual values at the moment of the block, and links the block to the trace through the trace-id.
The MatrixObserve surface picks up the block on the same data model. A spike in MatrixGuard blocks shows up in incident paragraphs not as "WAF triggered" but as "the credential-stuffing policy blocked 412 sessions in the last 90 seconds, of which 408 carried the rotating-UA header; the policy spec is policies/credential-stuffing.spec v3, last promoted 02 Apr".
The Cardiff case study.
Our earliest MatrixGuard customer — a Cardiff-headquartered specialty retailer — moved from a regex stack to MatrixGuard in January 2025. Over the fifteen months that followed, the operations team rewrote eleven of their twenty-eight enforced rules into specifications. We have, with the customer's explicit written permission, made the rewrites and the corresponding simulator outputs available in the customer note linked from the changelog.
| Metric | Pre-rewrite | Post-rewrite (Q1) | Steady state (12+ months) |
|---|---|---|---|
| False-positive blocks (rewritten 11 rules) | baseline 1.00× | 0.27× | 0.31× |
| Time to author a new policy | ~ half day | ~ 30 min (incl. simulator read) | ~ 30 min |
| Policies team felt comfortable enforcing | 28 | 33 | 41 |
| Overall block rate (all rules) | baseline 1.00× | 1.01× | 1.00× |
| Mean post-mortem write-up time (security-led) | ~ 2 h | ~ 35 min | ~ 35 min |
Table 1 Fifteen months at the Cardiff retailer. The number that did not move — the overall block rate — is the most important one. The platform did not start blocking more or less; the operator started understanding what was being blocked.
What this does not do.
Honest negatives
- MatrixGuard does not detect a zero-day with no precedent in the simulator window. The simulator only knows what your traffic looked like; if the exploit class is new, the simulator is uninformative.
- MatrixGuard does not auto-promote a policy that the simulator says raises false positives, however small. The gate is the gate; the operator can override with a signed waiver, in writing, on file.
- MatrixGuard does not use your traffic to train models we then sell to other customers. The simulator runs on your data, in your tenancy. The customer's traffic stays the customer's.
- MatrixGuard does not replace your incident-response team. The runtime explains the block; the post-mortem and the policy change are still yours to author.
Bring your hardest-to-read policy.
The most useful first conversation about MatrixGuard is held against the policy your security analyst keeps meaning to refactor. Forty-five minutes, against the WebMatrix simulator on your last seven days of traffic. Written note same day. The note tells you which rules are clearly worth rewriting, which are not, and the false-positive budget at which the rewrite would not pass the promotion gate.