How can a parser field rename silently stop a SIEM rule from matching, with no error?

## Why nothing errors A detection rule is compiled into a query and run by a search backend. Those backends are built for logs, not for a fixed schema: the same query is expected to run across sources where some fields are present and some are not, and where new fields appear all the time. So the near-universal semantics are that an unknown field is *absent*, and a comparison against an absent field is *false* - not an error. `dns.query` endswith one thing, `dns.query` matches a regular expression, `dns.query` has more than N distinct values per zone: after the field disappears, every one of those is false for every event, forever. Everything downstream then behaves correctly. The scheduled search executes on time. It scans millions of events. It returns zero rows. Zero rows is what a search returns when nothing matched, and that is exactly what the platform reports - success. No alert is created, so no analyst notices. The rule's own health page, if there is one, usually shows scheduling and completion status, and both are green. The failure is invisible at every layer that anyone actually looks at. ## The shapes silent mutes come in Renaming is the clean case; the family is larger, and they are worth being able to list: - **Field removed or renamed.** The predicate can never be true. This is the case above. - **Value reshaped while the field survives.** The most dangerous variety, because field-presence checks pass. Examples on resolver logs: the parser starts writing the queried name in lower case where the rule matched mixed case; it keeps or strips the trailing dot of a fully qualified name; it truncates long names at a fixed width, which destroys precisely the long-label and entropy signal that a tunnelling rule keys on. A DNS label may be up to 63 octets and a full name up to 255, so tunnelling traffic sits at the long end of the distribution - exactly what a truncating parser flattens. - **Type changed.** A string becomes a structured object, or a count becomes a string; comparisons stop behaving and often stop matching. - **Time moved.** The field the search windows on is renamed, or its parsed time zone changes, so events land outside every scheduled window even though they are indexed. - **Routing changed.** The data goes to a new index, data set or log-source label, and the rule's scope no longer covers it. Note that only the first one is caught by asking `does this field exist`. A real check has to look at population *and* shape. ## The organisational cause, and the check that fixes it In a shop where an in-house parsing pipeline is released on its own cadence, the parser team's contract with the SOC is implicit: they believe they are producing logs, and they are, while the SOC believes it is consuming a stable set of fields, and it is not. A release note saying *the query field is now `question_name` for consistency* is a perfectly reasonable engineering change, and asking humans to read every release note and cross-check it against hundreds of deployed rules is not a control - it is a hope. The durable fix is a contract test that lives in the parser's own pipeline, not in the SOC's calendar: 1. Derive, automatically, the list of fields the deployed detection content depends on - from the rules themselves, not from a hand-maintained document. 2. On every parser change, run a sample of real events through the new parser and assert that each of those fields is present, non-null and of the expected type and shape for the sources that should carry it. 3. Fail the parser build when the contract breaks. Renames then become a coordinated change with the content owners instead of a five-month blind spot. On the detection side, the complementary control is per-rule input monitoring: track the event count matching only the rule's log source and prefilter clauses, and alert when it falls off a cliff. That catches the reshaped-value and routing cases as well as the rename, and it is the signal that would have spoken on the fourteenth. ## Before and after, in one line of log The pair of records below is the whole failure. Same resolver, same client, same query - two consecutive parser releases. The rule was written against the first shape and never touched. Nothing in the platform reported anything wrong, and the only observable effect was the thing nobody was monitoring: alerts went to zero.