Semantic Knowledge Graph

The Knowledge Graph is the semantic-object graph for your workspace. It records each modeling object as a node grouped by its type, and the edges that connect them — for example, a reveal that depends on a node, or a mosaic that uses a reveal. These edges are the data that Lineage and Impact Analysis read when they trace what feeds an object and what would break if you change it.

Overview

The graph tab lists every object that participates in at least one relationship, grouped under an uppercase heading for its object type (for example reveal, mosaic, node) with a count of how many objects fall under that type. Each object is shown as a small chip labelled with its object id.

You don't draw this graph by hand. It populates as you build — when you create reveals, build mosaics that pin those reveals, and configure connections, Celiq derives the relationship edges between those objects. The Knowledge Graph tab reads back the set of objects that appear on either end of an edge, so an empty graph simply means no relationships have been derived yet.

Because every Lineage and Impact Analysis lookup walks these same edges, keeping the graph current is what keeps those two features accurate. When the underlying model has changed and the derived edges are stale, a Luminary runs Rebuild graph to re-scan the semantic layer and regenerate them.

When to use it

• To confirm an object is actually represented in the graph before you rely on its Lineage or Impact Analysis.
• To get a quick inventory of which reveals, mosaics, and nodes are connected across the semantic layer.
• To rebuild the derived relationships after creating or editing reveals and mosaics, so Lineage and Impact Analysis reflect the current model.
• To sanity-check that a newly built reveal or mosaic shows up in the graph after you save it.

Concepts

Getting started

• You are signed in as a Luminary or Weaver. (Lens and Tracer don't have access to Context Studio.)
• You have built at least one reveal or mosaic, so there are relationships for the graph to derive. The Rebuild graph action is available only to Luminary.

Step-by-step

Examples

You build a reveal called orders on a node, then pin it as a tile in a mosaic called Exec Overview. After saving, a Luminary opens the Knowledge Graph tab and runs Rebuild graph. The scan derives:

• a depends_on edge from the orders reveal to its underlying node, and
• a uses edge from the Exec Overview mosaic to the orders reveal.

The object listing then groups the participating objects by type — the reveal, the node, and the mosaic each appear under their own heading.

Conceptually, the derived edges look like this:

mosaic:Exec Overview --uses--> reveal:orders
reveal:orders        --depends_on--> node:<orders node>

Reading the same relationships from the object's point of view, Lineage and Impact Analysis split them into:

outbound:  edges where this object is the source (what it leads to / uses)
inbound:   edges where this object is the target (what points at it)

That inbound/outbound split is exactly what powers "what does this depend on" (Lineage) and "what breaks if I change this" (Impact Analysis).

Best practices

• Rebuild after a modeling session. Create or edit your reveals and mosaics first, then rebuild once so the derived edges reflect the finished state.
• Check the graph before trusting Lineage or Impact Analysis. If an object isn't in the listing, downstream traces for it will be empty — rebuild first.
• Treat the graph as derived, not authored. You don't add objects by hand in this tab; you build reveals and mosaics and let the rebuild derive the relationships.
• Coordinate the rebuild. Since only Luminary can rebuild, agree on who runs it after a Weaver finishes a batch of modeling.

Tips

Common mistakes

Troubleshooting

Related pages

• Lineage
• Impact Analysis
• Context Studio overview
• Business Knowledge Graph (People, Teams, Goals, OKRs)
• Mosaics
• Reveals