The ground you're already standing on.

If you've been doing this for a while you've probably got your own version of that story, and I think the reason these failures are so common and so hard to see is that nobody told us we were doing data modeling. We think we're writing detections. We're writing field mappings and normalization rules and parser configs, and underneath all of it we are making decisions about what the things in our data are and how they connect, which is the actual definition of data modeling, and we're mostly making those decisions implicitly, by hand, with no check that any particular decision was right. So I want to make a case I think is worth your time even though it sounds dry on the label: data modeling is the foundation you're already standing on, you've been doing it the whole time without naming it, and once you have the vocabulary for it there's a check you can run that catches exactly the silent failure I just described.

Walk through what happens to a log on its way to becoming a detection. A vendor's appliance emits a record. Some integration parses that record into fields. Those fields get normalized into a shared shape so your content doesn't have to be rewritten per vendor, and if you're on a modern stack that shape is probably OCSF, the open schema that says a network-connection event has these attributes with these names. Your detection is written against that shared shape. At every one of those steps somebody decided that this piece of the raw log means that field in the normalized event, and every one of those decisions is a claim about meaning. Saying a vendor's dest field becomes OCSF's dst_endpoint is a claim that the thing the vendor called a destination is the same kind of thing OCSF means by an endpoint, and that claim can be right or wrong, and most of the time nothing checks which.

That's the part worth slowing down on, because it's where the trouble lives. The shape is one thing and the meaning is another. The shape is "there's a field here called dst_ip and it holds an IP address." The meaning is "this is the address the connection went to, not the one it came from." A mapping can get the shape exactly right and the meaning exactly wrong, and when it does, your tooling won't complain, because schema-conformance only checks the shape. The field is present, it's the right type, it validates. It just means the wrong thing, or it points at a path that isn't there, and the detection downstream inherits the mistake without any signal that a mistake was made.

This is what I mean when I say you're already doing data modeling. The choice of which raw token becomes which normalized field is a modeling choice. Whether a given field is the actor or the target, the source or the destination, the process or the file the process ran from, is a modeling choice. You make dozens of them every time you onboard a source, and the quality of your detections rests on those choices being right far more than it rests on the cleverness of the detection logic, because a brilliant rule keyed on a field that means the wrong thing is still a rule that matches nothing.

Here's the awkward part I have to be honest about, because it's the whole reason this isn't a solved problem already. D3FEND off the shelf doesn't catch the silent error. It ships only three disjointness pairs in the entire ontology, and none of them are among Process, File, UserAccount, NetworkSession, and NetworkNode, the artifacts your core OCSF objects actually map to. So nothing in D3FEND says an entity that is a process can't also be a user account, which means a reasoner has no basis to object when you map a user to a process, and the wrong mapping sails through. The silent-failure mode isn't only in the integrations and the LLMs that generate mappings; it's baked into the reference ontology itself, because the assertions that would let a machine catch the error were never added.

So the gate I built adds them. It grounds each mapping two independent ways, the OCSF path it maps to and what the source field itself actually means, then asserts a disjointness layer over the handful of artifacts those mappings touch, and asks ELK, the reasoner, whether the two groundings agree. A type-preserving mapping agrees and stays satisfiable, which is the formal way of saying "this could be true." A type-crossing mapping, a user mapped to a process, disagrees under the disjointness layer and becomes unsatisfiable, a class that can't possibly be true, and the reasoner flags it and the build exits non-zero. That's a deductive gate: it catches the mapping mistake that silently kills a detection by checking meaning, not just syntax, with no machine-learning model anywhere in the loop, just logic over definitions.

The numbers are the reason I think this is worth your attention rather than a neat trick. Run against a real six-schema crosswalk corpus, 925 mapping rows drawn from CIM, UDM, ASIM, ECS, OpenTelemetry, and Zeek into OCSF, with the type-crossing corruptions injected the way the silent error happens in the wild, the gate caught 100% of them, 231 of 231 distinct mapping classes, with zero false positives attributable to the disjointness layer. It missed nothing in the error class it targets. And on the way it flagged about eight genuine coarse mappings in the real hand-built corpus that a human reviewer should look at, an application mapped to a destination host, a principal used as a host, a file path mapped to a process name, which is the gate doing exactly the job you'd want, finding the meaning-crossings a shape check waves through. The first-pass version isolates a single wrong mapping as the one unsatisfiable class in 3.69 seconds over the full D3FEND ontology on a laptop, half a gigabyte of memory, so this is the kind of check you could put in CI and have it run on every pull request, not a research artifact that needs a cluster.

I want to be careful about what I'm claiming, because the honest boundaries matter. This is Tier B evidence: my own groundings, my own disjointness adjudication, a single corpus, one reasoning pass. The 100% catch is measured on injected corruptions, not a held-out set of confirmed human errors, because the corpus doesn't ship labeled mistakes; the eight organic flags are the closest thing to real catches and they're plausible coarse mappings, not confirmed-wrong ones. The hard part, and the part nobody wants to do, is the disjointness adjudication itself, deciding which artifacts are genuinely disjoint versus legitimately overlapping, because a credential can be stored in a file, so asserting that a credential is never a file would break a valid mapping and manufacture a false alarm. That judgment held across this corpus with eight artifacts; a much larger surface might hit a wall this one didn't. I'd rather tell you that than oversell it.

The same split between shape and meaning shows up one layer down, in the bytes themselves, and it caught me off guard while I was building the corpus for this. I'd assumed that re-deriving the same data produces the same file, and so the same hash, which is the assumption underneath content-addressed storage, dedup, and chain-of-custody integrity checks. It doesn't hold by default. Write the same rows to Parquet through a parallel query engine like DuckDB and the file's size and its SHA-256 move from run to run, because the engine hands back rows in a different order each time and the encoding is order-sensitive, even though the data is identical down to the row. A hash of the file is a shape check, and it can disagree while the substance is unchanged, so an integrity check can report a change that never touched the data. The fix is the one the open formats already made, comparing logical content rather than raw bytes, which is why Iceberg tracks identity at the manifest level instead of asking you to diff files: the check has to be aimed at what the data means, not the form it happens to take.