Pattern detection after abstraction
The pattern detection worker never reads vendor metric names. It does not know whether the underlying signal came from Kafka consumer lag, OpenSearch queue rejection rates, database connection wait times, or analytics ingestion backpressure. By the time events reach the pattern worker, all of that vendor-specific vocabulary has been mapped to a small set of invariant behavioral categories: BACKPRESSURE_ACCUMULATION, QUEUE_GROWTH, RETRY_AMPLIFICATION, and their siblings from the operational primitive vocabulary.
This is the operational payoff of the abstraction work described in the previous series arc. The causal intelligence and abstraction engines established that behavioral patterns transfer across technology stacks when they are expressed in vendor-neutral terms. The pattern detection worker is where that principle becomes a runtime mechanism. A single pattern document can describe a cascading backpressure loop as a conjunction of primitives, and the detector will match that pattern whether the underlying technology is Kafka, PostgreSQL, Elasticsearch, or any other system that produces the same behavioral signatures.
The sliding-window model
Pattern matching requires a temporal model of the operational state. A single primitive event arriving in isolation rarely carries enough information to identify a pattern. Distributed system failures develop over time: a queue starts growing, backpressure accumulates upstream, retry amplification follows. Detecting this sequence requires maintaining a window of recent primitive activity and asking whether the window's contents match any known pattern signature.
The detector maintains a five-minute sliding window. Each new primitive event is added to the window, and events older than the detection horizon are evicted. The window represents the system's current behavioral state, not a single point-in-time snapshot. Five minutes is chosen to be long enough to capture the multi-stage development of common failure cascades while short enough that the window content remains relevant to whatever response is being considered.
For each pattern in the library, the detector applies two checks against the current window contents.
A full signature match occurs when every primitive listed in the pattern's signature is present and active in the window. This is the strongest possible match: all the behavioral components of the failure mode are simultaneously present. The match score for a full signature match is the pattern's confidence value, which reflects the historical reliability of this pattern as a diagnostic signal.
A precursor match occurs when the pattern's precursor primitives are all active but the full signature has not yet appeared. Precursor matching is the early-warning mechanism. The system recognizes that the initial conditions for a known failure mode are present, even before the failure is fully developed. Precursor matches use a reduced score to distinguish them from full matches, and the recommendation they generate indicates anticipated rather than confirmed pattern activation.
Candidates below a confidence threshold are suppressed. Those that survive are sorted by score and capped before publication, ensuring that the downstream recommendation consumers receive a ranked, bounded set rather than an unbounded stream of low-confidence hypotheses.
Mutable pattern library
Patterns are loaded from a persistent store rather than compiled into the worker binary. This matters because the pattern library is expected to evolve. As the reinforcement feedback worker accumulates outcome data and updates pattern confidence scores, the distribution of match priorities should shift. Patterns that consistently produce actionable recommendations when matched become higher-priority candidates. Patterns that produce noise or fail to predict actual incidents see their confidence erode and eventually fall below the detection threshold.
The worker falls back to a set of seed patterns when no learned patterns are available. The seed patterns cover a small number of common distributed system failure modes that are well-understood and do not require empirical calibration: cascading backpressure, connection pool saturation, retry storm progression, and similar canonical signatures. These seed patterns ensure that a fresh deployment can produce useful recommendations immediately, before any outcome history has accumulated to inform the learned library.
This fallback-to-seeds structure reflects a general principle in the cognitive substrate: a system should be able to operate at reduced capability when its learned state is unavailable, rather than failing entirely. The seed patterns are the pattern detection equivalent of the developmental engine's seed phase: limited but functional, providing a foundation for learning rather than a replacement for it.
Recommendation events as diagnostic signals
When a pattern match clears the confidence threshold, the worker emits a recommendation event. The recommendation includes the pattern identifier, the match score, the pattern's outcome description (what the pattern predicts will happen if nothing changes), and the pattern's ordered list of interventions (what actions have previously been associated with resolution of this pattern).
The recommendation is diagnostic rather than autonomous. It gives incident response systems, human operators, and downstream policy engines a ranked interpretation of the current operational state. It does not take action. This separation is deliberate: automated remediation requires additional policy controls, approval gates, blast-radius assessment, and rollback logic that belong in a later stage. The pattern detector's job is to recognize what is happening; the job of determining what to do about it belongs elsewhere.
This reflects the same principle that the arbitration engine applies within the cognitive loop. The pattern detector is analogous to the critic agent: it evaluates current conditions against known failure signatures and produces a scored recommendation. The actual execution decision is separate.
Why system-agnostic patterns transfer
The key invariant is that pattern documents describe behavior in terms of primitives and cannot depend on vendor names, metric names, cluster identifiers, or topology-specific labels. The detector is therefore small because the complexity of system adaptation has been isolated in the telemetry mapping layer that precedes it in the pipeline.
Consider what a vendor-specific pattern library would require. A pattern for Kafka consumer lag buildup followed by OpenSearch queue rejection would need to reference Kafka-specific metrics like consumer_lag_max, Elasticsearch-specific queues, and the specific thresholds defined in the monitoring configuration of a particular deployment. That pattern could not be reused in a different environment even if the underlying failure dynamic was identical.
A primitive-based pattern for the same failure describes BACKPRESSURE_ACCUMULATION followed by QUEUE_GROWTH. Any system whose telemetry mapping produces those primitives under those conditions will trigger the pattern. The cognitive substrate can maintain a single pattern library that applies across every instrumented service, rather than maintaining separate pattern catalogs for each technology stack.
This is what the abstraction work buys in operational terms: not just theoretical generality, but a concrete reduction in the maintenance burden of the pattern library and a concrete increase in the range of systems that benefit from accumulated pattern knowledge.