Controlling your AI starts with the ontology.
A model trained on the internet knows language. It does not know that a “case” in your business means a pallet, that account 4021 is never short-shipped, or that your Ohio supplier’s August lead times are optimistic and everyone plans around it. The ontology is where all of that gets written down. It is what makes an agent reason like your company instead of like a general-purpose model.
Nouns, verbs, and the rules that govern both.
An ontology is a working model of how your operation is put together. It has three parts, and an agent needs all three before it can produce a recommendation anyone would approve.
What exists in your business
SKUs, lots, plants, lines, orders, promises, suppliers, BOM levels, channels — with your definitions, not generic ones. Three ERPs can each hold something called a customer and mean three different things. The ontology settles which one is the customer.
What may actually be done
Resequence a build. Reallocate a short lot. Re-promise an order. Release a purchase order early. Each one is a real action with real consequences, defined as something an agent can propose and a person can approve, edit or reject.
When, by whom, within what limits
Which verbs apply to which nouns, under which constraints, requiring whose approval. Allocation policy, lead-time guardrails, SLA commitments, escalation thresholds, and the actions an agent may never take regardless of how confident it is.
Nouns alone give you a data model. Nouns and verbs give you a workflow. Only when the rules are attached does a recommendation arrive with the constraint that applied and the alternatives that were ruled out — which is the difference between an answer and a decision someone can defend to a customer.
One work order. 214 BOM lines. One of them says no.
A work order for 300 units releases Friday against a customer promise the following week. Two hundred and twelve lines are covered; of the two that are short, one clears on its own. The binding line — a capacitor — is short 1,160 after a purchase order slipped nine days, and a $438,000 shipment is at risk. Equivalent stock exists — enough of it — but it sits under another customer’s part number, on another program.
Recommending that transfer is not a data question. It is an ontology question, and here is everything that had to be joined before an agent could propose it.
Worked example — the customers, SKUs and penalties are synthetic; the mechanics are the product’s.
Two part numbers, one part
Approved on both AVLs
What is actually yours to move
Real movement, not assumed FIFO
Who else is counting on it
What it may never propose
Today that join is a five-to-six-step hunt across the ERP, the warehouse system, quality and the customer master, done by whoever knows where to look. In the ontology it is one governed read — and the resulting recommendation carries the evidence of why the transfer is safe, which is what makes it approvable and auditable.
Open the full worked decision More decision examples What the decision package contains
Agents raise the price of ambiguity.
A planner absorbs ambiguity without noticing. The Tuesday number is the reliable one. The Mexico plant reports a week behind. None of it is written down anywhere.
An agent without your ontology has no such instinct. It reasons confidently from whichever definition it found first, and a wrong answer looks exactly as well-formed as a right one.
Ontology-first platforms are usually developer platforms where your team models the enterprise before anything produces a number. A2go arrives with a supply chain ontology already modeled — the entities, events and metrics that recur across forecasting, planning, inventory and order promising, because they recur across manufacturers and distributors. What is specific to you is your rules, your priorities and your guardrails. Ontology makes your systems operate by them.
Your first domain is live in 8–12 weeks rather than after a modeling program, because the general structure is already there and only your part of it has to be written. Every decision added after that extends the same model instead of starting a new one.
We start from decisions, not from your schema.
Modeling an entire enterprise before anything works is how two-year programs happen. A2go works backward from the decisions that cost you money and models only what those decisions need: the rules that govern them, the entities they touch, and the fields they actually draw on.
Your business rules are held in the ontology, not hard-coded separately inside every agent. Change an allocation policy once and every agent that touches allocation obeys the new version on the next cycle. Rules written into individual agents drift apart the moment the business changes, and nobody finds out until two agents recommend opposite things.
The ontology holds what you can state. The Judgment Layer catches the rest.
Allocation policy, lead-time guardrails and escalation thresholds can be written down in a workshop, and they go into the ontology during deployment. The overrides, rejections and edits your planners make afterward cannot be, and those accumulate into decision memory specific to your company. Both stay in your tenant. Neither is shared across customers.
The ontology governs. The agents reason.
The model of your business
- Entities, relationships and events
- Business rules, policies and constraints
- Which data each decision may draw on
- Roles, permissions and approval thresholds
- Explainability and the audit trail
- Coordination across agents
The reasoning for one decision
- Reason across the data that decision requires
- Cost the alternatives against real constraints
- Run scenarios and comparisons
- Assemble the recommendation and its rationale
- Carry the approved action back to your systems
Bring one decision and we will model it with you.
Thirty minutes on a single decision in your operation: the entities it touches, the rules that already govern it, and what an agent would need to know before it could recommend anything you would sign.