# From Tables to Decisions: The Case for an Operational Ontology

**Project 82 white paper series — No. 3**

## Executive summary

Your organisation does not run on tables. It runs on things: people, vessels, sites, transactions, sensors, consignments. Yet almost every data platform you have bought presents the world as rows and columns, and every question your teams ask must first be translated — badly, and by hand — from the language of operations into the language of schemas.

This paper argues that the missing layer is an **operational ontology**: a governed, versioned model that maps your datasets onto the object types your teams actually reason about, with security, classification and provenance carried at the level of individual objects and properties. Project 82 delivers that layer inside your own perimeter — single host, sovereign cloud, or fully air-gapped enclave — and, critically, closes the loop by letting operators *act* on the model, not merely look at it.

We follow a single worked example throughout: a harbour-side investigation connecting a vessel, a transaction, a site and a consignee. It is a deliberately ordinary case, because the argument does not rest on exotic analytics. It rests on something simpler: when your model of the world matches the world, decisions get faster, evidence gets stronger, and audit stops being an afterthought.

## 1. BI answers questions about columns. Operators ask questions about the world.

Consider the question an investigations lead at a port authority actually asks:

> "The vessel *Kestrel Dawn* berthed at the East Quay on Tuesday. Who paid for that berth, which consignee is receiving the cargo, and have we seen this combination of parties before?"

Now consider what your current stack requires to answer it. The berthing record lives in the port management system. The payment sits in a finance export. The consignee appears in a customs manifest feed. Vessel identity — name, IMO number, flag history — is spread across two reference datasets that disagree with each other. A business-intelligence tool can chart berth utilisation by month with ease, because that is a question about a column. But "who is behind this vessel?" is a question about a *thing*, and things do not live in any one table.

So the question is answered the way it always is: an analyst spends an afternoon exporting, joining and eyeballing spreadsheets, and the answer arrives as a screenshot in an email — unversioned, unaudited, and unreproducible three weeks later when a decision made on its basis is challenged.

The failure here is not a lack of data or a lack of dashboards. It is a modelling failure. The enterprise has invested heavily in describing its data and almost nothing in describing its *world*.

## 2. The ontology: turning datasets into a model of operations

Project 82's answer is the ontology: a declared, versioned mapping from datasets to **object types**, **properties** and **link types**.

In the harbour example, the ontology defines a `Vessel` type (properties: name, IMO number, flag, tonnage), a `Site` type for berths and terminals, a `Transaction` type for payments and berthing fees, and an `Organisation` type covering agents and consignees. Link types express the relationships that matter operationally: `Vessel —berthed at→ Site`, `Transaction —paid by→ Organisation`, `Consignment —destined for→ Organisation`.

Three design decisions distinguish this from yet another semantic layer bolted onto a warehouse:

**The foundation is versioned and immutable.** Data lands in Project 82 as versioned, immutable datasets — each version a set of columnar segments plus a manifest recording schema, row counts, content hashes and parentage. Transformations are pipelines as code, and the mapping from dataset to object is *itself a pipeline*. When the customs feed changes shape, or a mapping rule is corrected, the ontology re-materialises under version control: you can state exactly what the model said last Tuesday, and roll back if a change was wrong. The model is governed with the same discipline as the data beneath it.

**Security lives on the objects, not just the tables.** Access policy in Project 82 is evaluated where operators actually work: at the object and property level, beneath a non-bypassable tenant and classification ceiling enforced in the database itself. The `Vessel` object may be broadly visible while its beneficial-ownership property is restricted to a named team under a specific purpose grant. Classification markings (for example `OFFICIAL` through to higher tiers) travel with objects and render as banners wherever those objects appear, and every read of marked data is written to an append-only audit log. Purpose-based access requests, marking ceilings and exportable evidence packs are platform features, not a policy document taped to the side of a database.

**Every property knows where it came from.** Because datasets are immutable and lineage is recorded end to end, each property on each object traces back to the source row, the pipeline version and the sync job that delivered it. The `Kestrel Dawn`'s flag value is not merely "in the system" — it is traceable to row 4,182 of Tuesday's registry extract, pulled by a named connector agent at 03:12, transformed by pipeline version 14 whose code hash is on record.

## 3. Provenance is the point: decisions that carry their evidence

That last property deserves its own section, because it is where most stacks quietly fail.

When your operations director suspends the *Kestrel Dawn*'s berthing privileges, or your investigations lead escalates the consignee to a financial-intelligence unit, the decision will eventually be questioned — by a regulator, a court, an internal audit function, or the affected party. The question is never "was your dashboard accurate in general?" It is: "on what evidence, exactly, did you act, and can you produce it?"

In a stitched-together stack, the honest answer is an archaeology project: which extract was loaded that week, which version of the join logic ran, whether anyone edited the spreadsheet after the fact. In Project 82, the answer is a query. The investigation references objects; the objects reference properties; the properties reference dataset versions, transform versions and the signed sync jobs that fetched the data. This is **auditor-defensible provenance**: the decision carries its evidence with it, and an evidence pack — the objects viewed, the property values as they stood, the lineage behind them, and the audit trail of who saw what — is a console export, not a six-week reconstruction.

The same machinery serves compliance passively. Because purposes, retention and classification are attached to the model, obligations such as records of processing can be generated *from the ontology itself* rather than maintained by hand in a register that drifts from reality.

## 4. Analysis follows the model

Once the world is modelled as objects and links, the analytical surface stops being a gallery of disconnected charts and becomes a set of views over one model:

- **Object explorer.** Search for the `Kestrel Dawn`; see its properties, markings and history; pivot across links to its berthings, its agents, its transactions. Filtering happens in the vocabulary of operations — "vessels flagged in the last ninety days with a berthing at East Quay" — not in SQL.
- **Graph view.** The analyst pivots from vessel to paying organisation and notices the same shipping agent behind three transactions to two different consignees. As a join across five tables this pattern is invisible; as a picture of linked objects it takes seconds to see.
- **Map view.** Sites, berths and vessel positions in spatial context — because a harbour is a place, not a postcode column.
- **Time-series view.** Sensor and reading objects — gate movements, berth occupancy, weighbridge totals — charted against the same object identities the rest of the investigation uses.
- **Saved investigations.** The assembled picture — vessel, transaction, site, consignee, and the analyst's annotations — is a first-class, shareable, access-controlled artefact that a colleague can pick up on Monday, with every element still linked to live objects and their provenance. Dashboards, likewise, are built over ontology queries, so a "flagged vessels this quarter" tile means the same thing as the objects behind it.

For deployments that enable it, an on-premises assistant can sit over the same surface — grounded strictly on the objects the caller is entitled to see, with prompts that never leave the enclave. It is an accelerant for the model, never a bypass of its policy.

## 5. From seeing to doing: actions with audit and approval

Here is the sharpest break with the BI tradition. A dashboard's terminal act is a screenshot. An operational platform's terminal act is an *operation*.

In Project 82, **actions** are defined on object types, with the same rigour as everything else. Our investigations lead can:

- **Flag** the `Kestrel Dawn` — an audited state change on the vessel object, immediately visible to every team whose views include it;
- **Assign** the investigation to a named officer, with the case and its objects travelling together;
- **Annotate** the consignee organisation with a structured assessment that becomes part of the record, not a comment in a chat thread;
- **Kick off writeback** — for instance, pushing a hold flag into the port management system itself, executed through the same connector agent that syncs data in.

Every action is subject to mandatory audit, and consequential ones sit behind approval workflows: the berthing suspension is proposed by the analyst, reviewed against the evidence — which, per section 3, is attached — and approved by the duty manager, with the whole chain recorded.

The writeback path deserves a note on trust, because it is where "acting on data" usually terrifies IT departments, and rightly so. Project 82's connector agents dial *out* to a single URL; nothing connects into your source networks. Every job an agent executes — sync or writeback — is cryptographically signed and addressed to that specific agent, and writeback is restricted to allow-listed statement templates: the platform cannot be made to execute free-form commands against your systems of record, even by a compromised control plane. Acting on the world is a first-class feature precisely because it is engineered to the same trust standard as everything else.

## 6. Why this belongs inside your perimeter

Could you approximate this by wiring together a data warehouse, a BI tool and a case-management product? Organisations try, and the attempt fails in predictable ways.

**The seams destroy the guarantees.** Provenance, classification and audit are only as strong as their weakest hop. The moment data crosses from warehouse to BI extract to case file, lineage breaks, markings fall off, and the audit trail fragments across three vendors' logs. The properties argued for in this paper — object-level policy, row-level provenance, audited action — are not features you can retrofit at the joints; they hold only when integration, transformation, modelling, analysis, action and governance share one substrate.

**The seams multiply the attack and compliance surface.** Three products means three identity systems, three patching cadences, three sets of processor terms — and, for regulated and classified environments, three cloud dependencies to explain to an accreditor. Project 82 ships as a single deployable stack that runs entirely inside your perimeter: one host to start, scaling out when needed, with an air-gapped profile in which the only external channel is a one-way, signed-bundle import for reference data and updates. No telemetry, no licence pings, no external dependencies at runtime. Nothing leaves the enclave — architecturally, not contractually.

**The seams are where the cost lives.** The integration tax between warehouse, BI and case tools is perpetual: every schema change, every new source, every policy update must be re-plumbed across the joints, usually by the scarcest people you employ. An ontology platform pays the modelling cost once, in one place, under version control.

The pattern of platform this paper describes has existed for years at the top of the market — priced for defence ministries and delivered with embedded engineering teams. Project 82's premise is that the sovereign and regulated mid-market deserves the same architectural idea as installable software: your hardware, your perimeter, your keys, your evidence.

The tables were never the point. The vessel at the quay, the payment behind it, the consignee at the gate — and the defensible decision you take about them — always were.

---

*Project 82 is a sovereign data-fusion and decision platform: integrate, transform, model, analyse, act, assist and govern — inside your own perimeter. For architecture and deployment detail, see the companion papers in this series.*