APEX Ontology — a working model of your business, built and run side by side with your team

APEX Ontology™

Your business has a shape.
But almost none of your software
knows what it is.

Your systems hold rows. A ticket table, a device list, a job sheet, an invoice ledger. None of them knows that this device sits at that site, under this contract, for a customer whose renewal is in six weeks. An ontology is where that gets written down — once, in one place, in your language — so people and software can both use it.

Map your first workflow with us → How it is built
objects properties links actions permissions drifts
SYSTEMS YOU ALREADY RUN tickets.csv device_list contracts finance_ar site_register ONE MODEL, YOUR LANGUAGE Customer Site Contract Device Job resolve links you would say out loud
// records resolve into objects; objects hold the relationships your team already talks about
The idea, in one page

Nouns, then verbs.

An ontology has two halves. The nouns are the things your business actually deals in — customers, sites, devices, jobs, contracts — and the relationships between them. The verbs are the small number of things people do to those things: raise it, approve it, schedule it, close it.

Most reporting projects stop at the nouns and produce another dashboard. The value shows up when the verbs are attached, because then the model is not just describing the business — it is where the work happens. That is also where it gets risky, which is why on our engagements every verb runs through a person.

We are not asking you to replace your systems. Your ERP, ticketing, finance and Microsoft 365 stay exactly where they are. The ontology sits above them and reads from them.

SYSTEMS OF RECORD — UNCHANGED ERP · ticketing · finance · M365 · device management OBJECTS AND LINKS — THE NOUNS Customer Site Device Job ACTIONS — THE VERBS, EACH APPROVED BY A PERSON raise job flag renewal retire asset …few reads writes back
// the model sits above your systems — it does not replace them
How it is built

Three layers. Built in that order,
because skipping one is how these fail.

Semantic, then kinetic, then the part almost nobody budgets for: keeping it true after the project ends.

Layer 01 · Semantic

The nouns of your business.

We sit with the people who do the work and write down what things actually are — not what a vendor's data model calls them. Then we map the systems you already run onto those objects, so a device row and a contract row become one connected picture.

  • objectA thing your business deals in: a customer, a site, a device, a job.
  • propertyA fact about it: serial, warranty end, renewal date, criticality.
  • linkA relationship you would say out loud: this device is installed at that site.

We start with one workflow, not your whole company. Six to ten object types is a realistic first pass for a mid-sized business, and it is enough to be useful.

OBJECT GRAPH CustomerNorthbridge Care Site × 4 Contract Device × 61 operates covered by installed at PROPERTIES · Customer sites4 devices61 contract ends14 Sep open jobs3 criticalityhigh
// one customer, four sites, 61 devices — renewal date attached to all
Layer 02 · Kinetic

A few verbs, each
with a person on it.

An action is a defined change: raise the job, flag the renewal, retire the asset. The model proposes it with its reasoning attached and the evidence it used. A named person approves or rejects, and only then does anything reach a system of record.

We deliberately keep the action list short. Three or four verbs that people actually run beats forty that nobody trusts, and a short list is something a mid-sized team can genuinely own.

  • actionA change to an object, with who may run it and what it writes to.
  • functionThe logic behind a suggestion — visible and reviewable, not a black box.
  • approvalA person, by name, in the record. Every time.
ACTION PATH SUGGESTED flag renewal contract ends in 42 days WHY — VISIBLE 3 open jobs · high crit. APPROVAL GATE a named person decides nothing writes without this approved ✓ rejected ✗ SYSTEM OF RECORD job raised in your ticketing rejected → logged, logic fixed feedback into the model
// assisted, not autonomous — the gate is the product
Layer 03 · Kept true

The layer that decides
whether any of this survives.

A model is accurate the week it is built. Then someone opens a site, swaps a supplier, renames a cost centre, and nobody updates it. Six months later it is quietly wrong and people stop trusting it — which is how most of these projects actually die.

So we run it as a service rather than handing it over and leaving. A named team, a monthly cadence, drift reported as a number, and changes to the model made as part of the change to the business, not months later.

  • cadenceA monthly working session with your people. Not a quarterly report.
  • driftWhat has changed against the model, counted and shown.
  • ownershipYour model, exportable, with the schema documented.
TWELVE MONTHS, TWO WAYS WITHOUT A SERVICE quietly wrong WITH APEX RUNNING IT review review review review stays accurate — someone owns it
// the difference is not the software — whether anyone is on it in month nine
Plain english

The six words you need,
and what each one costs you to skip.

Ontology vocabulary is borrowed from academia and it puts people off. Here is the whole of it, with an example from a business the size of yours.

Object

the thing itself

A single thing your business deals in, with an identity that survives being renamed in one system.

Example: a site — not four spellings of one address across finance, ticketing and the asset list.

Property

a fact about it

Something true of that object, held once so that two teams cannot disagree about it.

Example: a warranty end date that operations and finance both read from the same place.

Link

how things relate

Named relationship between two objects that a spreadsheet cannot hold — what makes the model worth building.

Example: this device is installed at that site under that contract.

Action

a defined change

A change to objects that a specific role may make, with a record of who made it and what it wrote to.

Example: raise a replacement job — approved by the service manager, written into your ticketing.

Permission

who sees and does what

Access resolved on the object, not bolted onto a report afterwards, so the model can hold sensitive data safely.

Example: a site manager sees their own sites; payroll properties are visible to two people.

Drift

the honest one

The gap between the model and reality. Every ontology has it. The question is whether it is measured or discovered during an incident.

Example: nine devices moved site last month and two were never recorded — reported, then corrected.
How we work

Side by side,
at your size.

The platforms that made ontologies famous were built for organisations with a data engineering department. If you have between fifty and a few thousand staff, that is not you, and a twelve-month transformation programme is not something you can absorb.

So we work the other way around. One workflow, one quarter, with our people sitting next to yours. Something in production at the end of it that a real person uses on a real Tuesday. Then the next one — funded by what the last one saved.

Your team learns it while we build it. That is the point: at the end you can run and extend the thing without us, and you keep the model either way.

  1. W1–2

    Pick the workflow that hurts

    Not the most interesting one. The one costing you hours every week — usually renewals, asset truth, or onboarding and offboarding.

  2. W3–5

    Model the nouns with your people

    Whiteboard sessions with the team that does the work. Six to ten object types, mapped to the systems you already run.

  3. W6–9

    Add two or three verbs

    The actions that workflow needs, each behind an approval, each writing back to the system of record you already trust.

  4. W10–12

    Run it in anger, then hand over the keys

    Your people use it for a month while we are still there. We document the schema, train your admin, and agree the monthly cadence.

  5. NEXT

    Second workflow, on the same model

    The second one is cheaper than the first, because the objects already exist. That compounding is the whole argument.

One motion, three stages

Where this sits.

Fabric decides what to build. DaaS puts it in people's hands and keeps it running. Ontology records what actually happened and hands that evidence back to Fabric.

Before — design

APEX Fabric™

Translate the constraint into an architecture, licence-review the models and benchmark on your own data before anything is committed.

During — deliver

APEX DaaS™

Devices and AI nodes delivered as a service — enrolled, secured, supported and refreshed on one predictable monthly figure.

After — and before again

APEX Ontology™

The running business keeps its own model current, turns drift into a reported number, and feeds real evidence into the next design.

Start small

Bring us the workflow
that wastes the most time.

One quarter, one workflow, your people in the room. If the first one does not pay for itself, there is no argument for the second.

Talk to Apex Experts →