2026-05-17· 9 min read

Graph data fabric - semantic graph, hybrid persistence

Graph-first architecture does not mean one database for everything. The semantic graph owns meaning while persistence categories earn their roles by workload.

graphsdata-fabricpersistencearchitecturedeterminism-laddermcp

Graph-first architecture has an easy misunderstanding: put everything in a graph database.

Wrong target.

The graph is the semantic fabric. It owns identity, relationships, lineage, provenance, policy, receipts, and authority. It explains what a thing means, how it connects, which evidence supports it, who can rely on it, and which system behavior may follow from it.

Persistence technology has a different job. It stores bytes under workload pressure: transactionality, volume, latency, search, analytics, replay, cost, retention, and sensitivity.

The clean architecture is not “one graph store for everything.” The clean architecture is:

MCP = agent-facing tool and resource protocol
REST API = stable application contract
domain/API classes = idempotent placement and relationship rules
semantic graph = meaning and authority
persistence categories = workload fit
fabric = graph-governed access across many persistence categories
Graph data fabric map with MCP chat surface, REST API, domain API classes, semantic graph, and persistence categories.
Domain/API classes upsert. Graph relates, points, and governs.

Agentic systems need named surfaces. Without them, “context” turns into a permission slip and “storage” turns into a pile of unrelated databases.

The recommended vendor-agnostic categories are:

SurfaceJob
MCPAgent-facing tools and resources for chat or IDE agents.
REST APIStable application contract, authorization boundary, schemas, rate limits, and failure handling.
Domain/API classesIdempotent placement logic deciding what gets upserted into graph state, workload-fit persistence, or both.
Semantic graphIdentity, relationships, provenance, lineage, authority, policy-bearing state, pointers, and receipts.
Persistence categoriesRelational, document, object, event/log, analytical, vector, search, cache/materialized view, and ledger/audit stores.

The REST API matters because it is the application boundary. MCP should not decide persistence. The graph should not receive every payload and distribute it outward. Domain/API classes sit behind the REST contract and make the placement decision under idempotent rules.

What the graph owns

The graph should hold the relationships a system cannot afford to rediscover every run.

Those relationships include:

  • entity identity and aliases
  • ownership, scope, and authority boundaries
  • lineage from raw evidence to derived claim
  • policy relationships and gate conditions
  • provenance for facts, receipts, and model outputs
  • version links between drafts, critiques, decisions, and shipped artifacts
  • trust state, freshness state, and confidence state
  • traversal paths agents may use before acting

This makes the graph a control plane for meaning. It does not need every payload byte. It needs durable pointers, hashes, relationships, and state transitions.

The graph answers questions like:

  • What is this?
  • Where did it come from?
  • What does it depend on?
  • Which rule applies?
  • Which evidence supports it?
  • Which agent or workflow may use it?
  • Which decision promoted it from claim to authority?

Once those questions have graph answers, storage can vary without losing the system’s memory of meaning.

What persistence categories own

Different persistence categories exist because workloads differ.

Relational stores fit strict writes, constraints, joins, and operational records. Document stores fit flexible records with changing shape. Object stores fit large evidence artifacts, exports, media, logs, and immutable receipts. Event logs fit append-only streams, replay, and ordering. Analytical stores fit wide scans, aggregates, and historical questions. Vector indexes fit similarity retrieval. Search indexes fit lexical discovery. Caches and materialized views fit live decisions with tight latency budgets. Ledger-style stores fit append-only proof, non-repudiation, and audit trails.

None of those categories should own the whole meaning layer by accident.

A large receipt can live in object storage while the graph stores its hash, owner, source, sensitivity, claim links, and retention state. A high-volume event stream can keep raw event order while the graph receives promoted entities and relationships. A vector index can help retrieve nearby passages while the graph decides which retrieved fact has provenance good enough for use.

The graph fabric reads across categories, but it promotes only governed meaning into graph state.

Persistence placement matrix mapping workload dimensions to graph responsibility and persistence categories.
Storage placement follows dimensions. Graph placement follows meaning.

The promotion rule

The most important boundary in a graph data fabric is promotion.

Raw material can sit outside the graph. Retrieved material can enter a model context. Candidate claims can appear in an eval or verifier panel. None of those steps automatically grant authority.

Authority appears when the system records a graph transition:

raw evidence -> extracted claim -> reviewed claim -> accepted fact -> policy-bearing state

Each arrow needs a named rule. Some arrows may require an eval. Some may require a gate. Some may require human approval. Some may require multi-agent convergence. The graph stores the transition, not just the final fact.

This connects directly to behavior placement. Retrieval can shape a model answer. A graph transition can change authority. Confusing those two layers creates quiet risk.

Why agents need this fabric

Agents do not need random database access. They need a navigable surface with boundaries.

MCP belongs above the REST API. The MCP presents simple chat-facing tools and resources. The REST API enforces application contracts, authorization, rate limits, schemas, and failure handling. Domain/API classes decide idempotently what gets upserted into the graph, into another persistence category, or into both.

The graph does not receive all data and then pour it into storage. Domain/API classes make placement decisions. The graph records how persisted data relates, which facts have authority, and which evidence or payload each relationship points toward.

An agent should be able to ask:

  • Find the relevant entity.
  • Traverse to supporting evidence.
  • Check freshness.
  • Check scope.
  • Check authority.
  • Retrieve the payload if allowed.
  • Leave a receipt.

The graph data fabric gives the agent a route through the system without pretending every storage engine speaks the same language. The graph supplies the map. Each persistence category supplies the payload or index best suited to its job.

This is also why a public MCP should project published graph context instead of tunneling into a workspace. Published-content MCPs covers the public boundary. The same pattern scales inward: expose graph-governed context, not random backend reach.

The common anti-patterns

The first anti-pattern is graph maximalism. Everything becomes a node, every payload becomes an edge, and storage decisions turn into ideology. The result usually costs more, performs worse, and makes large evidence harder to preserve.

The second anti-pattern is storage sprawl. Each database becomes its own private worldview. Entities drift. Provenance fragments. Agents retrieve whatever looks nearby. Gates lack a stable authority surface.

The third anti-pattern is vector amnesia. Similarity search retrieves useful fragments, but no graph binds those fragments to identity, provenance, policy, and acceptance state. The model sees plausible context without knowing whether the system trusts it.

The fourth anti-pattern is analytic authority. Dashboards and aggregates become operational truth without a graph transition naming how a measurement became a decision.

The answer is not one database. The answer is one semantic fabric over many persistence categories.

How this fits the ladder

The Determinism Ladder moves behavior from loose model influence toward explicit control.

Graph data fabric makes the graph rung concrete:

prompt asks
retrieval finds
graph explains
tool acts
gate blocks
eval proves
persistence preserves

Local graphs first covers the smallest useful version: files before infrastructure gravity. Graph-constrained execution covers explicit execution topology. This article covers the data layer between those moves: graph as meaning, hybrid persistence as storage.

The practical rule stays simple:

Store bytes where workload fits. Store meaning where agents, gates, and humans can traverse it.

Axioms applied in this essay

This article tested 7 of the StoneyTECH engineering axioms. Each verdict is the result of applying that axiom in this specific argument.