Point of view
Agents can only work in production if they understand the business. Ontology is how we teach them.
Experience you can lean on
Immersed in technology and across many different verticals, so the people on your project have done this before.
The argument
01
Ontology is the branch of philosophy that studies being. It asks what exists, what kinds of things there are, and how those things are related. The word comes from Greek roots meaning “being” and “study”. Philosophers have argued about it for more than two thousand years.
Notice what the discipline does. It does not collect facts about particular things. It sorts reality into categories, and then asks how the categories behave. Is a person the same as the roles they play? Is a company a thing, or a set of agreements? Is a late delivery a thing, or something that happens to one? These questions sound abstract until you try to build a system that must answer them.
Every database encodes answers to these questions, usually without saying so. A “customer” table decides what a customer is. A status column decides what states a thing can be in. The choice is made one project at a time, and the choices disagree. An enterprise ontology makes the choice once, on purpose, and writes it down.
02
Individual things and kinds
A particular is one individual thing, such as this loan or this clinic. A universal is a kind that many particulars share, such as “loan” or “clinic”. In an enterprise model, particulars are instances (the loan with this identifier) and universals are object types (Loan). Keeping them apart lets you define a type once and create many instances.
What has a place and what does not
Concrete things can be located in space and time: a truck, a field, a patient. Abstract things cannot: a policy, a credit limit, a tariff. A good model holds both. A truck is an asset with a location. A tariff is a rule that applies to it. Mixing them without care produces confusion in reports.
Things that persist
A substance is something that exists in its own right and persists through change. A customer remains the same customer when their address changes. In the enterprise these are the core object types: Customer, Account, Asset, Facility. Identity is the hard part. Deciding when two records are the same customer is most of the work.
How things are
Properties are the qualities a thing has: a balance, a weight, a risk rating, a status. They belong to something and can change. In the ontology they are typed attributes with units, allowed values and rules. A balance is not just a number. It has a currency, a time and a source.
How things connect
Relations hold between things: owns, supplies, reports to, is guarantor of. They are not afterthoughts. Most business questions are about relations, such as which clients depend on a supplier. In the ontology these are links with a direction, a meaning and sometimes their own properties.
How things stand
A state of affairs is a way things are arranged at a moment: this account is overdrawn, that shipment is held at customs. It is what a dashboard reports. In the ontology it is the current set of property values and links, with the history of how they got there.
What happens
An event is something that occurs and changes a state of affairs: a payment received, a sensor alarm, an approval. Events have times and participants. Modelling events well gives you audit, replay and the ability to ask what changed and why. Actions in Zeus are the governed way to cause events.
03
Computing borrowed the word. In knowledge representation, an ontology is an explicit specification of the concepts in a domain and the relationships between them. Engineers have used the idea in many forms: data dictionaries, entity-relationship diagrams, knowledge graphs, semantic layers.
We use the word in the plain enterprise sense. What are the things in this business? How do they relate? What can be done with them, and by whom? Customers, accounts, shipments, machines, patients and contracts are not rows. They are objects with meaning and with rules about how they behave.
The difference between a diagram on a wall and an ontology in production is that the second one is executable. It is stored, versioned and enforced. Applications read from it. Agents act through it. Changes go through review. That is what makes it a layer and not a document.
04
| Agent on a raw database | Agent on an ontology |
|---|---|
| The agent guesses which table is the source of truth. | Each object type has one defined source, with lineage. |
| It cannot tell what a late shipment implies. | Rules state what a delay means and what should follow. |
| Permissions are all-or-nothing database credentials. | Access follows objects, purposes and the requesting person. |
| Actions are free-form API calls. | Actions are named, governed operations with approvals. |
| After the fact, nobody can say why it acted. | Every action leaves a record of inputs, rule and approver. |
05
The entities of the business with their properties and states. Example: a Loan with amount, tenor and status. Example: a Cooperative member with plot size and crop.
How objects connect: ownership, dependency, sequence, hierarchy. Example: a Loan belongs to an Applicant and is secured by an Asset. Example: a Delivery goes from a farm to a buyer.
Rules and constraints that say how the business works. Example: a loan above a limit needs two approvals. Example: produce must be graded before a payment is released.
Governed operations that people and agents can perform, with full traceability. Example: request documents. Example: release payment, with an approver and a record.
06
A bank models Applicant, Application, Account, Document and Branch. An Application has a status, a submitted date and a requested amount. It is linked to one Applicant and many Documents.
Application #A-1042 (illustrative)
The bank states a rule: an application that has waited longer than its service level without a decision is “late”. The service level differs by product and branch, and the rule says which applies.
Late if waiting beyond product service level
An action named “Request missing documents” is defined. It can be performed by a loan officer or by an agent acting for one. It sends a message through the customer’s preferred channel and logs the request.
Action: Request documents
An agent sees the late application, checks which documents are missing, and proposes the action. The officer reviews, edits and approves. The decision, the rule and the approver are recorded.
Human approves, record kept
Free 30 minutes with an engineer.
07
The first mistake is treating the ontology as a diagram. A picture that no system reads goes stale within a quarter. The model must be stored and used by applications, or it is documentation.
The second is trying to model everything. Start with one decision. Model only the objects, links and actions it needs. Extend as the next use case demands.
The third is leaving it to one team. The people who know what a “late” application means are in operations, not IT. The ontology works when process owners help define it and review changes.
08
It holds the objects, relationships, rules and actions, with versioning and review, and exposes them to analysis, workflows and agents.
The other products refer to Zeus objects by identifier. Odin decides who may touch an object. Monolith limits what an agent may load and remember about it. Argus runs the workflows and stores the data. Cyclopes records what happened to it. Nobody keeps a private copy of “customer”.
09The ontology layer, built
Select any layer, or press play to watch the platform come together from your data up to the agents that use it. The figure is a general pattern; each layer shows which Boltcliq product builds it.
A shared model of the business: its objects, the links between them, the rules that say how it works, and the actions people and agents may take. It is stored, versioned and enforced, not drawn on a wall.
How we build it
Zeus holds one ontology that people and agents work from. We start with one decision, model only the objects, links and actions it needs, and extend as the next use case demands. Process owners define and review changes.
10
This is the shape of an ontology: a hub of core objects with typed entities and links. Edges carry meaning, and the model is the thing every other system reads.
We use real sector starting points to avoid a blank page. Banking, health, agriculture, public sector and logistics each have a template you adapt rather than invent.
11
An ontology is not finished. The business changes, and the model must change with it. That needs ownership. We recommend a small group of modelers, with named owners for each object type and a review step for changes.
Changes move through environments like code: draft, review, test, promote. Agents and applications read the promoted version. When a rule changes, you can see which workflows and agents depend on it before you ship.
12
Our team of consultants and experts brings a combined 35 years of industry experience.
Immersed in technology and across many different verticals, so the people on your project have done this before.
Ontology
Tell us the problem. An engineer, not a salesperson, answers.
Agents can only work in production if they understand the business. Ontology is how we teach them.
