Standards watch

Security has an ontology. It doesn't have a semantic layer.

The claim in this essay's title failed review the first time I made it, and the objection was a good one: MITRE D3FEND is machine-readable domain semantics with real governance behind it, published as OWL, queryable with a reasoner, so in what sense does security lack a semantic layer? The objection is right in one sense of the phrase and wrong in the other, and the fact that both readings are natural is most of what this essay is about. The phrase means one thing to the ontology community and a different thing to the data-platform community, the two artifacts do different jobs, and security has built exactly one of them. So before arguing anything I owe you definitions, and then I'll walk through what security actually has, why the gap is the binding from knowledge to tables and metrics, and why a quiet Apache incubator project is the first credible candidate to close it.

Reading time: about 15 minutes. Evidence tier: A where I cite standards bodies, project repositories, and specs I fetched directly (D3FEND 1.4.0, the Apache Ossie spec and incubation record, MITRE's published tooling); B where I lean on my own lab measurements; C where I repeat coalition membership counts, since those trace to the convening vendor's blog, and where I characterize community positions. I'll flag each as it comes.

When I swept the prior art, everything adjacent to a security semantic layer sorted into four classes, and the sorting is clean enough that I'll state it as the essay's core structural claim: each class has exactly what the others lack, and nothing sits at the intersection.

Schemas without metrics.

OCSF, Splunk's CIM, Elastic's ECS, and Microsoft's ASIM all define what security events look like, machine-readably and in detail, and none of them defines a single metric. That's not a criticism, since normalization is what they're for, but it bounds what they give you: a shared event shape with no shared account of what to compute over it. The closest historical attempt to go further was OSSEM, Roberto Rodriguez's community data model, whose relationship graph was real enough to feed the ATT&CK data-sources revamp; its repositories have been idle since late 2022 (last substantive push September 2022, not formally archived), and even at its peak it was a schema-and-relationships model, not a metrics layer. Tier A for the repo states, which anyone can check.

Metric catalogs without machine-readability.

The definitions exist, and they're good. SOC-CMM's metrics suite carries 101 named metrics aligned to its maturity model, in an unlocked spreadsheet under CC BY-SA. The SANS SOC survey and its metrics cheat sheet name the canon everyone recites: MTTD, MTTR, false-positive rate, ingest coverage. FIRST's Metrics SIG publishes incident-timing definitions, and NIST SP 800-55 is the standards-body treatment of security measurement. Every one of these is prose, PDF, or spreadsheet, which means every SOC that adopts them hand-translates each definition into its own SPL, KQL, or SQL, and two teams implementing "false-positive rate" from the same page will produce different queries. That translation loss is the exact failure OCSF exists to end at the schema layer and Sigma at the detection layer, still fully present at the metrics layer.

Coverage scores without semantics.

The one place security already exchanges machine-readable measurement is ATT&CK Navigator layers, the versioned JSON format (v5.3.2 as I write, actively maintained) that annotates a score onto each technique. Navigator layers prove the demand: teams genuinely want to hand each other "our coverage" as a file. But a layer's score is a number with no defined derivation, hand-assigned or emitted by a tool whose formula you can't see, so the format standardizes the exchange while leaving the semantics of the number private. And the organization best placed to fix that stopped: MITRE CTID's M3TID measurement model, the most explicit attempt to define threat-informed-defense measurement, was archived in June 2025. Tier A on both repo states.

Proprietary computation without a standard.

Meanwhile a commercial category computes security metrics all day: detection-posture products score rule inventories against ATT&CK, and Splunk's ITSI runs KPIs over CIM data models, which is the closest working precedent for metrics-over-a-security-schema anywhere in the industry. Every one of them is closed, and none publishes its metric definitions in a portable form, which is rational vendor behavior and also the strongest evidence that the demand is real and monetizable. The boundary on my claim: a web sweep can't see unpublished internal models, and ITSI is a working proprietary instance of the pattern, so the defensible statement is that no open, vendor-neutral, machine-readable security semantic layer exists, and that's the statement that matters if you want one you can adopt without buying it.

I also checked whether anyone had simply built a security model in the general-purpose tooling, a SOC-metrics package for dbt's semantic layer, a published Cube or LookML security model, and found nothing, which surprised me more than the standards gap did, because the tooling has been mature for years and the definitions have been sitting in SOC-CMM's spreadsheet the whole time.

There is now a serious attempt at an open interchange format for exactly this artifact. The Open Semantic Interchange launched in September 2025 as a Snowflake-convened coalition with Salesforce and dbt Labs as co-founders, published a v0.1.1 spec that December, and entered the Apache Incubator in June 2026 under the name Ossie, since the obvious acronym already belonged to the Open Source Initiative. The spec is a vendor-neutral YAML format for semantic models: logical datasets bound to physical tables, foreign-key relationships, model-level metrics as SQL expressions in named dialects, and an ai_context field at nearly every level for exactly the agent-grounding synonyms and instructions you'd expect in 2026. A draft ontology layer landed in May 2026, conceptual modeling with dataset mappings rather than OWL, which keeps the two-senses distinction intact rather than collapsing it. All of that is Tier A, read from the spec and the incubation record directly. The coalition's size, seventeen launch partners grown past fifty organizations, traces to the convening vendor's own blog, so treat the count as Tier C even though the direction is plainly real.

Here is the finding that made this essay worth writing: security is entirely absent. I enumerated the project's issues, discussions, and dev-list archives and found zero security, SIEM, SOC, or OCSF presence; the member roster contains no security vendor at all, no Splunk, no CrowdStrike, no Elastic, no Palo Alto; and the project's own roadmap names industry-specific semantic models as a goal with SaaS, finance, and retail as its examples. The first vertical working group, financial services aligned to FIBO, held its first formal meeting in July 2026. So the domain-model pattern is forming right now, finance went first, and nobody from our industry is in the room, which reads less like a snub and more like the two communities not sharing a vocabulary, the same collision this essay opened with.

To test whether the fit is real rather than rhetorical, I drafted a security-operations semantic model in the format: OCSF 1.8.0 event classes as fact datasets, ATT&CK techniques, ATLAS techniques, D3FEND defenses, and a Sigma rule inventory as dimension and bridge datasets, and eleven SOC metrics in governed ANSI SQL, detection coverage among them, defined once over the joins instead of re-derived per dashboard. The draft validates against the project's own tooling, and the exercise taught me three things worth passing on. The format handles the security shapes today, at definition level, without contortion; the standards themselves supply the dimension tables, which is a quiet advantage security has over most domains walking into this; and the coverage metrics come out honest only if you write the discipline into the definitions themselves, because a coverage number describes design-time structure, what content and defenses exist, and never operational efficacy, and a governed definition is exactly the place to make that caveat travel with the number.

The caveats are real and I'll state them plainly rather than let the greenfield excitement carry the paragraph. Ossie has zero ASF-blessed releases; the 0.2.0 schema on main carries an explicit warning that it may change; the reference converters are proof-of-concept CLI tools, not product features; the dialect enum today covers the BI world (ANSI SQL, Snowflake, Databricks, BigQuery, Tableau, MDX, MAQL) and not the engines a composed security stack actually runs, so ANSI SQL is your carrier; and the sharpest critiques deserve their names: Matthew Mullins has argued the MetricFlow reference implementation makes this standardization around one vendor's toolchain, David Jayatillake points out that Microsoft, holding the largest semantic-layer footprint through MDX and DAX, has little reason ever to join, and Coginiti's governance read is that a vendor-convened neutral standard carries a structural asymmetry the Apache move mitigates but doesn't erase. All Tier C as positions, all worth weighing. My read lands where the practitioner math lands: converging your metric definitions on the format is cheap and useful even if Ossie stalls, because a clean governed-metrics file is worth having regardless, while building a runtime dependency on a draft spec in 2026 would be premature.