Semantic Layer, Ontology, Context Layer: Three Different Things Wearing One Name

I wrote recently about the five layers sitting under any AI system that does real work, and said context was the one most teams skip. The reasonable follow-up was where context is actually supposed to live.

There are three answers to that, they get used as synonyms, and they are not synonyms. Working out which one you have is a large part of why some systems produce answers that are precise and wrong at the same time.

Semantic layer: what your numbers mean

A semantic layer defines metrics, dimensions, and joins once, so every tool computing a number computes the same number. A dashboard and an agent asked the same question to share the definition rather than each reimplementing it.

It is deterministic and cheap to put on top of a warehouse you already run, which is why it is usually the first thing built.

Its limit is that it cannot tell when the things underneath it is different objects wearing the same label. It will average across them without complaint.

Ontology: what your things are

An ontology says what your entities are, how they relate, and which identifiers in different systems point at the same real-world object.

This is the layer that resolves identity, and it has one practical advantage over most data modelling work. A domain expert can review it without reading SQL. If the model claims two records are the same asset, someone who knows the assets can tell you whether that is true, which is not something you can say about join logic buried in a transformation.

Its limit is scope. An ontology describes the world. It does not decide who is allowed to see it, and it does not record how a conclusion was reached.

Context layer: three questions it has to answer

The context layer wraps the other two and exists to answer three things.

Who is allowed to see this. Where did this figure come from. What did we already decide.

That third one is the part usually missing. Not the data, but the assumptions and choices accumulated over time, still available to whoever picks the question up next year.

Its limit is cost and honesty. Building it properly is expensive, and a fair amount of what gets labelled a context layer is a semantic layer or an ontology with a new name on the architecture slide. Governance and provenance are the test. If neither is implemented, the label is doing the work.

Two ways this goes wrong

A team builds the semantic layer, skips the ontology, and the system computes a precise metric across entities that do not match across sources. Every individual step is correct. The answer is not.

Or a team builds the ontology, calls it a context layer, and never implements access policy or lineage. The diagram improves. Nothing else does.

On sequencing: if your entities are genuinely unambiguous and the job is consistent metrics, a semantic layer on its own is enough and overbuilding is a waste. Add the ontology once several systems describe the same object differently, which most enterprises are already past. Build the full context layer when systems are permitted to act rather than answer, when several parties read the same data, and when someone will audit a decision long after everyone involved has moved on.

Why aviation breaks the first layer immediately

Aviation is an unusually sharp illustration of this, because asset identity here is genuinely unstable in a way it is not in most industries.

An engine has an ESN, and it moves between airframes across its life. The airframe carries an MSN that never changes and a registration that does change at lease transfer. The MRO records that engine under one serial format, the lessor's CMS under another, the operator's tech log under a third, the OEM under a fourth. None of those are errors. They are four names for one physical asset.

Now ask a portfolio question. Average time on wing across the fleet. A semantic layer will define time on wing correctly, apply it consistently, and hand you a number to two decimal places. If the shop visit history for one engine sat under a serial the join never matched, that number is wrong and nothing in the pipeline will raise a hand.

The ontology is what fixes it. One canonical asset, every alias each system uses for it, and the relationships between engine, airframe, and lease held explicitly. Your technical team can read that mapping and tell you whether it reflects reality, which is exactly why the work belongs at this layer rather than inside transformation code nobody reviews.

The three questions, for a lessor

Who is allowed to see this.A lessor, an MRO, and an OEM reading the same physical records through different views, with row and column level policy instead of three copies of the data quietly drifting apart. On our platform that runs onDatabricksUnity Catalog, with row-level security and column masking, so multi-tenant means logically separate rather than physically duplicated.

Where did this figure come from.Provenance from the source page of a scanned mini pack, through extraction and transformation, to model output. When you are arguing a discrepancy at redelivery or defending a valuation to a finance partner, the number matters far less than your ability to produce the page behind it.

What did we already decide.Which derate assumption underpinned the shop visit forecast in March. Which scenario the workscope was costed against. Which correction the records team made, and why. Without that, the same argument gets had twice and reaches two different conclusions.

The short version

If your agents return confident answers you cannot defend, work upward rather than sideways.

Check that your entities resolve before you trust your metrics. Check that you can trace an answer before you let anything act on one.

#ContextEngineering #DataArchitecture #AviationAI #AgenticAIKeepFlying®

KeepFlying builds the aviation FinTwin on Databricks and Azure. A knowledge graph holds the domain logic, Unity Catalog holds the governance, and extraction agents tuned to airframe, engine, APU, and landing gear records turn documents into queryable assets with lineage back to the source page.