Context
Some engineering work takes years before it can be discussed openly. Patents, export controls, customer confidentiality, and internal review cycles all delay what the people doing the work already know is finished. That gap is demotivating in a field that rewards visible output. Achievements that cannot be named still count, but they are harder to point to when explaining what you have been building.
We recently saw one such piece of work become public. A patent application we led on rules processing for security event streams has been published as US20250310354A1. Publication does not change the underlying ideas. What changes is that they are on the public record, open to read and cite beyond the team that developed them. The operational shift is small but real: we can finally point clients, collaborators, and future hires at the document instead of describing the work from memory.
The sequential bottleneck
Most rule engines evaluate rules in a fixed order against every event they receive. As the rule set grows, so does the cost per event. In threat detection pipelines, where event volume is high and rules accumulate from research, customers, and internal teams, that pattern becomes a binding constraint. Latency rises, compute spend follows, and teams start trading detection coverage for throughput.
The bottleneck is not that rules are bad. It is that the engine treats the full set as uniformly applicable. A rule written for endpoint telemetry is still evaluated against gateway events. A rule that only applies when a particular platform configuration is present still runs everywhere else. Sequential processing of an undifferentiated rule list scales poorly because most rules are irrelevant to most events.
Teams respond with indexing, short-circuiting, and partitioning, which help but do not change the default model. Every event still hits the full rule set before anything narrows it down. Refactoring rules into smaller services shifts the cost rather than removing the mismatch between rule scope and event context.
What the application describes
The application outlines a different shape for the engine. Detection rules live inside rule objects that also carry selection criteria: metadata that defines which events, platforms, or contexts should load those rules at all. When an event arrives, the system determines its context, selects the applicable rule objects, and evaluates only that subset.
In practice, that means treating rules as self-describing artifacts matched to context-appropriate event streams, rather than running every rule against every event. The approach targets enterprise security monitoring: event vectors from endpoints and network assets flowing into a central stream, with detections and responses triggered when a loaded rule matches activity in an event object.
Rule objects also carry refinement instructions: how to label a detection, which channel receives an alert, or what metadata accompanies a report. Bundling reporting logic with the detection rule avoids a second pass over results to interpret what a hit meant. The full specification covers platform configuration, entity modeling, and response workflows; we will not reproduce claim language here.
Read the application at US20250310354A1. Additional background on our patent work is on the people page.
Takeaways
Publication arrives long after the ideas it describes. Review cycles, assignee process, and counsel timelines sit between finished work and a document anyone outside the team can read. We treat finished as finished: what we have shipped, tested, and defended in review is not provisional just because it is not yet public.
The design lesson from this application is separate and concrete. A rule should declare the events and configurations that should load it, and the engine should honor that declaration before evaluation runs. Deferring that decision until the rule set and event volume have both scaled turns a design question into an infrastructure problem.