Axioms Beat Sample Data: What OWL Support Means for AI Agents

Ask an AI agent to integrate with a system it has never seen, and watch what it does: it requests a few sample records and starts inferring. Three JSON documents in, it has decided that email is always present (it appeared in all three), that tags is a scalar (each sample happened to have one), and that status takes two values (it saw two). Every one of those conclusions is a guess dressed as knowledge, and every one can be wrong in ways that surface weeks later as a production incident.

The failure is not the agent's reasoning; it is the evidence. Samples show what data happens to look like. They cannot show what data is allowed to look like — which fields are required, which repeat, which values are permitted, how types relate. That is schema knowledge, and there is a language purpose-built to state it with no ambiguity at all: OWL.

What an ontology hands the agent

An OWL ontology exported from a CoreModels project is not documentation about the schema; it is the schema, stated as axioms a machine can consume directly. Every type is a class with its inheritance explicit in rdfs:subClassOf — the agent does not infer that an Article is a kind of Creative Work; it reads it. Every element is a property with a declared domain and range: which types own it, what it holds, whether it points at a scalar, another type, or a controlled vocabulary.

Most valuably, the constraints agents guess worst are the ones OWL states best. Required-ness and cardinality travel as restriction axioms on the owning class: a minimum-cardinality restriction means required, a maximum-cardinality restriction means single-valued, an upper bound on a collection is a stated bound. And the absence of restrictions is itself defined — in RDF's open-world semantics, an unrestricted property is optional and multi-valued, as a rule of the language rather than an inference from samples. The agent never has to decide whether a field is required. Either an axiom says so, or the default answers it. There is no third case.

Controlled vocabularies arrive as SKOS: complete term lists with preferred labels and explicit broader/narrower hierarchy. An agent classifying content against a taxonomy sees every permissible value and how they nest — not the two values that happened to appear in the samples.

Consultation, not excavation

The delivery mechanism matters as much as the content. Agents reach this over MCP: connect to https://coremodels.example.com/mcp (OAuth), and the governed model becomes something the agent consults rather than reverse-engineers.

The export_owl tool returns the project's schema as a Turtle ontology on demand. It carries one feature designed specifically for a machine reader: the lossiness ledger — everything the OWL rendering could not express about the underlying model — is prepended as comment lines at the top of the document. The agent gets the schema and the schema's honest limits in one artifact: these constructs are exact, these were approximated, this was left out. An agent that knows what its ground truth does not cover is a categorically safer agent than one holding a beautiful file with unmarked gaps.

The transform_schema tool goes further: it converts schemas between formats statelessly, with owl available on both sides. An agent holding a partner's Turtle vocabulary can turn it into JSON Schema to validate payloads against; an agent holding a SQL DDL file can render it as an ontology to compare with the governed one. Every call returns the produced schema, the executed plan as a replayable artifact, and the full lossiness ledger — so even the agent's own conversions are accountable.

Grounding by IRI, not by string

The subtlest agent failure is silent misalignment: the agent maps your Person to its notion of a person because the labels match, and the label was all it had. OWL removes the guesswork because every entity is an IRI, and the governed model's cross-standard mappings ride along as owl:equivalentClass and owl:equivalentProperty assertions, with taxonomy terms carrying skos:exactMatch links. When the ontology says your customer type is equivalent to the schema.org Person, the agent grounds on a public, unambiguous identifier — it aligns to what the entity is, not what it is called. String similarity stops being load-bearing.

This is grounding in the strict sense: the agent's internal representation anchored to identifiers the whole ecosystem shares, with the equivalences asserted by the model's governors rather than conjectured by the model reader.

Agents propose; the gate disposes

There is one more role for agents here, and it comes with a deliberate limit. Our mapping engine accepts AI-proposed plans — an agent, or our own server-side proposer, can suggest how one schema maps onto another. But an AI proposal earns no shortcut: it passes the exact validation gate every hand-written mapping passes, with at most one repair attempt, and a plan the gate rejects is rejected regardless of the confidence score attached to it. The gate never trusts self-reported confidence.

That symmetry is the design principle worth stating plainly. We are enthusiastic about agents as proposers, readers, and consumers of precise semantics — and unwilling to let any of them become an unaudited writer of meaning. Agents get better evidence than samples; they do not get more authority than humans.

The shape of the shift

Put together, OWL support changes what "an agent that knows your schema" means. Before: knowledge was inferred, probabilistic, and silently stale. After: the agent consults the governed model over MCP, reads axioms instead of guessing from instances, grounds entities on shared IRIs instead of matching strings, sees the complete vocabulary instead of the observed one, and receives an explicit ledger of what its ground truth omits. Guessed structure becomes stated semantics — with the limits stated too.

To wire an agent up, start with the MCP quickstart in the CoreModels docs, then have it call export_owl on a project you govern.