Ontological governance is governance grounded in shared definitions of what things actually are, and it’s the necessary companion to the epistemological side of governance. Where epistemology asks how we know what’s true about our APIs, ontology asks the prior question: what are the things we’re governing in the first place? What is an API? What is a capability? What is an application? What is a resource? What does “customer” mean in our schema, and is it the same customer everyone else in the organization is talking about? Ontology is the discipline of defining the categories, concepts, and entities that make up your API domain, and shared ontology — agreement on what things are — is the foundation that governance has to stand on. You cannot govern consistently if different teams mean different things by the same words, and getting the ontology right is some of the deepest and most stabilizing governance work there is.
I drew the ontological-versus-epistemological distinction explicitly in 2025, and it’s a genuinely useful frame for thinking about governance. Ontological governance is rules-based and oriented toward a defined, stable state — it asks “what are the things, and what rules apply to them,” and it treats governance as establishing and enforcing a settled set of definitions and standards. Epistemological governance is knowledge-based and oriented toward perpetual negotiation — it asks “how do we know what’s true, and how do we keep learning,” and it treats governance as an ongoing process of discovery. Both are necessary. The ontological side gives you the stable definitions — this is what a capability is, this is what an API is, these are our entities and their properties — that make consistent governance possible. The epistemological side keeps you honest about the limits of what you know and the need to keep refining. Governance that’s purely ontological becomes rigid, enforcing definitions that may no longer fit reality; governance that’s purely epistemological never settles enough to actually govern. The healthy practice holds both.
The “what is” questions are the concrete expression of ontological governance, and I’ve spent a lot of time on them. I’ve written pieces asking what is an API, what is an application, what is a capability — and these aren’t pedantic exercises, they’re foundational ontological work. When I wrote in 2025 about what a capability is, I was doing ontology: defining the entity precisely enough that an organization can agree on it, govern it, and build on it. The reason these definitional questions matter so much for governance is that ungoverned ontology is where drift begins. If your organization hasn’t agreed on what an “application” is in the context of your API management, then different teams will model it differently, your governance rules will apply inconsistently, and the confusion will propagate through everything built on top. The “what is” work is the work of establishing the shared ontology that consistent governance requires.
Schema is where ontology becomes concrete and machine-readable, and it’s why I’ve called schema work the most stabilizing API work. A schema is, in a real sense, an ontology — it defines what entities exist, what properties they have, and how they relate. When you define your data models in JSON Schema, you’re encoding your organization’s ontology: this is what a customer is, these are its fields, this is what’s required. I wrote in 2025 that schema work is the most stabilizing API work precisely because getting the ontology right at the schema level stabilizes everything downstream. The shared, agreed-upon, machine-readable definition of what things are is the bedrock. This is why I’ve also warned that locking up a taxonomy is short-sighted — because ontology, while it needs to be stable enough to govern by, also needs to remain open and evolvable, not frozen into a rigid hierarchy that can’t adapt as the domain changes. The ontology has to be settled enough to govern and open enough to evolve, which is a genuine tension.
The vocabulary dimension is the human side of ontological governance, and it’s where a lot of governance actually succeeds or fails. I wrote in 2017 about the words we use to describe our API technology — because the language, the shared vocabulary, is the surface of the ontology. When teams use the same words to mean the same things, governance has a foundation; when they use the same words to mean different things, or different words for the same things, governance fragments. The taxonomy work I did for the human services data specification, adding a taxonomy API to support the domain, was ontological governance in practice — establishing the shared categories and definitions that let everyone in a domain speak precisely about the same things. This vocabulary and taxonomy work is unglamorous, but it’s foundational, because the ontology lives in the shared language, and the shared language is what lets a distributed organization govern consistently. Getting people to agree on what words mean is genuinely hard, expensive, political work — and it’s exactly the work that makes everything else in governance possible.
The connection to domain-driven design and to capabilities is where ontological governance becomes most powerful and most current. Domain-driven design is, at its heart, an ontological discipline — it insists on a shared, precise model of the domain, a “ubiquitous language” that everyone uses consistently, which is exactly the ontological foundation governance needs. The capabilities work I’ve done recently is ontological too: defining a capability as a clear, agreed-upon entity — a business-aligned, self-describing unit of what an organization can do — is establishing the ontology that lets capabilities be governed across business and engineering. The deepest insight of ontological governance is that the definitions come first. Before you can write rules, run engines, or enforce standards, you have to know what you’re governing — what the entities are, what they mean, how they relate. The ontology is the substrate, and governance built on a shaky or contested ontology is governance built on sand. The organizations that do the hard, foundational work of establishing a shared, precise, machine-readable ontology of their API domain — agreeing on what capabilities, applications, resources, and entities are — give their governance something solid to stand on. The ones that skip it find their governance constantly undermined by the fact that nobody quite agrees on what they’re governing. Ontology is the answer to “what are the things,” and getting that answer shared and stable is the foundational governance work that everything else depends on.
References
- The Words We Use To Describe Our API Technology
- Locking Up Any Taxonomy Is Short-Sighted In Today’s Online Environment
- I Added A Taxonomy API To Support The Human Services Data API (HSDA)
- What Is An Application
- OpenAPI Governance Using Rule-Based Or Script-Based Approaches
- What Is API Governance
- Schema Work Is The Most Stabilizing API Work
- Ontological vs Epistemological API Governance
- What Is A Capability
