After a merger, two proxy feeds share one normalised action field with different meanings — what breaks?

## The shape of the failure After an acquisition, the SOC inherits a second web proxy. Its records arrive as LEEF, with an `action` attribute whose values are allow, deny, observed and alerted. The incumbent proxy has its own action vocabulary. To get one set of dashboards, the mapping author collapses both onto a single normalised action field, matching value names that looked equivalent. They were not equivalent. On the incumbent, deny means the request was refused and never reached the site. On the inherited proxy, most of the estate runs in monitor mode: deny means the policy matched and was recorded, and the request went through anyway. This is a **semantic** defect, not a syntactic one, and that is what makes it hard. There is no parse failure — the value is a legal member of the target enumeration. No rule goes silent — content matches the field and produces results. Every dashboard renders. The system is working exactly as built and telling you something false. ## What it costs - **Verdicts invert.** A responder triaging a hit to a known-bad domain sees action deny, concludes the control prevented it, and closes the case. On the inherited feed the connection completed. - **Hunts miss.** A hunter looking for successful egress filters to allowed traffic and excludes exactly the population that was allowed but recorded as denied. - **Metrics lie upward.** A blocked-versus-allowed ratio reported to leadership now mixes enforcement with observation and reads as better coverage than exists. - **The wrongness is durable.** Because nothing failed, nobody is prompted to look. Silent absence at least eventually raises the question "why is this quiet?"; silent wrongness raises nothing. ## Finding it Three checks, in increasing cost: 1. **Value distributions per feed.** Group the normalised field by source product. Two feeds with wildly different proportions of the same value — one 40% deny, the other 2% — is not proof of anything, but it is the question that starts the investigation. 2. **Internal consistency in the same record.** A blocked request should look blocked in its other fields: no meaningful response size, a status consistent with refusal, no downstream fetch. A record claiming denial while carrying a successful status and a large body is the contradiction that settles it. 3. **External corroboration.** Correlate a sample of supposedly denied destinations against a different observation surface — DNS query records or network flow records showing bytes actually moving to that destination. Flow records carry the five-tuple, counts and timestamps and no payload at all, which is enough here: the question is only whether bytes moved. ## Fixing it properly The instinct is to remap the inherited feed's deny onto the nearest better-fitting value and move on. Do more than that: - **Model enforcement mode explicitly.** Whether a control was enforcing or observing is a fact about the event and deserves its own attribute rather than being smuggled into the action value. OCSF separates disposition from activity for this reason; ECS separates `event.action` (what happened) from `event.outcome`, whose allowed values are success, failure and unknown. - **Write down which reading you chose.** Even `event.outcome` is ambiguous for a block: success can mean the block succeeded or the fetch succeeded. A mapping that does not state its reading will be misread by the next person as surely as this one was. - **Never drop provenance.** Keep the observer vendor and product on every normalised event. Two feeds whose meanings differ can then be qualified in content, and any future divergence is addressable rather than invisible. - **Treat an absent equivalent as a schema request, not a rounding problem.** If a source has a value with no honest home in the target schema, the answer is to extend the schema or add a field, not to map it to the nearest neighbour. Enumerations and booleans are where collapse hurts most, because a wrong member is indistinguishable from a right one. ## Cleaning up behind it A corrected mapping only fixes events ingested from now on. Two things remain: - **Re-normalise history from the retained raw events** for the window the wrong mapping was live, if raw retention covers it. This is the only reason the raw copy exists. - **Re-triage the affected verdicts.** List the cases from the inherited feed closed on the reading "prevented, no impact" during that window, and work them again. Some will be genuinely fine; some are unremediated successful connections that the SOC has already told itself it handled. Scope both by the window, and say so — an open-ended re-review of everything is how this work gets abandoned. ## Onboarding discipline that prevents it When a new feed arrives, require the mapping author to enumerate every distinct value of every enumerated field, write one sentence about what each means in that product, and name the target schema value. Any row where the sentence and the target disagree is the defect, caught before content is built on it. It is an hour of work per feed, and it is the cheapest hour in the pipeline.