Context graph
How Systemiq uses a graph-shaped model to structure operational context across the stack.
In Systemiq, a context graph is the working structure used to organize modeled entities, their relationships, and their directional impacts across the stack.
The graph is not a separate feature sitting next to the platform. It is how Systemiq keeps operational structure explicit enough to model, maintain, and query context over time.
Model view
How Systemiq structures operational context
Enterprise signals
Systemiq ingests selected operational evidence from across the enterprise stack.
Systemiq model
Structure the business into elements, subsystem context, system context, client-wide interpretation, and directional impact.
Elements
Atomic nodes and local state
Indicators, relationships, reaction behavior, and node-level evidence.
Tools
Subsystem context
Connection circles, causal loops, and other modeled subsystem behavior.
Systems
Operational boundaries and rollups
Cross-tool interpretation, system state, and propagated impacts.
Client
Cross-system interpretation
Client-wide insights, summaries, and interpretation across all or selected systems.
Agent access
Agents consume structured operational context rather than rebuilding reality from raw sources.
What agents ask for
Which systems matter, what changed, what is connected, where impact is rising.
Access surfaces
What the graph represents
- Elements act as the atomic modeled entities where local state and evidence are attached.
- Tools group connected elements into subsystem context such as connection circles, causal loops, or other modeled structures.
- Systems define major operational boundaries where tool-level context is interpreted together.
- Client-level interpretation can aggregate all or selected systems into higher-level insights and summaries.
- Mappings and impact relations make dependencies and directional influence explicit across layers.
- Records, metrics, summaries, and impacts persist graph-derived context as operational memory.
How Systemiq uses the graph
- Selected enterprise signals are attached to modeled entities instead of left as isolated raw inputs.
- Subsystem context is built by connecting elements into tools and other higher-order structures.
- System-level interpretation is derived by aggregating connected tool context within an operational boundary.
- Impact propagation is made explicit so the platform can carry forward influence, dependency, and change across the stack.
- The resulting graph-derived outputs are persisted and served back through MCP, APIs, maps, records, and metrics.
What this enables for agents
- Agents can retrieve narrowed operational context instead of reconstructing business reality from raw source systems.
- Agents can reason about relationships, dependencies, and rising impact rather than isolated signals.
- Multiple agents can work from the same current model instead of maintaining separate local interpretations.
- The context remains queryable over time rather than disappearing after a single execution.
Where it appears in the platform
- In stack structure: client scope, systems, tools, elements, mappings, and impacts.
- In query surfaces: MCP tools, records, metrics, and model navigation workflows.
- In visualization: maps and model views that make connected context inspectable.
- In operational memory: persisted outputs that retain graph-derived context over time.
Continue with Stack model for the concrete shape of client scope, systems, tools, elements, records, and metrics, or move to MCP to see how agents query the model.