Ontology first: intelligence that acts, not dashboards that report.

The dashboard trap

A typical enterprise data programme moves data from the ERP, the CRM and a dozen operational systems into a warehouse, cleans it, and publishes dashboards. It is real work and it is necessary. It is also where most programmes stop, because the next step, connecting what the dashboard shows to what somebody should do about it, has no owner and no architecture.

The result is intelligence that reports. A churn score sits in a table. A predicted failure sits in a chart. Somebody, eventually, opens a ticket.

What an ontology is

An ontology, in this context, is a model of the business as its operators understand it: the objects that matter (a customer, an account, an asset, a work order, a flight), their properties, the links between them, and the actions each one allows (approve, dispatch, escalate, hold). It sits between the data foundation and the applications, and everything above it is built in those terms rather than in tables and columns.

The approach was popularised in enterprise software by Palantir, whose platforms put an ontology at the centre of the data architecture. The principle travels well beyond any one vendor. Once the business is described as objects and actions, an analyst, a dashboard and an AI agent can all work on the same thing, and an action proposed by a model is an action on an object a person already recognises.

How we build it

1. Sources. ERP, CRM, core systems, sensors, documents and third-party APIs, catalogued in the Solution Architecture phase.
2. Data foundation. A governed warehouse or lakehouse with master data, access control, lineage and an audit trail. This is where most programmes stop.
3. Ontology. Objects, properties, links and actions, defined with the operators who will use them and versioned like code.
4. Applications. Operational dashboards, forecasting, optimisation and AI agents, each consuming the ontology rather than raw tables.
5. Approval gates. Every consequential action an agent proposes carries a defined approval path. Autonomy is earned per action type, not granted by default.

Start with three use cases

An ontology that tries to describe the whole enterprise on day one never ships. We start with three use cases that share objects, for example in a bank: collections prioritisation, credit line review and fraud escalation, all of which need a customer, an account and an exposure. The first ontology covers those objects and their actions. Each further use case extends it.

Where it earns its keep

• Oil, gas and energy: asset, sensor, work order and crew objects, so predictive maintenance schedules a crew rather than colouring a chart red.
• Banking: customer, account and exposure objects, so credit and collections decisions carry an audit trail the regulator can read.
• Airlines: flight, passenger, crew and asset objects, so disruption recovery proposes rebookings and crew changes together.
• Telecommunications: subscriber, plan, cell and ticket objects, so retention offers and proactive care are triggered by the same model.

Who builds it

A Solution Architect owns the ontology. Data Engineers own the foundation. AI / ML Engineers own the models and agents. All three sit inside Technology Leadership Services, with the client's in-house team trained to operate and extend the platform after go-live. Intelligence that acts needs a team that stays.