01
The middle plane
Consider an object-based interface: an agent reads an Order and invokes a permitted scheduling action, while the application resolves the underlying records. This is an illustrative design pattern, not a description of every deployment.
The plane in the middle is the interface in the strict sense: it is the contract between what the organization knows and what the organization can do. Everything above it inherits its vocabulary, and everything below it disappears behind that vocabulary.
02
Schema is governance
Deciding what counts as an object, which properties it carries, which relations are real, and who may invoke which action — these look like data-modeling choices and are actually governance choices. When access control and audit ride on the object layer, permissions become semantics: the question "what can this agent see and touch?" is answered by the ontology, not by a scattered pile of grants.
This is why the layer is political inside any organization that builds it. The schema encodes whose view of the business wins. An ontology is an org chart for meaning.
03
Why agents force the issue
Language models made unstructured interfaces cheap: point one at raw tables and it will produce plausible answers. But plausible readings of raw data are precisely the unadjudicated-belief failure this notebook keeps circling — and an agent acting from them acts without a consequence boundary.
Typed objects and named actions can make permissions and audit easier to define. They do not enforce themselves: the implementation still has to validate access, preserve records, and handle mistakes in the schema.
04
The small version
In my systems, I’m working toward a typed object layer between ingestion and action, with provenance and explicit permissions. The question is whether those boundaries remain useful as the research and software change.
You do not need a platform to have an ontology. You need the discipline. The open question I am still testing is whether ontology-first survives contact with fast-moving research code, or whether the schema ossifies faster than the work changes shape.