![\"The](\"https://matt.thompson.gr/uploads/2026/world-instances.svg\")
This is an addition to the original term sheet. The core terminology is unchanged; the Agent Design Process has gained an Ontology / Vocabulary layer — a living document you revisit without end, not a numbered step in a sequence.
\nI’ve come around to ontology. It speaks to me, my interest in meaning goes back to reading the Thesaurus as a kid, grammar didn’t interest me as much though, meaning is fascinating, probably the birth of Context Is All you Need :)
\nI arrived at this point whilst building an agent that navigates through a maze of infrastructure. The agent creates a typical graph of nodes and edges: the nodes are labelled by domains, types, and legal actions, and the edges are labelled to express the relation between the nodes.
\nThis led to this comment in my session with Claude (spelling mistake is kept for honesty!):
\n\n\n“I am thinking that this could be a use case for one type of system however I am now thinking we need an ontological for the nodes and edges defined clearly. it would not be a generic discovery agent, rather an Infra Discovery Agent and use an ontology documented in the atomicguard repo: docs/design/notes/topology_sensing_dsa_belief_state_and_agent_function.md’s ‘Node and Edge ontology’ section… take a step back and consider what an environment for that would look like.”
\n
The conversation has progressed to the point where I wanted to understand what an ontology really is and why it is making sense, central to my work, and where in my approach and workflow should I be defining it.
\nOntology definition from Wikipedia:
\n\n\nOntology is the philosophical study of being.
\n
This was a big blocker to why I thought it wasn’t relevant, I do not buy into AI being conscious so this triggered me.
\nThis is getting more useful as a definition - Formal Ontology from Wikipedia:
\n\n\nIn philosophy, the term formal ontology is used to refer to an ontology defined by axioms in a formal language with the goal to provide an unbiased (domain- and application-independent) view on reality, which can help the modeler of domain- or application-specific ontologies to avoid possibly erroneous ontological assumptions encountered in modeling large-scale ontologies.
\n
It’s a graph of objects with specific relations. Voilà.
\nIn connecting the dots I like to refer to frameworks that help me understand the world I work in. These are frameworks I’ve actively applied, which I’ve found to be common sense and to make situations flow.
\nIn looking at ontology in greater detail, I see that these frameworks themselves have inherent ontologies that define the world and provide approaches to navigate the situation. For a given context I find them excellent for their simplicity and clarity.
\nThis quote from the DDD wiki page is key for any software engineering (formal or otherwise):
\n\n\nUbiquitous language is one of the pillars of DDD together with strategic design and tactical design.
\n
The way to look at it is that ontology is a symbolic structure that defines the terrain. Doctrine and frameworks offer an imperfect way to navigate that terrain.
\n\n\nIf ontology is the map, doctrine is your strategy.
\n
Here is how they stack together in system design:
\nIn formal systems or orchestration layers, your ontology is the foundational state space and schema (like the definitions in a belief store). Your doctrine provides the deterministic constraints and logic applied to that state.
\nPEAS? Its a framework and vocabulary that helps define how an intelligent agent perceives and interacts with a given world.
\nThis post is the synthesis of the two grammars in this series: the ontology’s predicates are written in the grammar of logic (Series 11), and its ubiquitous language is the grammar of natural language (Series 12) vocabulary the design documents share.
\nA fact, in the philosophically accepted sense, is a justified true belief — the analysis of knowledge that runs from Plato’s Theaetetus forward: a proposition you hold, that is true, and that you are justified in holding. Everything the world ontology names is exactly that: a belief the agent holds about the world. And Kind is the justification — what entitles the agent to hold it.
\n| Kind | \nJustified by | \n
|---|---|
| exogenous | \nsensing the world — a belief about the state at the moment of sensing | \n
| controllable | \nthe agent’s own action — it made the fact so | \n
| static | \nsetup — granted once, fixed for the task | \n
| derived | \ninference — entailed by other justified beliefs | \n
These four kinds are not new coinage — each is an established concept:
\nWhat this project contributes is the sharper synchronous-entailment test — does the effector’s successful return entail the fact? — which draws the controllable/exogenous boundary without ambiguity, and the decision to tag every predicate with an explicit kind.
\nMultiple Kind tables are not redundancy — each reads the same coin through a different lens. The facts section reads Kind as justification: what entitles the agent to hold the belief. The ubiquitous language reads it as determination: what sets the fact’s truth, judged by the synchronous-entailment test. The belief state reads it as belief: what the agent actually holds, which may be false. That is the honest epistemic position — a fact is a justified true belief, but the agent never directly knows the true: it can only hold justifiably held beliefs. The most it can claim is that a fact was true at the point in time it was sensed, or the action was taken.
\nTwo consequences worth holding onto:
\n"FINAL:" marker is a belief justified by the very system being measured — an “irrational performance measure” — not by the world.In formal systems or orchestration layers, an ontology is the state space and schema (like a graph of infra) that an agent navigates. As I’ve been learning about PEAS I didn’t think the vocabulary for the environment was important past defining a ubiquitous language. I saw it as a maze to be solved but hadn’t looked at the composition of that maze.
\nSo defining your environment is a practice that begins before PEAS — a first pass, then a living document, re-entered whenever a later step exposes a gap. As with DDD, the model — and its use — benefits from being considered flexible, both in terms of correcting mistakes made earlier in the process and adapting to new information.
\nTwo artefacts, because they fail differently:
\n| Artefact | \nWhat it holds | \nIts failure mode | \n
|---|---|---|
| Schema | \nThe types and predicates of the domain, each classified by its Kind — controllable, exogenous, static, or derived (the definitions live in the ubiquitous language) | \n“I’m missing a predicate” — the structure can’t express something the design needs | \n
| Ubiquitous language | \nThe shared naming and vocabulary for those types and predicates, agreed so every design document means the same thing by the same word | \n“Two docs use the same word for different things” — the naming drifts and the design reads inconsistently | \n
Scope it honestly: this is the world ontology — the environment the agent navigates and acts in: its entities, predicates, actions, and connections. It is not the agent ontology, which uses the PEAS framework to define the agent loop itself (percept, agent function). Confusing the two is the crux of the mistake I have made, and clarifying the delineation between them is the point of these posts.
\nWhen the ontology is re-entered: it is a normal, expected loop-back, not a process violation. The clearest signals are in Step 2 (the environment’s properties don’t fit what the ontology declared) and Step 3 (a persistent-state variable has no home in the schema). For me, it surfaced mid-build — “I need an ontology” — as I was drawing the graph of nodes and edges.
\nThe infra discovery agent walks an unknown pipeline graph — commit → lint, unit-tests → integration-tests → merge-gate → deploy — building belief one sensed node at a time. It builds on the two threads that came before: the search algorithms that solve a maze, and the dual-state agent that separates the workflow state from the environment — where the LLM lives — and the world, where actions are taken and facts are sensed via effectors. I have been framing infrastructure as a maze where the agent is tasked with finding the exit, so I created a graph for the agent to walk. The fun part is that the graph’s details are unknown until the agent walks it. The world holds the whole topology but withholds it: the agent can only query a node it has already reached. Here the world is the point, and the ontology earns its keep.
The world, as instances:
\n
Entities:
\n| Type | \nMeaning | \n
|---|---|
Node | \na stage in the estate — commit, lint, unit-tests, merge-gate, deploy | \n
Edge | \na connection between nodes, in one of two directions | \n
Domain | \nthe system a topology lives in | \n
Status | \na node’s condition from the agent’s point of view — known, visited, cleared, blocked | \n
Predicates, classified by Kind:
\n| Predicate | \nKind | \nWhy | \n
|---|---|---|
node(id) | \nexogenous | \nsensed — the node exists in the estate | \n
notifies(id, target) | \nexogenous | \nsensed per node — the push edge, who this node tells | \n
requires(id, target) | \nexogenous | \nsensed per node — the pull edge, what this node needs | \n
known(id) | \ncontrollable | \nthe agent’s belief — it has heard of this id | \n
visited(id) | \ncontrollable | \nthe agent’s belief — it has been there | \n
cleared(id) | \ncontrollable | \nthe agent’s belief — the node’s requirements are met | \n
reachable(from, to) | \nderived | \na path over already-sensed edges | \n
is-leaf(id) | \nderived | \nno notifies — a structural goal or dead end | \n
Actions: SENSE(node), WALK(edge), BACKTRACK, RECORD(belief), REPORT(descriptor).
Predicates are the facts of the state — what can be asserted about the world, each classified by Kind. Actions are the operations that change the state, and an action is defined over predicates: its precondition is a set of predicates that must hold, and its effect is a set of predicates it makes or unmakes true. SENSE and RECORD above are actions; node, notifies, and known are the predicates they read and write.
Connections: notifies and requires edges link nodes; the agent’s belief is the discovered subgraph.
The belief state — the point of this example. The world ontology is what gives the agent something to hold belief about: the minimal loop’s world was the conversation, and there was nothing to model. Here the agent’s belief is a real model of the world, built incrementally — known (heard of), visited (been there), cleared (requirements met) grow one sense at a time as the agent walks. This is the schema’s controllable side doing real work.
The world ontology, as a graph:
\n![\"The](\"https://matt.thompson.gr/uploads/2026/world-ontology.svg\")
The formal ontologies — schema.org, RDF(S), and OWL:
\nThe world ontology above is informal — entities, predicates, actions, and connections, with a Kind for each fact. When the ontology must be shared, queried, or reasoned over by tools, it gets written in a formal ontology language. Three stand out:
\nsubject predicate object statement. The post’s predicates map straight onto it — notifies(lint, merge-gate) is the triple lint notifies merge-gate. RDFS layers class and property hierarchies on top (subClassOf, subPropertyOf).derived predicates meet the Grammar of Logic’s entailment (⊨) — OWL axioms are the rules, and the reasoner computes reachable and is-leaf exactly as the logic sheet’s Determination describes. What OWL does not express is Kind: nothing in RDF(S)/OWL says whether a fact is exogenous, controllable, static, or derived. That determination axis is this post’s addition — the one the formal standards leave to you.The schema.org decision — serialisation, not semantics:
\nIn the project this has been applied to, I made the decision to use schema.org — and only as serialisation, so the project adheres to a common understanding. That rests on a distinction worth naming:
\n| \n | Serialisation | \nSemantics | \n
|---|---|---|
| Answers | \nhow is the fact written down? | \nwhat does the fact mean? | \n
| Concern | \nform — storage, sharing, auditing, interop | \nmeaning — truth, entailment, legality | \n
| A serialised fact is… | \ninert: structure but no truth yet | \ntrue or false only once interpreted | \n
| schema.org gives | \n✓ vocabulary + shape (JSON-LD) | \n✗ — no preconditions, effects, derived facts, reasoner | \n
| In this project | \nthe JSON-LD audit record | \nthe planning layer, where the facts are determined and entailed | \n
| This post’s terms | \nthe serialised record | \nKind, and the Grammar of Logic’s Determination (no truth without a model) | \n
Serialisation is the form a fact takes to be shared; semantics is what determines its truth. schema.org buys a common shape — two systems agree on the record’s form because they share its vocabulary — but not common meaning: agreement on what follows, what is legal, what is true. That is why the decision uses schema.org only as the audit view, keeping the authority in the semantics layer.
\nThe world ontology’s facts serialize onto schema.org Action types and properties: actionStatus (the lifecycle + guard verdict), agent (the acting entity), object (the entity acted on), result (the verdict), instrument (the effector), target (the grounded task), error (the failure cause).
This is also where the ubiquitous language artefact does real work: schema.org has no Agent, SensedFact, WorldState, or passed/predicate/args/value, so the custom terms are scoped to a dev: namespace in the JSON-LD context. That is the ontology’s UL in action — the terms that don’t exist in the shared vocabulary are namespaced into your own, so they never collide with schema.org’s.
Which leaves the post’s point standing: the Kind axis is exactly what schema.org cannot express. reachable and is-leaf are derived facts with no serialization home — their determination must live in the semantics layer, not the audit view. Using schema.org only is a decision about which layer carries what, not a claim that the ontology is shallow.
The world ontology, as JSON-LD — the audit record:
\n{\n "@context": {\n "@vocab": "https://schema.org/",\n "dev": "https://dev.example.org/",\n "Agent": { "@id": "dev:Agent", "@subClassOf": "https://schema.org/Organization" },\n "Node": "dev:Node",\n "SensedFact": "dev:SensedFact",\n "notifies": "dev:notifies",\n "requires": "dev:requires"\n },\n "@type": "Action",\n "actionStatus": "CompletedActionStatus",\n "agent": { "@type": "Agent", "@id": "dev:discovery-agent" },\n "object": { "@type": "Node", "@id": "dev:merge-gate" },\n "result": {\n "@type": "SensedFact",\n "notifies": "dev:deploy",\n "requires": "dev:lint, dev:integration-tests"\n }\n}\nThe serialization carries the facts — there is no Kind field. How each fact is determined stays in the semantics layer, exactly as the serialisation/semantics split above sets out.
\nThe world ontology names facts; the agent stores them as beliefs. A fact is what is the case in the world; a belief is the agent’s stored, justified representation of it. Storing a fact as a belief is the loop’s core move — SENSE → RECORD: the agent senses the world’s exogenous predicates (node, notifies, requires) and records them into its own controllable predicates (known, visited, cleared).
This is where Kind does its real work, tying back to the facts section: the exogenous facts are justified by the world at the moment they are sensed; the belief is justified by the agent’s own actions of sensing and recording. The sequence below shows a fact entering belief, and the belief evolving as the agent acts.
\nThe belief state — schema (JSON-LD context):
\n{\n "@context": {\n "@vocab": "https://schema.org/",\n "dev": "https://dev.example.org/",\n "BeliefState": "dev:BeliefState",\n "known": "dev:known",\n "visited": "dev:visited",\n "cleared": "dev:cleared",\n "blocked": "dev:blocked"\n },\n "@type": "BeliefState"\n}\nThe schema defines the belief state as a JSON-LD object: the BeliefState type with four properties — known, visited, cleared, blocked.
Building belief, as a sequence:
\n![\"Building](\"https://matt.thompson.gr/uploads/2026/building-belief.svg\")
An example belief state, from a run:
\nThe walk commit → lint → merge-gate → deploy leaves this belief state:
{\n "@context": {\n "@vocab": "https://schema.org/",\n "dev": "https://dev.example.org/",\n "BeliefState": "dev:BeliefState",\n "known": "dev:known",\n "visited": "dev:visited",\n "cleared": "dev:cleared",\n "blocked": "dev:blocked"\n },\n "@type": "BeliefState",\n "known": ["dev:commit", "dev:lint", "dev:unit-tests", "dev:merge-gate", "dev:deploy"],\n "visited": ["dev:commit", "dev:lint", "dev:merge-gate", "dev:deploy"],\n "cleared": ["dev:commit", "dev:lint", "dev:merge-gate", "dev:deploy"],\n "blocked": []\n}\nunit-tests is known — learned from commit’s notifies — but unvisited, because the walk took the lint branch; integration-tests was never sensed.
A stored belief is not a guaranteed fact — it is justified by the agent’s actions, not guaranteed by the world. A belief can be well-stored and false, exactly as the facts section’s “justification is not truth” set out.
\nThe shared vocabulary, agreed once so the schema above is checkable:
\nKind definitions — a Kind says what determines a predicate’s truth (the determination defined in the Grammar of Logic term sheet):
\n| Kind | \nDefinition | \nExample here | \n
|---|---|---|
| controllable | \nthe effector’s successful return entails the fact — determined by the agent’s own action | \nknown, visited, cleared | \n
| exogenous | \nthe effector’s successful return does not entail it — the world can change the fact after the action returns, so the fact is only a belief about the current state | \nnode, notifies, requires | \n
| static | \ntrue at setup, never changed by any action or sensing | \ndomain | \n
| derived | \ncomputed by the state model, never asserted — entailed from other predicates | \nreachable, is-leaf | \n
Term definitions — one agreed meaning each:
\n| Term | \nAgreed meaning | \n
|---|---|
notifies | \nthe push edge — who this node tells when it finishes | \n
requires | \nthe pull edge — what this node needs before it can clear | \n
known | \nthe agent has heard of this id | \n
visited | \nthe agent has been there | \n
cleared | \nthe node’s requirements are met | \n
leaf | \na node with no notifies — structurally the goal or a dead end | \n
Even the minimal loop needs an ontology — a schema and a ubiquitous language are still required, and doing them from the start is right. But its world is the conversation: two exogenous facts (received(prompt), received(response)), one accumulated state (context), and nothing to have belief about. Almost everything degenerates to exogenous, and there is no belief state. That is what this example fixes: the infra agent’s ontology is the scaffold for a belief the minimal loop cannot hold. (The minimal loop’s full walk-through is preserved as a draft for further work on the agent loop — drafts/minimal-llm-loop.md.)
The vocabulary was right from the start — nothing here needs re-entering yet. This work enables learning whilst doing and has the heady intent of “doing it properly” via the link to formalisation. It doesn’t have to be perfect; being on the road to formalisation is enough.
\nThe world ontology’s predicates are atomic sentences of the grammar of logic (Series 11). A single fact, shown three ways:
\nnotifies(lint, merge-gate)
as an RDF triple:
\n<https://dev.example.org/lint> dev:notifies <https://dev.example.org/merge-gate>\nand the same fact as compact JSON-LD:
\n{\n "@context": {\n "@vocab": "https://schema.org/",\n "dev": "https://dev.example.org/",\n "notifies": "dev:notifies"\n },\n "@id": "dev:lint",\n "notifies": "dev:merge-gate"\n}\nThe predicate, the triple, and the JSON-LD are the same statement — the grammar determines the shape, the serialization chooses the form.
\nThe lifecycle of a single node’s belief — from unknown, through known and visited, to cleared or blocked:
\n![\"The](\"https://matt.thompson.gr/uploads/2026/belief-lifecycle.svg\")