Visualizing knowledge graphs in Context Engine

When you open a knowledge graph in Context Engine, it is shown as a semantic data graph. This is a unified, visual view of your organization’s data from two connected perspectives—the physical structure of your warehouse, and the business meaning layered on top of it. This guide explains what the visualization shows, and how to navigate around it. Visualizing a knowledge graph lets you move beyond questions like “What columns are in this table?” or “Where does order revenue live?” Instead, you can explore business questions, such as “Show me all the revenue metrics,” and see how the graph traverses the semantic layer to find the relevant tables and columns automatically. This is also what enables Maia Team to speak the language of your business: when you select this knowledge graph for a task in Mission Control, Maia Team uses these same semantic and physical layers to interpret your prompts and find the right data.

---

​

What knowledge graphs contain

Combined, a single knowledge graph can contain thousands of interconnected nodes that span your warehouse structure, the business concepts mapped to it, and the evidence and documentation that support those mappings.

​

Physical and semantic layers

Every knowledge graph is built from two layers that map onto each other:

• Physical layer: Your actual warehouse structure. This includes the tables and columns ingested by the crawlers you add to the knowledge graph, along with their schemas, column definitions, and inter-table relationships, such as foreign keys.
• Semantic layer: The business meaning that sits on top of the physical layer and contextualizes it within your organization and industry. This includes:
  • Domains: Groups of related business concepts, such as “Sales”, “Customer support”, or “Inventory management”.
  • Entities: Real-world business objects inferred from your data, such as Order, Account, or Subscription.
  • Attributes: Business-friendly properties that map onto the actual columns in your warehouse, bridging business language and raw SQL columns.

The semantic layer sits on top of the physical layer. This means that you can explore your data landscape in business terms without needing to know the underlying schema.

​

Evidence

Alongside the physical and semantic layers, a knowledge graph also stores evidence that supports its structure:

• Documentation: Often broken down into individual statements, documentation provides automated context for each entity and table.
• Profiles: These aggregate this evidence to help explain what a piece of data means.

​

Pipeline lineage

If you add a Pipeline execution crawler to a knowledge graph, it also tracks which pipelines read from and write to tables in your warehouse structure, which shows you how data flows through your organization.

---

​

Example business question

The following example shows how a business question travels from the semantic layer down to the physical layer, using a fictional order revenue metric. Semantic layer:

• Domain: Sales, the business area that groups revenue-related analysis, and CONTAINS the entity below it.
• Entity: CustomerOrderAnalysis, a cross-domain analysis record that correlates order revenue metrics with customer engagement metrics. This entity HAS the attribute below it.
• Attribute: ordertotal, the semantic property representing “total order revenue.”

Physical layer, connected by MAPS_TO:

• Column: order_total, in the table SALES.REPORTING.order_analysis.
• Table: order_analysis, the actual warehouse table that holds the data.

This example shows why the connection between layers matters:

• In the semantic layer, a single attribute like ordertotal can MAPS_TO multiple physical columns that represent total order revenue across different tables, reducing the underlying schema complexity.
• Domains organize this information by business purpose. When you ask a business question, the graph traverses from domain to entity to attribute, follows each MAPS_TO relationship, and shows you which tables and columns hold the relevant data.

You can trace a knowledge graph in either direction:

• Forward: Start with a business question, find the relevant entity, find its attributes, then follow MAPS_TO to the physical columns that hold the data.
• Backward: Start with a table, trace up through its CONTAINS relationships to find the attributes that MAPS_TO it, then see which entity and domain it serves.

Evidence sits on both semantic and physical nodes, so you get supporting context at either end of this trace.

---

​

Exploring knowledge graphs

In the left navigation, click , then Context Engine to open the Context Engine dashboard. This shows all the knowledge graphs you can access—each tile contains the knowledge graph’s name, the number of nodes it contains, and the number of projects that can access it. Click a knowledge graph to view the semantic data graph representing all the information this knowledge graph contains. Here, you can chat to Maia Team about the data in this knowledge graph, and explore the knowledge graph yourself. Maia Team can summarize the content of a knowledge graph, guide you through the nodes and connections the knowledge graph contains, and use it to answer business questions.

​

Nodes

Click any node in your knowledge graph to see its description and a list of the nodes it connects to. When viewing the details about a node, click a node in the connections list to see its details. Use the Nodes drop-down to choose which nodes to visualize. The number on this drop-down represents the nodes currently visible in the knowledge graph.

​

Edges

The Edges box displays how many connections the knowledge graph contains. This number changes depending on which nodes are currently visible. Hover over the connection between two nodes to see the relationship between them. Relationship types include:

• Structural: These represent layers. For example a warehouse CONTAINS databases, or a domain CONTAINS an entity.
• Semantic: These link business concepts to physical data. For example, an entity HAS attributes, or an attribute MAPS_TO a column of data.
• Data lineage: These track pipeline execution. For example, a pipeline READS_FROM a table in your warehouse, or one pipeline execution TRIGGERED another.
• Evidence: These connect business knowledge to the evidence or documentation that supports it. For example, a profile MENTIONS statements supporting a particular entity.

​

View options

• Click Reset view to display all nodes.
• Click Fit to frame to zoom out far enough to see the whole knowledge graph.
• Use your mouse to move around the knowledge graph:
  • Left click to rotate the knowledge graph.
  • Middle click or scroll to zoom in and out.
  • Right click to pan across the knowledge graph.