AI System Graph
A typed, traversable representation of every architectural relationship in your system
What is the AI System Graph?
The AI System Graph is a formal directed graph that encodes your entire system architecture as typed nodes and edges. Every entity, capability, module, policy, invariant, flow, route, and file in your SysMARA project becomes a node. Every relationship between them — ownership, dependency, enforcement, governance — becomes a typed edge.
Unlike documentation or diagrams, the graph is machine-readable. AI agents can traverse it to answer questions like "what breaks if I rename the user entity?" or "which policies govern the create_subscription capability?" without parsing natural language or guessing at project structure.
Node Types
Every node has an id, a type, a name, and a metadata object. The id follows the format {type}:{name}.
| Type | Example ID | Description |
|---|---|---|
entity | entity:user | A domain object with typed fields and constraints |
capability | capability:create_user | A named operation with inputs, outputs, and policy gates |
module | module:billing | A boundary that groups entities and capabilities |
policy | policy:admin_full_access | An access control rule with conditions and effects |
invariant | invariant:email_must_be_unique | A business rule that must hold at runtime, compile time, or both |
flow | flow:billing_cycle | A multi-step workflow with failure handling |
route | route:POST:/api/users | An HTTP endpoint that exposes a capability |
file | file:routes/create_user.ts | A generated or managed file on disk |
Edge Types
Edges encode the semantic relationships between nodes. Each edge has a source, target, type, and optional metadata.
| Edge Type | Source | Target | Meaning |
|---|---|---|---|
belongs_to | entity | module | Entity is owned by this module |
uses_entity | capability | entity | Capability reads or writes this entity |
governed_by | capability | policy | Capability is gated by this policy |
enforces | invariant | entity | Invariant constrains this entity |
depends_on | module | module | Module depends on another module |
triggers | capability | flow | Capability execution triggers this flow |
exposes | route | capability | Route exposes this capability over HTTP |
owns | module | file | Module owns this generated file |
protects | invariant | capability | Invariant is checked when capability executes |
step_of | capability | flow | Capability is a step within this flow |
How the Graph is Built
The graph is constructed by the buildSystemGraph() function. It takes your parsed SystemSpecs (all YAML specs combined) and an optional array of RouteSpec objects, then produces a deterministic SystemGraph with sorted nodes and edges.
The build process follows these steps:
- Create a node for every entity, capability, module, policy, invariant, flow, and route in your specs.
- Create edges by walking the relationships: module membership, entity references, policy bindings, invariant enforcement, dependency declarations, flow triggers, route exposures, and flow steps.
- Sort all nodes and edges lexicographically by ID for deterministic output. Two identical specs always produce an identical graph.
Example Graph Output
Here is a partial JSON output from a SaaS billing system graph. Notice how the graph captures that create_subscription uses the subscription entity, is governed by billing_admin_manage_subscriptions, is protected by the no_duplicate_active_subscription invariant, and triggers the workspace_onboarding flow indirectly through its module relationships.
{
"version": "0.1.0",
"generatedAt": "2025-03-14T12:00:00.000Z",
"nodes": [
{
"id": "capability:create_subscription",
"type": "capability",
"name": "create_subscription",
"metadata": { "module": "billing" }
},
{
"id": "entity:subscription",
"type": "entity",
"name": "subscription",
"metadata": {}
},
{
"id": "invariant:no_duplicate_active_subscription",
"type": "invariant",
"name": "no_duplicate_active_subscription",
"metadata": { "entity": "subscription" }
},
{
"id": "module:billing",
"type": "module",
"name": "billing",
"metadata": {}
},
{
"id": "policy:billing_admin_manage_subscriptions",
"type": "policy",
"name": "billing_admin_manage_subscriptions",
"metadata": {}
}
],
"edges": [
{
"source": "capability:create_subscription",
"target": "entity:subscription",
"type": "uses_entity"
},
{
"source": "capability:create_subscription",
"target": "policy:billing_admin_manage_subscriptions",
"type": "governed_by"
},
{
"source": "entity:subscription",
"target": "module:billing",
"type": "belongs_to"
},
{
"source": "invariant:no_duplicate_active_subscription",
"target": "capability:create_subscription",
"type": "protects"
},
{
"source": "invariant:no_duplicate_active_subscription",
"target": "entity:subscription",
"type": "enforces"
}
]
} Why the Graph Matters for AI Agents
Traditional codebases force AI agents to grep through files, parse imports, and guess at relationships. The AI System Graph eliminates guessing by providing a single, traversable data structure that answers architectural questions directly.
Traversal
An AI agent can walk edges to discover all capabilities that use a given entity, all policies that govern a capability, or all flows triggered by a capability. This makes context gathering deterministic rather than heuristic.
Impact Analysis
Before modifying any spec, an agent can traverse the graph to compute the full impact surface: which modules, invariants, policies, capabilities, routes, flows, tests, and generated artifacts are affected. This drives the Change Protocol's risk classification.
Dependency Understanding
Module dependency edges let agents verify that a proposed change respects module boundaries. If a capability in the billing module needs to reference a user entity from the users module, the agent can check whether users is in billing's allowedDependencies before making the change.
Generating the Graph
Run the following CLI command to generate the graph from your YAML specs:
sysmara graph This parses all spec files from your configured specDir, builds the graph with buildSystemGraph(), and outputs the JSON. You can pipe it to a file or pass it to downstream tools for visualization or analysis.
AI-Safe Change Workflows
The graph is the foundation of SysMARA's AI-safe change workflows. When an AI agent proposes a change through the Change Protocol, the graph is used to compute impact surfaces, classify risk, identify human review flags, and determine which generated artifacts need to be refreshed. Without the graph, the agent would have no reliable way to assess whether a change is safe to apply automatically or requires human approval.