Keystone query reference

Atlas holds every fact it knows about SAP — every artifact, every relationship, every piece of evidence — in a Keystone knowledge graph. This section is the reference for that graph: what it stores, how the pieces connect, and how to query them.

How this section is organized

Node types

Ten families of classes — SAP artifacts, documents, guidance, plans, cases, bundles, estimates, governance, and the SAP source-intelligence sub-graph. Every class, with its parent and label.

Relationships

Every object property — the edges that connect nodes. Domain, range, inverse, and the pattern Atlas uses them for.

Datatype properties

Every literal-valued property — names, hashes, timestamps, percentiles. Domain, datatype, and meaning.

Worked examples

Seven SPARQL queries covering the patterns Atlas's own services exercise: caller-discovery, entity resolution, plan-graph traversal, stability-tier rollup, released-API lookup, evidence export.

The shape of the graph

Atlas’s ontology lives at ontology/atlas-ontology.ttl with SHACL constraints in ontology/atlas-shapes.ttl. Two prefixes carry the whole model.

Prefix	IRI	What it holds
atlas:	https://atlas.naburis.cloud/ontology#	Nine families: SAP artifacts, source documents, guidance, version scope, plans, engineering cases, bundles, estimates, governance signals.
sap:	https://atlas.naburis.cloud/ontology/sap#	One family — SAP Source Intelligence: the detailed CDS / OData / release-contract sub-graph Atlas reasons over when planning.

Every instance Atlas writes carries a sourcedFrom triple pointing at the originating document, with a version hash and a timestamp. That is the substrate of the evidence trail — every claim in the graph can be traced back to where it came from.

How to run a query

The SPARQL examples on this site describe the shape of the queries Atlas’s own services run. End users do not issue SPARQL directly — the Studio’s Investigate view wraps it in a natural-language surface that calls POST /api/atlas/resolve with an intent + prompt, and the gateway translates that to the traversal under the hood. The examples page is here so a reviewer can see the shape of each retrieval pattern Atlas runs internally and verify the query is doing what the prose describes.

The worked examples

The Examples page lists all seven. They cover the queries Atlas’s own services run in production:

• Find every caller of a deprecated BAPI.
• Resolve one concept across four source names into a single graph node.
• Walk a plan’s dependency graph from consumption view down to basics.
• Compute the effective stability tier of a plan (min across dependencies).
• List everything SAP superseded in a named release.
• Find released A_ replacements for a custom Z-view.
• Export a plan’s full evidence trail as JSON-LD.

✓

Examples are tested in CI

Each example ships as a standalone file at docs/examples/keystone/*.rq and is executed in CI against the staging graph. When the ontology or the staging fixtures change, out-of-date examples fail the build before the page ships — so every query on this site runs as printed.

Why Keystone, not Postgres or a vector store

The one-sentence version: Atlas’s traversals are typed graph walks over facts whose provenance has to travel with them, and SPARQL expresses that directly. For the longer rationale — the alternatives considered, the costs Atlas accepted, and what the store is not used for — see Why a knowledge graph.