OWL checks semantic errors that text can miss

The previous chapter separated two validation jobs: Pydantic checks the shape and types of an incoming tool call, while an ontology checks the meaning of the result. In this final technical example, the speaker uses OWL axioms to show what a meaning-level check can catch.

An output can be valid text and still describe an impossible or unacceptable situation. For example, a sentence about a refund may be grammatical, and a payout command may contain all the expected fields, but the action can still violate the domain model. OWL supplies formal constraints that a reasoner can evaluate instead of asking an LLM to enforce those constraints through free-form language alone.

Source note: The talk does not map every slide example to a fully named OWL property. The examples below preserve the kinds of constraints and errors that the speaker presents without inventing a more specific schema.

Three different kinds of constraint

The examples are easier to understand if their jobs are kept separate:

Constraint	What it controls	Example error it can expose
One-value or functional restriction	How many values a relationship may have	Issuing a second refund for the same order
Disjoint classes	Which categories an individual cannot belong to at the same time	Sending a buyer's payout to a support representative or support desk
Value restriction	Which values a property is allowed to take	Giving an order a status outside paid, shipped, or refunded

These are not three names for the same check. A one-value rule limits multiplicity. Disjointness limits category membership. A value restriction limits the vocabulary of a property.

1. Catching a second refund

The speaker first shows a functional-property example involving a refunded order. In this use, the model says that the relevant refund relationship for one order may have only one value. If the agent tries to issue a second refund for that same order, the new result conflicts with the constraint.

The important point is that the validator is not merely comparing two sentences for similar wording. It is reasoning about the identity of the order and the permitted number of refund values associated with it. Each refund message might look reasonable on its own. The contradiction appears only when both are considered in the same modeled domain.

Conceptual restatement of the slide example (not OWL syntax):

one order → at most one refund

Click to enlarge

The slide pairs a functional-property axiom for refunded orders with the error of issuing a second refund on the same order. This is the kind of rule that can sit beside the graph and give the agent loop a reason to reject or reconsider a proposed action.

2. Catching a role mismatch in a payout

The next example uses disjoint classes. Two classes are disjoint when the same modeled individual cannot be a member of both. Here, Customer and SupportRep are treated as separate categories.

That distinction matters when a payout is supposed to go to the buyer but is instead sent to a support desk. The payout may be formatted correctly. Its recipient may even be a real entity in the graph. The semantic problem is that the recipient has the wrong role: the rule expects a customer, while the proposed recipient is represented as a support representative.

Conceptual restatement of the slide example:

Customer and SupportRep are disjoint
the payout recipient must be a Customer
the proposed recipient is a SupportRep → flag the mismatch

Click to enlarge

The slide's second table row pairs disjoint Customer and SupportRep classes with the visible payout-to-support-desk error. The check is about a relationship between an action and a domain role, not about whether the recipient's name looks plausible.

3. Restricting order status to known values

The third example is a value restriction. The speaker's slide allows an order status to be one of three values: paid, shipped, or refunded. A probabilistic model might generate a different, made-up status that sounds natural in English. The restriction gives the validator a direct test: the value is either in the permitted set or it is not.

Conceptual restatement of the slide example:

status ∈ {paid, shipped, refunded}

This is a controlled vocabulary. It does not ask the validator to judge whether an unfamiliar phrase sounds convincing. It checks membership in the values that the domain model explicitly permits.

Click to enlarge

The slide's third row displays the allowed-value constraint and contrasts the permitted statuses with a made-up probabilistic value. It makes the difference between free-form wording and a formally limited field visible.

Why this is harder to enforce in plain text

English can express all three rules. Someone can write “do not refund an order twice,” “send the payout to the customer,” or “use only these three statuses.” The speaker's point is not that natural language cannot say these things. The difficulty is making unconstrained text generation reliably obey them.

An OWL axiom turns the intended relationship into a machine-checkable condition. The surrounding agent loop can then inspect a tool result or proposed state and decide whether it is consistent with the ontology. If it is not, the loop can reject it, send feedback to the LLM, or involve a human, as described earlier in the talk.

This does not make the LLM incapable of producing an error. It gives the system a formal place to detect certain errors after the model proposes them. The check is only as strong as the domain concepts and constraints that have been modeled. That last limitation is a general teaching consequence of the architecture, not a separate claim made by the speaker.

The architectural lesson

The chapter's examples complete the proposed division of labor:

1. The agent generates a response or a tool proposal using its probabilistic language model.
2. The tool runs and returns information or a possible state change.
3. The ontology reasoner checks meaning: multiplicity, roles, category separation, and allowed values.
4. The surrounding program routes the result: accept it when it is reasonable, or retry and escalate when it violates the modeled constraints.

Pydantic can help at the door by rejecting malformed parameters. OWL can help at the ledger by checking whether the resulting action fits the domain. Together, these checks surround the agent without replacing its flexibility. That is the speaker's concrete example of using formal ontology-based guardrails to keep a probabilistic system on track.