The history of email security is a cat-and-mouse game where each side has learnt to bypass the previous round. Rule-based filters were bypassed by content variation. Content classifiers were bypassed by human-grade prose. Reputation systems were bypassed by newly-registered domains. Each generation of detection produces a generation of bypass.
The defence is not to ship a smarter individual detector. It is to ship combinations that attackers cannot bypass without defeating multiple orthogonal signals at once. That is what cross-feature rules are.
What a cross-feature rule is
A cross-feature rule is a named, declarative policy that combines two or more independent signals into a single decision. Example: "recipient has been in a credential leak in the last seven days AND the sender has never been seen before AND the message contains a financial instruction". The rule fires when all three conditions are true.
Each of the three underlying signals is individually weak. Plenty of real business email involves new senders. Plenty of legitimate traffic contains financial instructions. Leaked credentials happen to users who are never attacked. The fact that all three conditions occur at once on the same message is structurally suspicious.
If each of three independent signals has a 10% false-positive rate in isolation, the combined rule has a 0.1% false-positive rate at the conjunction. The statistical argument is simple. The engineering work is in making the signals truly independent.
The nine rules we shipped
In v1.2.0 we shipped nine named cross-feature rules, covering patterns we had observed repeatedly in case data but which no individual detector fired on reliably. Each rule has an explicit name, a documented pattern, a per-tenant toggle, and a false-positive counter.
The named-rule approach is different from a black-box ensemble. When a rule fires, the customer can see which rule fired and why. When a rule has a false-positive rate above a threshold, the customer can disable it. When we tune a rule, the tuning history is auditable.
Why naming matters
An anonymous ensemble score is a number. A customer cannot negotiate with a number. A named rule is a hypothesis — "this pattern suggests this attack class" — and a hypothesis can be examined, challenged, and refined.
When a SOC analyst reviews an alert and decides it was wrong, they need to know which rule fired so they can decide whether to tune it, disable it, or refine the underlying signals. An unnamed ensemble produces alerts that are correct on average but opaque in detail. Named rules produce alerts that are inspectable by design.
The operational discipline
Every rule has a monthly review cadence. False-positive rate, true-positive rate, and fire volume are tracked per rule per tenant. Rules that drift outside their expected range produce a review ticket. Rules that consistently fire with high precision earn weight in the consensus engine. Rules that fire noisily earn a tuning pass.
This is engineering discipline applied to detection, not marketing about AI. The AI layer is one input. The rules layer is where the ensemble's decisions become legible.
Attackers bypass detection generation by generation. Named rules make the defence generation-aware: when a rule is bypassed, we know which rule, which signals stopped firing, and where the defence needs to evolve. An unnamed ensemble tells you only that something is not working as well as before.
The signals, combined, are more useful than any one of them alone. The naming makes the combination maintainable.