Research reference

Each graph type answers a different question

A knowledge graph answers what the system knows about the world. A workflow graph answers what should run next and under which conditions. A reasoning graph answers why a conclusion was chosen. A state and memory graph answers what happened and what should persist. Each models a different set of relationships, carries its own invariants, queries, and failure modes, and belongs on the simplest substrate that can answer it.

Reviewed August 11, 2026 · 13 research and standards sources

Describe the graph. Leave with a working contract.

Turn your choices into a system prompt or versioned JSON specification without leaving your place in the guide.

Interactive builder

Turn decisions into a graph contract

Choose the graph’s responsibility, describe its behavior, then copy a system prompt or JSON specification.

Local only · nothing is sent or saved

  1. 1 Choose
  2. 2 Describe
  3. 3 Govern
  4. 4 Copy
1. What must the graph own?

Choose one primary responsibility. Add another graph later if the system needs a second one.

2. Describe the system Required
3. Add execution guardrailsLifecycle, failure, approval, and evidence
Live blueprint contract v1.1
execution

Research evidence workflow

Execution / workflow graph

Move forward when evidence is sufficient; return to retrieval when review finds a gap.

  • Human gate
  • Provenance on
  • session state
What a successful run should return
  • The task or state that was active at the start of the run.
  • The transition selected and the guard that allowed it.
  • The postcondition evidence that proves the transition succeeded.
  • The next eligible task, terminal state, or escalation requirement.
# CONFIG: v1.1 | agent | instructional + agent/tooling | deterministic local template

# System prompt: Research evidence workflow

## Role

You are the graph runtime for this execution / workflow graph. Your responsibility is execution: Coordinate tasks, gates, branches, retries, and terminal states.

## Task

Turn a research question into a source-backed answer with a review checkpoint.

Operate the graph by reading current state, selecting only valid edges, applying the requested action, and verifying the resulting state before reporting success.

## Required state schema

The runtime must provide:

- graph_version: required string
- current_node: stable node identifier or null
- requested_action: required string
- authorization: can_read, can_write, and requires_approval booleans
- available_tools: runtime-supplied tools with a name, description, and JSON input and output schemas
- evidence: stable id, source reference, and validation state for each evidence record

The required runtime state must match this JSON Schema:

{
  "type": "object",
  "additionalProperties": false,
  "required": [
    "graph_version",
    "current_node",
    "requested_action",
    "authorization",
    "available_tools",
    "evidence",
    "graph_state"
  ],
  "properties": {
    "graph_version": {
      "type": "string"
    },
    "current_node": {
      "type": [
        "string",
        "null"
      ]
    },
    "requested_action": {
      "type": "string"
    },
    "authorization": {
      "type": "object",
      "additionalProperties": false,
      "required": [
        "can_read",
        "can_write",
        "requires_approval"
      ],
      "properties": {
        "can_read": {
          "type": "boolean"
        },
        "can_write": {
          "type": "boolean"
        },
        "requires_approval": {
          "type": "boolean"
        }
      }
    },
    "available_tools": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": [
          "name",
          "description",
          "input_schema",
          "output_schema"
        ],
        "properties": {
          "name": {
            "type": "string"
          },
          "description": {
            "type": "string"
          },
          "input_schema": {
            "type": "object"
          },
          "output_schema": {
            "type": "object"
          }
        }
      }
    },
    "evidence": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": [
          "id",
          "source",
          "validation_state"
        ],
        "properties": {
          "id": {
            "type": "string"
          },
          "source": {
            "type": "string"
          },
          "validation_state": {
            "type": "string",
            "enum": [
              "validated",
              "unverified",
              "disputed"
            ]
          }
        }
      }
    },
    "graph_state": {
      "type": "object",
      "description": "Graph-type state validated by the runtime's domain schema."
    }
  }
}

If required state is missing or invalid, return blocked. Do not infer missing permissions, tools, or state.

## Tool registry

Use only tools supplied by the runtime with explicit input and output schemas. Validate tool input before execution and tool output before applying a state change. If a required tool or permission is unavailable, return blocked instead of inventing a call.

## Graph contract

- Graph type: Execution / workflow graph
- Named nodes: intake, retrieve sources, evaluate evidence, human review, publish
- Allowed node types: task, gate, outcome
- Allowed edge types: NEXT, ON_PASS, ON_FAIL, RETRY
- Relationship policy: Move forward when evidence is sufficient; return to retrieval when review finds a gap.
- Persistence: Keep state for the active session; do not treat it as durable memory without an explicit write.
- Selection basis: Choose this type when the system must control executable state transitions, guards, retries, approvals, and verified terminal conditions.

## Transition rules

1. Load and validate the runtime state before selecting an edge.
2. Select only a declared outgoing edge whose guard passes.
3. Check authorization and required approval before any tool call or write.
4. Execute only a tool bound by the runtime registry.
5. Verify the declared postcondition before recording success or advancing state.
6. Record the transition, evidence, and resulting state before returning.

## Graph-specific read and write order

### Read
1. load current state.
2. find eligible outgoing transitions.
3. evaluate guards.
4. select one next task.

### Write
1. record the attempted transition.
2. run the task.
3. store the result.
4. advance only after verification.

### Verify and stop
- Verification: A transition succeeds only when its declared postcondition passes; a tool call or write alone is not proof.
- Termination: Stop only at a declared terminal node or when the selected failure policy requires escalation.

## Constraints and failure handling

- Pause before irreversible or externally visible transitions and request explicit human approval.
- Attach source, actor, timestamp, schema version, and validation state to material records.
- Do not guess past a failed invariant. Preserve state and escalate with the attempted action, evidence, and required decision.
- Validate node and edge types before every write.
- Never infer private attributes or relationships that were not explicitly provided and authorized.
- Treat this prompt as behavioral guidance. Enforce permissions, schema validation, and success checks in the runtime harness.

## Expected successful result

- The task or state that was active at the start of the run.
- The transition selected and the guard that allowed it.
- The postcondition evidence that proves the transition succeeded.
- The next eligible task, terminal state, or escalation requirement.

Example valid successful result:

{
  "status": "complete",
  "active_node": "task:evaluate-evidence",
  "traversed_edges": [
    "task:retrieve-sources -[ON_PASS]-> task:evaluate-evidence"
  ],
  "state_changes": [
    "retrieval_status: pending → verified"
  ],
  "evidence": [
    "postcondition: minimum source coverage passed"
  ],
  "next_action": "Run task:evaluate-evidence"
}

## Output format

Return valid JSON only. Do not add prose before or after the JSON. The result must validate against this JSON Schema:

{
  "type": "object",
  "additionalProperties": false,
  "required": [
    "status",
    "active_node",
    "traversed_edges",
    "state_changes",
    "evidence",
    "next_action"
  ],
  "properties": {
    "status": {
      "type": "string",
      "enum": [
        "complete",
        "blocked",
        "needs_approval",
        "failed"
      ]
    },
    "active_node": {
      "type": [
        "string",
        "null"
      ],
      "description": "Stable node identifier or null."
    },
    "traversed_edges": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Typed edge identifiers in traversal order."
    },
    "state_changes": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Validated mutations made during this run."
    },
    "evidence": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Source or verification references."
    },
    "next_action": {
      "type": [
        "string",
        "null"
      ],
      "description": "One concrete next action or null."
    }
  }
}

## Acceptance criteria

- Every traversal uses a declared edge.
- Every write passes the graph schema and runtime policy.
- Every success claim cites its postcondition or evidence.
- Any uncertainty, missing evidence, or failed invariant is explicit.
- The final response matches the output contract and contains no undeclared fields.
- Production approval requires runtime fixtures and failure tests; prompt review alone is not sufficient.

A deterministic local checklist verifies that the generated prompt includes the required sections. This does not prove runtime behavior. Test permissions, schemas, transitions, expected outputs, and failure cases in your harness.

The short version

The short version

Graph engineering is the practice of designing systems that show relationships between data. The practice grew from graph theory and now supports semantic data, workflow systems, AI search, and agent memory. The four-part model on this page provides a starting taxonomy and build guide for using graphs in your projects.

Example A graph can represent a driver and a car as entities and connect them with a DRIVES relationship. A graph-aware search system can use that relationship to answer which car the driver uses.

Start with the relationship your system needs

The logical graph defines the relationships your system must understand. The substrate stores or runs that graph. PostgreSQL, JSON event logs, workflow engines, RDF stores, and graph databases can all support graph-shaped systems.

Related terms and their roles

Graph neural network
A model architecture that learns from graph-structured data. Its role is graph machine learning. Knowledge and workflow graphs describe different system responsibilities.
Computation graph
A graph of mathematical operations used for execution and differentiation inside ML systems.
Vector index graph
A structure such as HNSW that accelerates nearest-neighbor search. It organizes retrieval paths. Application records and governed relationships provide domain meaning.
Graph visualization
A view of nodes and links. The picture displays a graph. Graph engineering defines the model, rules, and operation behind it.

The field converged from several histories

Graph engineering combines practices that matured at different times. Graph theory created the foundation. Semantic data, workflow systems, AI search, and agent memory expanded how engineers use the model.

  1. 1736

    A route became nodes and edges

    Euler reduced the Seven Bridges of Königsberg problem to places and connections. The abstraction mattered more than the map and became a foundation of graph theory.

    Oxford Academic ↗
  2. 1999

    Relationships became web data

    The W3C published RDF as a way to represent machine-readable statements and relationships on the web. RDF graphs express subject-predicate-object triples.

    W3C ↗
  3. 2000s

    Property graphs made traversal application-friendly

    Property-graph databases put properties on both nodes and relationships. Neo4j's vendor history dates its model to 2000 and its first open-source release to 2007.

    Neo4j history ↗
  4. 2012

    Knowledge graphs entered mainstream search

    Google's Knowledge Graph popularized search over entities and their relationships. Search could connect things and their meaning as well as matching strings.

    Google ↗
  5. 2023

    LLM systems made reasoning and memory graph-shaped

    ReAct, Tree of Thoughts, Graph of Thoughts, and generative-agent memory systems made actions, alternatives, evidence, reflection, and persistent experience explicit system structures.

    Graph of Thoughts ↗
  6. 2024+

    Standards matured while AI graph patterns expanded

    ISO published GQL for property graphs, while GraphRAG joined knowledge graphs with LLM retrieval. The data foundations are mature; many AI reasoning and memory patterns are still evolving.

    ISO GQL ↗

Four graph types share one repeatable build method

Each graph type answers a different system question. Choose a type to see its nodes, edges, use cases, build steps, invariants, verification queries, and failure modes.

01

Knowledge graph

Represent durable entities, claims, events, concepts, and the meaningful relationships among them.

Understand
Knowledge graph structural model Entity Claim Event Source
Entities connect to claims and sources through meaningful relationships.
Primary question
What does the system know about the world?
Typical lifetime
Long-lived
Starter nodes
Entity · Claim · Event · Concept · Source
Starter edges
RELATES_TO · MENTIONS · SUPPORTS · CONTRADICTS · DERIVED_FROM
Decide

Use it when

  • Relationships have domain meaning beyond one process run.
  • Questions require multi-hop traversal, entity resolution, or provenance.
  • Users need to connect evidence across many sources.

Choose another approach when

  • The data is naturally tabular and every useful query is a shallow join.
  • The team cannot define stable identities or meaningful relationship types.
Build this graph Recipe, invariants, queries, risks

Minimal implementation recipe

  1. Write the five questions the graph must answer before designing a schema.
  2. Define stable entity IDs, alias rules, and merge/split behavior.
  3. Name a small set of precise relationship types and their direction.
  4. Attach source, time, confidence, and validation to every assertion.
  5. Build extraction and entity-resolution paths, then test them on reviewed examples.
  6. Measure answer quality and graph quality separately.

Required invariants

  • Every claim or relationship has provenance.
  • Extraction confidence remains separate from verified truth.
  • Time-varying facts preserve prior versions when they change.
  • Identity rules produce the same canonical entity for the same input.

Verification queries

  • Which sources support or contradict this claim?
  • Which entities connect these two topics within two hops?
  • Which aliases remain unresolved or conflict with each other?

Suitable starting substrates

  • PostgreSQL tables
  • RDF + SPARQL
  • Property graph
  • SQLite for a bounded local graph

Common failure modes

  • Entity duplication
  • Vague predicates
  • Lost provenance
  • Ontology before questions
Research anchor: Hogan et al., Knowledge Graphs ↗
02

Execution / workflow graph

Represent tasks, states, gates, dependencies, retries, joins, approvals, and recovery paths.

Understand
Execution / workflow graph structural model Start Task Pass Retry Done
Tasks move through gates, branches, joins, and terminal states.
Primary question
What should run, in what order, and under which conditions?
Typical lifetime
Per definition and per run
Starter nodes
Task · Gate · Run · Approval · Artifact · Terminal state
Starter edges
DEPENDS_ON · ON_SUCCESS · ON_FAILURE · RETRIES · WAITS_FOR · PRODUCES
Decide

Use it when

  • The system has branches, retries, waits, parallel work, or human approvals.
  • A run must resume after process failure or interruption.
  • Operators need to explain why a run is blocked or which path it took.

Choose another approach when

  • The process is a short, deterministic sequence that plain code expresses more clearly.
  • The proposed graph would make side effects harder to observe.
Build this graph Recipe, invariants, queries, risks

Minimal implementation recipe

  1. Define start, waiting, failure, cancellation, and terminal states.
  2. Give each task a typed input, output, owner, timeout, and idempotency rule.
  3. Model success, failure, retry, compensation, and approval transitions explicitly.
  4. Persist run state or event history before adding parallelism.
  5. Add checkpoints and a safe resume rule for long-running work.
  6. Trace every transition and verify both success and failure paths.

Required invariants

  • Every run is terminal, waiting on a named condition, or actively owned.
  • Retries are bounded and side effects are idempotent or compensated.
  • A transition must be valid from the current state.
  • A resumed run cannot silently repeat a completed external action.

Verification queries

  • Which nodes are ready to execute?
  • Why is this run blocked, and what can unblock it?
  • Which downstream work is invalidated by this failure?

Suitable starting substrates

  • Plain code + typed state
  • Workflow engine
  • Durable event history
  • DAG scheduler

Common failure modes

  • Unbounded retries
  • Hidden side effects
  • No recovery path
  • Framework for a straight line
Research anchor: LangGraph Graph API ↗
03

Reasoning graph

Represent goals, questions, assumptions, evidence, alternatives, tests, decisions, and observed outcomes.

Understand
Reasoning graph structural model Goal ? A B Decide
A goal branches into alternatives that evidence tests before a decision.
Primary question
Why should the system choose this conclusion or action?
Typical lifetime
Per decision; retain selectively
Starter nodes
Goal · Question · Hypothesis · Evidence · Alternative · Test · Decision · Outcome
Starter edges
DECOMPOSES_INTO · SUPPORTS · REFUTES · TESTED_BY · SELECTED_OVER · VERIFIED_BY
Decide

Use it when

  • A consequential decision must remain explainable after the model call ends.
  • The system must compare alternatives, gather evidence, or backtrack.
  • Reviewers need to trace a conclusion to tests and external observations.

Choose another approach when

  • A deterministic rule or direct lookup already answers the question.
  • The design would store unrestricted hidden chain-of-thought or sensitive deliberation.
Build this graph Recipe, invariants, queries, risks

Minimal implementation recipe

  1. Decide whether the graph is transient search, a durable decision record, or both.
  2. Set a branch, token, time, and tool budget before exploring alternatives.
  3. Link claims to external evidence and observations. Keep the source material in its governed location.
  4. Persist concise assumptions, alternatives, rationale, decision, and uncertainty.
  5. Link each decision to the test or outcome that later verified or contradicted it.
  6. Prune failed branches and expire stale evidence under an explicit policy.

Required invariants

  • Model confidence never becomes authority by itself.
  • A durable decision cites evidence and records uncertainty.
  • The durable record contains concise rationale and evidence. Hidden chain-of-thought stays outside the record.
  • A failed test can invalidate dependent decisions.

Verification queries

  • Which decisions rely on unverified assumptions?
  • What evidence supports this conclusion, and what refutes it?
  • Which rejected alternative should be reconsidered after this result?

Suitable starting substrates

  • Typed JSON records
  • SQLite or PostgreSQL
  • Transient search tree
  • Graph store after measured need

Common failure modes

  • Branch explosion
  • Transcript-as-reasoning
  • Stale evidence
  • Confidence as permission
Research anchor: Graph of Thoughts ↗
04

State & memory graph

Represent events, checkpoints, episodes, memories, summaries, versions, scope, and continuity across runs.

Understand
State & memory graph structural model Event State Memory Run recall
Events become checkpoints and selected memories that inform a later run.
Primary question
What happened, what is true now, and what should persist?
Typical lifetime
Session to long-lived
Starter nodes
Agent · Session · Run · Event · Checkpoint · Episode · Memory · Summary
Starter edges
OCCURRED_IN · PRECEDED_BY · UPDATED · SUMMARIZED_BY · RECALLED_FOR · SUPERSEDES
Decide

Use it when

  • The system must resume, reconstruct state, or remember across sessions.
  • Multiple agents need shared coordination history with clear scope.
  • Old information must be superseded, expired, or traced to its origin.

Choose another approach when

  • A stateless request is complete after one response.
  • The system lacks retention, deletion, permissions, or conflict policies.
Build this graph Recipe, invariants, queries, risks

Minimal implementation recipe

  1. Separate authoritative current state, event history, selected memory, and lossy summaries.
  2. Record immutable events and derive current state when replay is practical.
  3. Add checkpoints with schema and software-version compatibility rules.
  4. Define what becomes memory, when it is retrieved, and when it expires.
  5. Scope reads and writes by user, agent, tenant, project, or thread.
  6. Propagate supersession and deletion into every derived index.

Required invariants

  • One source is authoritative for current state.
  • Every memory has scope, provenance, and a review or expiry policy.
  • Newer memory supersedes older memory without erasing history.
  • Deleting a source also removes or invalidates derived retrieval records.

Verification queries

  • What was the run state at this time?
  • Which checkpoint can safely resume execution?
  • Which memory supersedes this older memory, and why was it recalled?

Suitable starting substrates

  • Append-only event log
  • Checkpoint store
  • SQLite/PostgreSQL projection
  • Memory store + retrieval index

Common failure modes

  • Stale memory
  • Unbounded checkpoints
  • Cross-scope leakage
  • Shared writes without governance
Research anchor: LangGraph persistence ↗

Choose the simplest substrate that fits

Start with infrastructure your application already trusts. Adopt a dedicated graph system when query depth, latency, scale, or interoperability requirements justify the change.

JSONL + SQLite

Local tools, prototypes, event history, and shallow cross-run queries.

Start here when append, replay, portability, and low operations cost matter most.

PostgreSQL

Existing applications with transactions and bounded relationship traversals.

Use joins, recursive CTEs, indexes, and materialized projections before adding a new datastore.

RDF + SPARQL

Semantic interoperability, shared vocabularies, ontologies, and linked data.

Choose it when the meaning and exchange of statements matter across systems.

Property graph

Frequent, variable-depth, relationship-centric traversal and exploration.

Adopt it when measured queries are awkward or slow on the current substrate.

Workflow engine

Long-running execution with retries, timers, signals, approvals, and recovery.

Choose durable execution when the system needs operational guarantees across time and failure.

AI uses graphs around the model

Graph engineering structures the context, control, decisions, and continuity around an AI model. The graph gives the system explicit relationships the model can retrieve, follow, evaluate, or update.

Knowledge

Ground retrieval

Entity and claim graphs connect evidence across relationships. GraphRAG combines those relationships with vector similarity and community summaries for corpus-level questions.

Execution

Control agents

Workflow graphs represent tool calls, branches, retries, joins, approvals, checkpoints, and recovery as explicit product behavior. This structure keeps execution rules visible and testable.

Reasoning

Structure decisions

Search graphs can explore candidate paths. Durable reasoning graphs preserve concise evidence, alternatives, tests, and decisions without storing hidden chain-of-thought.

State & memory

Preserve continuity

Events, episodes, checkpoints, summaries, and supersession links let an agent resume work and recall relevant context across sessions.

How RossLabs tools use graph structures

These examples use architecture already published on this site. The descriptions remain at the product-pattern level and exclude private content, personal information, local paths, source filenames, and private graph relationships.

AI navigation map

Point an AI system at this URL and use the sequence below. Every substantive section is server-rendered HTML with a stable ID; the page also includes TechArticle JSON-LD and an embedded structured reference payload.

  1. Classify the primary responsibility. Semantics, execution, deliberation, or continuity.
  2. Open the matching anchor. #knowledge-graph, #workflow-graph, #reasoning-graph, or #state-memory-graph.
  3. Generate a portable blueprint when useful. Open the blueprint builder and copy either the system prompt or JSON interaction contract.
  4. Use the contract as the implementation reference. Follow its nodes, edges, invariants, build steps, and verification queries.
  5. Choose the smallest substrate. Use #substrate before introducing a graph database.
  6. Add provenance and policy. Record source, actor, time, version, scope, and validation for important graph records.
  7. Test the named failure modes. Verify traversals, writes, recovery paths, and declared success conditions.

Shared record envelope

Use a common outer record so the four logical graphs can reference one another without becoming one universal graph.

{
  "id": "stable-id",
  "graph_type": "knowledge | workflow | reasoning | memory",
  "record_type": "type-specific",
  "source_id": "provenance-reference",
  "created_at": "ISO-8601 timestamp",
  "actor": "human | service | model | tool",
  "schema_version": "1",
  "valid_from": "optional timestamp",
  "valid_to": "optional timestamp",
  "validation": "verified | disputed | unverified"
}

Sources and confidence

Overall confidence is high for the historical milestones, standards, graph data models, and workflow concepts. Confidence is moderate for the unified “graph engineering” field. The four-part taxonomy is a practical synthesis created for this guide.

Research brief

Graph Engineering for AI-Native Systems

The supplied 39-page report shaped the four-part working taxonomy. Its externally checkable claims were verified against the sources below.

Peer-reviewed survey

Knowledge Graphs ↗

Covers graph models, creation, enrichment, quality, identity, and publication.