Governance Ontology
Decision Infrastructure asks
“Should it still happen now?”
A governance ontology is the shared vocabulary describing what actions are admissible at execution time within enterprise systems. It is the semantic substrate of governed execution — not a policy document, not a workflow engine, not a rules-engine framework.
Most governance models describe what should happen.
A governance ontology defines what is admissible at execution.
- Policy management
- Workflow governance
- Compliance documentation
- Rules-engine marketing
- A semantic governance layer
- Execution admissibility vocabulary
- A runtime governance ontology
- The substrate of governed execution
What Is a Governance Ontology?
A governance ontology is the shared vocabulary by which an enterprise expresses, evaluates, and enforces what actions are admissible at execution time. It names the architectural primitives that runtime governance depends on — admissibility, authority, binding, runtime validation, escalation, evidence — and it anchors them to versions of policy, registries of authority, snapshots of input, and authoritative time.
Where a domain ontology models what business objects are — loans, contracts, accounts, transactions — a governance ontology models whether actions on those objects remain permitted at the moment they would commit. The two are orthogonal architectural layers, and the distinction is the structural basis of governed execution.
Decision Infrastructure is the category. Consequence Intelligence is what governed execution produces after the act. A governance ontology is the semantic layer that makes the category operationally real — without it, governance remains language rather than architecture.
Why Existing Governance Models Fail
Four categories of artifact are commonly mistaken for governance. None of them, individually or in combination, constitute a runtime governance ontology.
Describe what is permitted, but do not evaluate or enforce it at runtime. They are reference material, not architecture.
Decide once, at the moment a rule fires, against the inputs they are given. They do not re-anchor to live state, do not bind at the commit boundary, and do not produce evidence-at-execution as a structural property.
Route decisions through approvals and hand-offs. They do not re-evaluate admissibility at the act — the workflow can deliver a stale verdict to a live execution path and not know it.
Describe controls, attestations, and audit posture. They describe behavior; they do not enforce admissibility. A compliance framework can be perfectly documented and operationally inadmissible at the same time.
The result of mistaking any of these for governance is the same: language without anchor. The governance ontology is what replaces description with structural enforcement — the semantic layer that makes admissibility evaluable at execution, not asserted in documentation.
Governance Ontology vs Domain Ontology
The two ontologies are orthogonal. They operate on different architectural axes, and neither can be derived from the other.
What objects are
Loan · Contract · Account · Customer · Transaction · Asset · Policy. Structure, relationships, recorded state. Industry standards: MISMO, FIBO, HL7, LegalRuleML.
Whether action is admissible
Admissibility · Authority · Runtime Validation · Exposure · Binding · Evidence · Escalation. Action-temporal. Evaluated at runtime against live state.
For the full architectural treatment of the distinction — why the two cannot be collapsed, and what enterprises lose when they are — see the architecture brief: Governance Ontology vs Domain Ontology.
Runtime Admissibility
Runtime admissibility is the discipline that the governance ontology makes evaluable. At every commit, the question is not "was this approved earlier" but "is this admissible now, against the policy, authority, exposure, and evidence that are authoritative at this moment." The ontology supplies the vocabulary; admissibility supplies the verdict.
Without the ontology, admissibility cannot be expressed as an executable contract — the verdict has no structured basis, no anchored reference state, and no externally verifiable trace. Admissibility becomes assertion. With the ontology, it becomes a deterministic property of the runtime.
See: Runtime Admissibility — the canonical primitive page.
Commit Boundary
The commit boundary is the architectural location at which intent becomes consequence. The governance ontology supplies the executable contract that the boundary enforces — without the ontology, the boundary is a database transaction; with it, the boundary is a governance event.
Every term in the governance ontology — admissibility, authority, binding, runtime validation, escalation, evidence — resolves at the commit boundary. The boundary is where the ontology stops being vocabulary and starts being architecture.
See: The Commit Boundary — the canonical primitive page.
Decision Runtime Trace
The Decision Runtime Trace is the canonical record of how a decision moved from intent to consequence through admissibility, validation, binding, execution, and evidence. The governance ontology is what the trace is written in — every stage of the trace anchors to terms the ontology defines, and the trace is replayable because the ontology is version-anchored.
The trace is a primitive of Decision Infrastructure — not a log, not an audit trail, not a distributed-tracing span. It is the artifact that proves, deterministically, that the governance ontology was honored at execution.
See: Decision Runtime Trace — the canonical primitive page.
Evidence-at-Execution
Evidence-at-execution is the architectural property by which evidence is generated atomically with binding — recorded in the runtime trace at the moment of action, not reconstructed afterward from logs. The governance ontology specifies whatmust be captured (the admissibility verdict, the authority anchored, the policy version in effect, the inputs snapshotted); evidence-at-execution is when and how it is captured.
Reconstructed evidence is interpretation. Evidence created in-line at execution is fact. A system that cannot produce in-line evidence cannot claim governed execution — regardless of how thoroughly its policies are documented.
See: Evidence at Execution — the canonical primitive page.
Governed Execution
Governed execution is the composite outcome of the governance ontology operating across the runtime. Decisions form upstream; admissibility is evaluated at the commit boundary; binding occurs only when the executable contract is satisfied; evidence is generated in-line; the trace finalizes deterministically. The ontology is what makes each of those stages name-able, evaluable, and provable.
Architectures that contain a governance ontology can demonstrate governed execution as a structural property. Architectures that do not contain one can describe governance, but cannot enforce it at the moment of action.
See: Governed Execution — the canonical primitive page.
Why AI Agents Require Governance Ontology
AI agents reason fluently over domain ontologies. Given a rich model of what business objects are, they form plausible action plans at machine speed. What they cannot do, structurally, is determine whether the action they propose remains admissible against a live governance ontology — unless that ontology is loaded as an executable contract and evaluated at the commit boundary by an architectural layer designed for the purpose.
Without a governance ontology, AI agents in regulated environments are unaccountable in principle. There is no record from which their actions can be audited, replayed, or refused. The agent's reasoning chain is the only artifact, and the agent is asked to be both decision-maker and system of record — which is structurally incoherent.
With a governance ontology, AI-agent execution becomes governable at machine tempo. Each proposed action is evaluated against an admissibility surface the agent cannot rewrite. Binding occurs only when the contract is satisfied. Evidence is generated in-line. The agent participates in a governed runtime rather than acting as one.
The Future of AI-Native Enterprise Governance
As AI agents take consequential execution authority across regulated enterprise functions, governance becomes ontological rather than procedural. The question is no longer "did we document the policy" but "is the policy executable, version-anchored, evaluated at runtime, and provable in the trace." Each of those properties requires a governance ontology as its semantic substrate.
We expect a small number of governance-ontology standards to emerge in the next architectural cycle — comparable in role to MISMO, FIBO, HL7, and LegalRuleML on the domain side, but action-temporal and runtime-anchored. They will name admissibility surfaces, authority registries, escalation paths, and evidentiary requirements as first-class objects. Decision Infrastructure is built to bind to whichever of these standards an enterprise adopts — or to a governance ontology the enterprise defines for itself.
The future of enterprise governance is not better documentation. It is an executable ontology that an AI agent cannot rewrite, an architectural layer that enforces it at the commit boundary, and a runtime trace that proves it was honored.
The Governance Ontology — Index of Terms
The eight terms below are the runtime-enforceable primitives of the governance ontology. Canonical definitions live elsewhere — either on a dedicated concept page or in the canonical glossary at /decision-infrastructure-glossary/. The short context below is orientation, not definition. Follow the canonical link on each term to read the authoritative source.
- Admissibility
- The runtime property that an action is currently permitted given policy, authority, conditions, exposure, evidence, and risk.
- Binding
- The atomic architectural event at which intent becomes consequence — the system-of-record mutation. Admissibility must be verified before it occurs.
- Runtime Validation
- The continuous evaluation that runs between admissibility and binding — catching state drift before the act.
- Governed Execution
- Execution that proceeds only when admissibility is verified at the binding moment — the composite outcome the ontology produces at runtime.
- Evidence-at-Execution
- Evidence generated atomically with binding — recorded in-line at the moment of action, not assembled afterward from logs.
- Replay Governance
- The ability to reconstruct deterministically what an enterprise system should have decided at a prior moment, using only the inputs available at that moment. Requires that the governance ontology be version-anchored and that the trace preserve the policy, authority, and inputs in effect at each stage.
- Escalation
- A structured deferral of binding when admissibility cannot be deterministically decided. The action is held pending higher-authority review or additional evidence. Escalation is a first-class verdict, not an error.
- Continuous Admissibility
- Admissibility evaluated not once but continuously for the duration of an obligation — open commits, held positions, long-running disbursements re-evaluated as state changes.
Canonical: Runtime Admissibility →
Canonical: Commit Boundary →
Canonical: Runtime Admissibility →
Canonical: Governed Execution →
Canonical: Evidence at Execution →
Ontology-resident sub-term · deep-link: #term-replay-governance
Ontology-resident sub-term · deep-link: #term-escalation
Canonical: Runtime Admissibility →
Frequently Asked Questions
What is a governance ontology?
A governance ontology is the shared vocabulary that describes what actions are admissible at execution time within enterprise systems. It is the semantic substrate of governed execution — the layer that makes admissibility, authority, binding, runtime validation, escalation, and evidence expressible, evaluable, and enforceable at runtime. It is distinct from policy documents, workflow engines, and rules-engine frameworks: those describe or route; the governance ontology anchors enforcement at the moment of action.
How is a governance ontology different from policy management or a rules engine?
Policy management describes rules; rules engines decide on them once; workflow systems route the decision. None of those evaluate against live state at the moment of binding. A governance ontology defines the vocabulary that makes admissibility evaluable at execution — anchored to policy versions, authority registries, input snapshots, and time. The ontology is the semantic layer; runtime admissibility and the commit boundary are how the ontology becomes architectural.
Why isn't a domain ontology like FIBO or MISMO sufficient?
A domain ontology models what business objects ARE — their structure, relationships, recorded state. A governance ontology models whether actions on those objects remain ADMISSIBLE at execution time. The two are orthogonal — neither is derivable from the other. A perfectly modeled loan can still fail admissibility. A perfectly specified admissibility surface tells you nothing about the structure of the objects it governs. Most enterprise architectures collapse the two; the collapse is the structural failure mode behind a large class of AI governance failures.
What does runtime governance ontology mean in practice?
In practice, a runtime governance ontology means that every consequential action is evaluated against an executable contract — not against documentation. The contract names: who may act (authority), under what conditions (admissibility), against what evidence (runtime validation), at what binding moment (commit boundary), with what verdict (allow / hold / deny / escalate), captured as in-line evidence. The ontology is what allows these to be expressed as runtime primitives rather than aspirations.
Why do AI agents specifically require a governance ontology?
AI agents reason fluently over domain ontologies and propose actions at machine speed. Without a governance ontology loaded as an executable contract, the agent has no signal that an action is no longer admissible — and the enterprise has no architectural anchor for refusal. The governance ontology is what makes AI-agent execution governable at machine tempo: each proposed action is evaluated against an admissibility surface the agent cannot rewrite, and binding occurs only when the contract is satisfied.
Decision Infrastructure is the category. The governance ontology is the semantic layer that makes the category enforceable. Without it, governance is described. With it, governance is bound at execution.
Reference Surfaces
Reference Surfaces
Understanding a category requires more than comparisons. These reference surfaces explain the core concepts, architecture, vocabulary, and placement of Decision Infrastructure within the enterprise stack.
Definition
What Is Decision Infrastructure?
The canonical introduction to the category. Defines Decision Infrastructure, execution governance, runtime admissibility, and governed execution.
- Category definition
- Execution governance
- Runtime admissibility
- Governed execution
Placement
Where Decision Infrastructure Fits
Where Decision Infrastructure sits between Decision Systems and Consequence Intelligence in the enterprise stack.
- L4 Decisioning
- L5 Decision Systems
- L6 Decision Infrastructure
- L7 Consequence Intelligence
Architecture
Decision Infrastructure Architecture
The architecture that enables execution governance — how Decision Infrastructure operates across enterprise systems.
- Commit boundaries
- Runtime validation
- Execution control
- Evidence generation
Vocabulary
Decision Infrastructure Glossary
The canonical vocabulary of the category — the lexicon analysts can quote precisely.
- Runtime admissibility
- Commit boundary
- Execution governance
- Governed execution
- Evidence at action
Related Concepts
Architectural primitives the ontology specifies
The governance ontology is the semantic vocabulary. These are the primitives written in it and the operating model that runs them.
Runtime Admissibility
The property the ontology makes evaluable — that an approved decision remains permitted at the moment it acts.
Commit Boundary
Where the ontology becomes architectural — the point intent crosses into consequence.
Execution Governance
The discipline the ontology operationalizes — governance applied at the act, not the approval.
Governed Execution
The composite outcome the ontology produces at runtime.
Evidence at Execution
The architectural property the ontology specifies — evidence captured at the moment of action.
Decision-to-Execution Gap
The structural failure the ontology resolves.
Decision Runtime Trace
The artifact the ontology is written in — the immutable record of how a decision became an executed outcome.
System of Intelligence
The operating model that enacts the governance ontology at runtime.
Related Comparisons
Related Comparisons
Use these comparisons to understand how Decision Infrastructure differs from adjacent categories, systems, and governance models.
Decision Infrastructure vs Decision Intelligence
The category vs its output cousin — what produces decisions vs what governs them at execution.
Decision Infrastructure vs Decision Governance
Governance defines policy. Infrastructure operationalizes it at execution.
Decision Infrastructure vs Decision Control Plane
A control plane routes and coordinates actions; Decision Infrastructure governs whether each action should still happen at all.
Decision Infrastructure vs Decision Execution Engine
An execution engine runs the action; Decision Infrastructure governs whether execution may proceed.
Decision Infrastructure vs Runtime Governance
Runtime governance is a capability; Decision Infrastructure is the category that contains it.
Decision Infrastructure vs Decision Systems
Workflow-and-approvals systems exit before execution; Decision Infrastructure governs the act itself.
Decision Infrastructure vs AI Governance
AI Governance defines what should be allowed. Decision Infrastructure governs whether those permissions remain valid at execution.
AI Governance vs Decision Systems
Why model and process governance frameworks don't close the gap between approval and consequence.
Decision Infrastructure vs Digital Twin
Simulating reality vs governing what is allowed to happen in reality.
Sovereign Reasoning vs Decision Systems
Reasoning under jurisdictional and policy constraints vs the workflow systems that operationalize decisions.
Decision Infrastructure vs Agentic AI
Agents act autonomously; Decision Infrastructure governs whether each autonomous action is admissible at execution.
Decision Infrastructure vs MLOps
MLOps keeps the model healthy; Decision Infrastructure governs whether the decision it informs is admissible at execution.
Decision Infrastructure vs GRC
GRC documents and reviews controls; Decision Infrastructure enforces them on each action at execution.
Decision Infrastructure vs iPaaS
iPaaS connects systems and moves data; Decision Infrastructure governs whether the action between them should execute.
Decision Infrastructure vs Observability
Observability explains execution; Decision Infrastructure governs whether it should occur at all.
Decision Infrastructure vs Knowledge Graphs
Knowledge graphs map what is connected; Decision Infrastructure governs whether an action across those connections is admissible.
Decision Infrastructure vs Sovereign Reasoning
Sovereign Reasoning bounds how AI reasons; Decision Infrastructure governs whether the resulting action is admissible at execution.
Decision Infrastructure and Palantir
Palantir integrates data and drives action; Decision Infrastructure governs whether each action is admissible at execution — across any platform.
Decision Infrastructure and ServiceNow
ServiceNow runs and automates the workflow; Decision Infrastructure governs whether each action it fires is admissible at execution.
Decision Infrastructure and Pega
Pega manages decision workflows; Decision Infrastructure governs whether execution remains legitimate at the act.
Decision Infrastructure and Appian
Appian automates process execution; Decision Infrastructure governs consequence authorization at the commit boundary.
Decision Infrastructure and FICO
FICO optimizes decision quality; Decision Infrastructure governs whether a scored decision is still admissible at execution.
Decision Infrastructure vs Middleware
Middleware passes messages between systems; Decision Infrastructure governs whether the action a message triggers should execute.
Decision Infrastructure vs BPM
BPM orchestrates the process and moves work to the action; Decision Infrastructure governs whether that action should commit.
Decision Infrastructure vs Workflow Automation
Workflow automation runs the sequence; Decision Infrastructure governs whether each action in it should commit.
Decision Infrastructure and Salesforce
Salesforce runs the customer workflow; Decision Infrastructure governs whether each action it fires remains legitimate at the act.
Decision Infrastructure and Celonis
Celonis reveals how processes run and drives action; Decision Infrastructure governs whether that action is admissible at execution.
Decision Infrastructure and Icertis
Icertis manages contracts and obligations; Decision Infrastructure governs whether an action taken under them is admissible at execution.
Decision Infrastructure and Encompass
Encompass runs the loan workflow; Decision Infrastructure governs whether each consequential loan action is admissible at execution.
Decision Infrastructure and Empower
Empower runs loan origination; Decision Infrastructure governs whether each consequential loan action is admissible at execution.
Decision Infrastructure and Harvey
Harvey generates legal reasoning and drafts; Decision Infrastructure governs whether the actions taken from that reasoning are admissible at execution.
Decision Infrastructure and iManage
iManage manages legal knowledge; Decision Infrastructure governs the consequential actions taken using that information at execution.
Decision Infrastructure and Intapp
Intapp coordinates legal intake, conflicts, and approvals; Decision Infrastructure governs whether execution remains admissible at the act.
Decision Infrastructure and Relativity
Relativity surfaces and reviews evidence; Decision Infrastructure governs the consequential actions taken because of it at execution.
Decision Infrastructure and Reveal
Reveal surfaces evidence with AI-assisted review; Decision Infrastructure governs the consequential execution based on it.
Decision Infrastructure and Aderant
Aderant runs the business of law; Decision Infrastructure governs whether the consequential actions those operations drive are admissible at execution.
Decision Infrastructure and NetDocuments
NetDocuments manages legal documents and knowledge; Decision Infrastructure governs the consequential actions taken using that information.
Decision Infrastructure and Contract Lifecycle Management
Contract lifecycle platforms manage the contract; Decision Infrastructure governs whether actions taken under it remain admissible at execution.
Decision Infrastructure and Litera
Litera drafts, compares, and perfects legal documents; Decision Infrastructure governs whether the actions taken from those documents are admissible at execution.
Related Reading
Long-form explorations of the semantic substrate
Platform & Vision