Catching the mistake that kills a detection.

The honest starting point, and the part that surprised me when I went looking, is that this isn't a gap in your tools so much as a gap in the reference material your tools build on. The natural place to ground a security schema is D3FEND, MITRE's map of defensive techniques and the digital artifacts they act on, because D3FEND already defines what a Process and a File and a UserAccount are as things a defense operates against. So if you want a machine to check that your OCSF field mappings line up with reality, D3FEND is where you'd anchor them. The trouble is that D3FEND, off the shelf, gives a reasoner almost nothing to object to.

Here's the specific fact the whole thing turns on. A reasoner, which is just the program that works out what follows from what you've told it, can only flag a contradiction if you've stated the facts that contradict. To catch "you mapped a user account to a process," you need a stated rule that says a user account and a process can't be the same individual thing. That kind of rule has a name, disjointness, and it's the assertion on the map that two kinds of thing are genuinely distinct even when they're related to each other. D3FEND ships only three of these disjointness pairs in its entire ontology, and none of the three sit among Process, File, UserAccount, NetworkSession, and NetworkNode, which are exactly the artifacts your core OCSF objects map to. Those five are each just declared a kind of some parent, with nothing saying any two of them are distinct. So nothing in D3FEND says a thing that's a process can't also be a user account, which means a reasoner has no basis to complain when you map one to the other, and the wrong mapping sails straight through.

That changes where the silent failure lives. It isn't only the integration that wrote the bad mapping, and it isn't only the LLM that generated it, it's built into the reference ontology itself, because the assertions a machine would need to catch the error were never written down. You can run the strictest validation you like against raw D3FEND and it will catch nothing of this kind, not because your check is weak but because the map it's checking against has nothing to say on the question.

I measured this two ways, a clean first pass and then a run against a real corpus, because a mechanism that works on a toy proves nothing.

The first pass is the one-wrong-mapping demo. Take a small set of correct groundings, inject the exact silent error (map actor.user to Process, the actor-as-object confusion), merge it into the full D3FEND ontology rather than a trimmed slice, and reason over the whole thing. ELK isolates exactly the one wrong mapping as the single unsatisfiable class and does it in 3.69 seconds using about half a gigabyte of memory, on a laptop. That timing is the part that makes this practical rather than academic, because a check that runs in seconds on a laptop is a check you can drop into CI and run on every pull request, not a research artifact that needs a cluster.

The corpus run is the one that tells you whether the judgment holds at any scale. I ran the gate against a real six-schema crosswalk corpus, 925 mapping rows drawn from CIM, UDM, ASIM, ECS, OpenTelemetry, and Zeek into OCSF, of which 364 had both groundings and were therefore testable, across 231 distinct mapping classes. Against injected type-crossing corruptions, remapping a correctly-typed field to a disjoint artifact, the gate caught all of them, 231 of 231, with zero false positives attributable to the disjointness layer. And on the way through it flagged about eight coarse mappings in the hand-built corpus that a human ought to look at, an application mapped to a destination host, a UDM principal used as a host, a file path mapped to a process name, which is the gate doing the job you'd want, catching the meaning-crossings that a shape check waves through.

Now the boundaries, because the numbers oversell themselves if I stop there. 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 on a held-out set of confirmed human errors, because the corpus doesn't ship labeled mistakes, so the honest reading is "it misses nothing in the error class it's designed to catch," not "it catches every real-world mistake anyone has ever made." The eight organic flags are the closest thing to real catches, and they're plausible coarse mappings rather than confirmed-wrong ones. And the genuinely hard part, the part that decides whether this scales past my eight artifacts, is the disjointness adjudication itself, because over-asserting it manufactures false alarms. A credential can be stored in a file, so if I'd carelessly asserted that a credential is never a file, a perfectly valid "this credential lives in a file" mapping would fail the build for no good reason. The distinction that saves it is that disjointness is about identity, not relation: a process is executed from a file and the two are related, but the individual that is the process is not also the file, so asserting they're distinct is sound. Getting that call right for every artifact pair is bounded human work that needs real judgment, and it held across this corpus's eight artifacts, but a much larger surface could hit a wall this one didn't, and I'd rather you hear that from me than discover it after you've trusted the gate further than it's earned.