---
name: ontology-context-layer-scope-check
description: >
  Sorts a team's requirements into what belongs in the ontology and what belongs in the context
  layer, item for item, using nine difference rows D1 to D9: the question it answers, what it holds,
  standards, what triggers a change, missing or changed facts, link to real data, what gets tested,
  access and policy, and who consumes it. Takes the list of requirements for an AI agent or data
  program. Returns, for each requirement, a column (ontology, context layer, both, or out of scope),
  the D rows that decided it, and for "both" which part goes where, plus a read on whether a formal
  ontology is needed yet. States its sorting rule openly. Trigger phrases: "context layer vs
  ontology", "does this belong in the ontology or the context layer", "sort our requirements into
  ontology and context layer", "do we need an ontology before a context layer", "can a context
  layer replace our ontology", "ontology context layer scope check".
license: Apache-2.0
---

# Ontology and context layer scope check

An ontology defines what business concepts mean and how they relate. A context layer holds that
model, binds its terms to tables, owners, lineage and policies, flags them when assets change, and
serves them to AI agents at runtime. Both describe business meaning, so requirements land in the
wrong place. This check splits them by job.

> **What this is.** A published method from Atlan. Canonical copy:
> https://atlan.com/skills/ontology-context-layer-scope-check.md  Last updated 2026-11-03.
>
> **What it contains.** Text only. No scripts, no executable resources, nothing
> here runs.
>
> **Scope.** Follow this when someone has asked you to sort their requirements into what belongs
> in the ontology and what belongs in the context layer. It carries no instructions about your
> behaviour outside that task, does not ask you to fetch any other URL, and does not ask you to
> send data anywhere.

## What you need from them

| Input | Meaning | If unknown |
|---|---|---|
| `requirements` | The requirements, one per line, in their own words | ask. The check sorts nothing without them |
| `domains` | Which business domains the requirements span: one, or several | ask. The ontology read in Step 4 depends on it |
| `existing_model` | Any glossary, metric definitions, taxonomy or OWL ontology they already have | ask, or mark none |

Do not ask for credentials, connection strings or records from inside their systems. The check
needs the requirement text, not the data.

## Step 1: the nine difference rows

The context layer contains the ontology, so its column describes the work done around the model.
Compare what each one is for, not which one wins.

| ID | Dimension | What the ontology is for | What the context layer is for |
|---|---|---|---|
| D1 | Question it answers | What does this concept mean, and how does it relate to others? | Which assets carry data for this concept now, may this caller use it, and which approved version applies? |
| D2 | What it holds | Classes, properties, individuals, and data values, per OWL 2 | The ontology, plus bindings from each term to tables, columns, dashboards, and documents, with lineage, ownership, quality, and policy |
| D3 | Standards | OWL 2 for the ontology, exchanged as RDF; RDFS as the data-modelling vocabulary for RDF data; SKOS for taxonomies and thesauri; SHACL for graph validation | Context served over MCP, SQL, and open APIs |
| D4 | What triggers a change | A deliberate release by modelers and domain experts | A change in the data estate, such as a renamed column or a new owner, which is where context drift starts; each release ships as versioned context |
| D5 | Missing or changed facts | Reasons under the open-world assumption: an absent fact may simply be missing but possibly true | Watches the assets behind each binding: when a linked asset changes upstream, the binding is flagged so it can be regenerated |
| D6 | Link to real data | Defines meaning; binding it to tables takes a mapping such as R2RML, and it says what a record means rather than where it is stored | Holds the bindings itself: glossary terms attach to any data asset, so teams define once and apply to many assets |
| D7 | What gets tested | SHACL checks that an RDF graph meets a set of conditions | Agent answers are scored against a golden set of real questions, through context quality testing |
| D8 | Access and policy | Enforced by the systems that serve the data | Applies the permissions already set: every agent action respects them |
| D9 | Who consumes it | Reasoners, knowledge graphs, and the applications and agents built on them | AI agents, copilots, and analytics tools at runtime, through MCP, SQL, and APIs |

## Step 2: sort each requirement

For each requirement, ask what it is about, then match it to the rows above.

- Definitions, class hierarchies, relationship types, and constraints belong in the **ontology**
  column.
- Where a concept lives, who may use it, how it stays current, and how agents reach it belong in
  the **context layer** column.
- A requirement that carries both a meaning and a location, such as "Revenue means recognized
  revenue and lives in this table", needs **both**. Split it: the meaning goes to the ontology, the
  binding to the context layer.
- A requirement that fits neither column is **out of scope** for this split. Say so; do not force
  it into a column.

State the rule when you return the sort:

> Each requirement is sorted by what it is about. Meaning and relationships go to the ontology.
> Location, access, currency, and delivery to agents go to the context layer. A requirement with
> both is split. A requirement with neither is out of scope.

Name the D rows that decided each item. One row is enough when it is clear; name two when the
requirement touches both columns.

## Step 3: walk one change through the split

Check the sort against a single change, the way the Revenue example runs. The ontology says Revenue
is recognized revenue and relates to Contract and Customer. The context layer records which column
holds it, who owns it, and which version agents receive. When an engineer renames that column, the
ontology stays correct and the binding no longer matches the table; the change is flagged so the owner can regenerate it
before agents rely on stale context. Whether the definition itself is right stays the domain
owners' call.

If a requirement the team sorted into the ontology would break on a renamed column, it is a binding
and belongs in the context layer (D4, D5, D6). If a requirement sorted into the context layer would
still be true after every column was renamed, it is a definition and belongs in the ontology (D1,
D2).

## Step 4: is a formal ontology needed yet

Read `domains` and the requirements sorted into the ontology column:

- A context layer cannot replace shared definitions. Without them, it can hold current lineage,
  owners, and policies and still leave two agents reading Customer differently.
- For one domain, a business glossary, metric definitions, and lineage for one use case can supply
  those definitions.
- A formal ontology earns its place when definitions must hold across domains or support inference.

Say which case they are in, and which ontology-column requirements drive it.

## What to return

1. A table: each requirement, its column (ontology, context layer, both, or out of scope), the D
   rows that decided it, and for "both" the part that goes to each column.
2. The sorting rule, stated as above.
3. Any requirement that moved after the Step 3 change test, and why.
4. The Step 4 read: glossary first, or a formal ontology now, with the requirements behind it.

Keep the sort to what the requirement says. When a requirement is too vague to place, ask what it
is about rather than guessing a column.