Orbis Ontology concepts

What the Ontology is

Your warehouse, your ticket system, your logs and your ERP each hold part of the truth. Orbis Atlas connects them; the Ontology describes what their records mean: which things exist, how they relate, what may be changed, and how all of it changed over time. It does this in place. Objects are live views over the systems that own the data, never second copies.

Objects and links

An object is one typed thing your operation cares about, with properties. A link is a typed relationship between two objects. Together they form the model a question can travel across.

A starting model for operations teams uses these object types: Station, Process, Incident, Ticket, Operator. Typical links read like plain English: a station runs a process, an incident affects a station, a ticket tracks an incident, and an incident is assigned to an operator. Your deployment adds the objects your business uses, such as orders, shipments or suppliers.

Actions

Actions are the only way the Ontology changes anything. Each action is typed and takes checked parameters, and every object it names must exist. Before it runs, a person approves it. It can only reach systems on your allow-list, and every run, approved or refused, is written to a hash-chained audit trail you can verify.

The ontology defines these actions: Open incident, Assign owner, Create ticket, Notify, Resolve incident.

Create ticket and Notify run today. The others are defined but not yet wired, and the Ontology refuses them rather than pretending they ran.

Time

The Ontology keeps an append-only history of every object and link. That means you can ask what the model looked like at a past moment, see exactly what changed between two moments, and trace any value back to the system it came from. History cannot be edited, so it can be trusted.

A question, end to end

Take the question: which critical incidents have no ticket yet, and who owns them? No single system can answer it. Alerting knows the incidents, the tracker knows the tickets, and the ownership map knows the owners.

1. The Ontology follows the links: incident to station, ticket to incident, incident to owner.
2. Orbis AI answers, citing the record behind every claim and the system it came from.
3. If the answer calls for a change, the Cognitive Kernel proposes an action, such as creating a ticket and assigning the owner.
4. A person approves it. The Executor writes it to the tracker and records it in the audit trail.
5. Ask again, and the incident no longer appears: the model reflects the change.

Using the Ontology in the app

Open Ontology from the left rail. It has six views.

• Overview. The home dashboard: how many objects and links the model holds, which critical incidents need a decision, the latest actions, how many ran or were refused, whether the audit verifies, and every capability on the platform with its real status. Anything live opens the screen behind it.
• Explorer. Search every object or filter by type. Open one to see its properties, the system it was read from, what it links to, and what changed. Follow a link to the object at the other end, and act on the object from the same panel.
• Schema. Every object type with its properties and how many exist, how the types link, and the actions allowed on them with the governance each carries.
• Questions. See the incidents that no ticket tracks yet, with where each happened and who owns it, and propose a ticket from any of them.
• Actions. Propose an action, then review it before it runs. The review is a dry run by the executor itself: it shows the change the action will make and every check it must pass, from its inputs to whether the destination is on your allow-list, while nothing has run yet. If a check would fail, the action cannot be run until you change it. Approve and run it, and you see the result.
• Audit. Every attempt, newest first, with who made it, the outcome, and whether the chain of records still verifies.

When a deployment is showing fictional demo data instead of your systems, the Ontology says so at the top of every view.

What is available today

Every capability is marked with its real status. Capabilities marked mapped at deployment are set up for your systems by our team as part of your deployment.