Edges of Edges: What Metagraphs Actually Are, in Practice

Every knowledge system eventually runs into the same wall. You have a fact. You want to say something about the fact. Who said it. When it was true. How confident you are. Whether another fact disputes it. And the moment you try to attach that second layer, you discover that the data model you chose treats facts as the floor and gives you no native way to stand on top of one. The fact is an edge. You want an edge that points at that edge. The model says no.

This is the central structural problem of the metagraph, and it is the reason metagraphs exist as a category distinct from graphs. A graph connects things. A metagraph connects connections. The word sounds like an abstraction for its own sake until you have spent a week working around the fact that your graph database will not let a relationship be the endpoint of another relationship, at which point it becomes the most concrete thing in your architecture. What follows takes that constraint apart: what it actually is, why two very different systems hit it from opposite directions, and the production patterns that let you build the metagraph you need on top of the property graph you can actually run.

The two systems are Goertzel's AtomSpace, which solves the problem natively and pays for it in production maturity, and Neo4j, which is production-mature and does not solve the problem at all without help. Most teams will deploy on something Neo4j-shaped. So most of what follows concerns the bridge: how to represent edges-of-edges, facts-about-facts, and rules-about-rules in a property graph that was never designed to hold them, without the design collapsing into an unqueryable mess.

What an AtomSpace actually is

Start with the system that gets the model right, because it makes the constraint visible by not having it. An AtomSpace, in OpenCog and its successor Hyperon, is a typed, weighted, in-memory hypergraph with a pattern-matching query and rewrite engine sitting on top. The unit of everything is the Atom. There are two kinds. A Node is a vertex with a type and a name: ConceptNode "cat", PredicateNode "loves". A Link is a typed, ordered tuple of other Atoms: EvaluationLink (PredicateNode "loves") (ConceptNode "Alice") (ConceptNode "Bob"). A Link is a hyperedge, which means it can connect any number of arguments rather than the two a normal edge allows.

Here is the move that matters. A Link's arguments are Atoms, and Links are Atoms, so a Link can take another Link as an argument. The edge can point at the edge. There is no special construction for it, no reification layer, no workaround. You build a Link whose first argument happens to be another Link, and you have said something about a statement. This is why the structure earns the name metagraph rather than merely hypergraph: a hypergraph lets an edge touch many vertices, but a metagraph puts vertices and edges in the same universe so that edges can touch edges. Both properties live in the same object.

The practical consequence is that the things you fight to bolt on elsewhere are ordinary here. A truth value attached to an assertion is just a Link whose argument is the assertion. A provenance record about a claim is a Link pointing at the claim. A rule that fires on a pattern of claims is itself a Link, addressable and rewritable like any other Atom. Programs are data in the literal sense: a MeTTa program, the language designed to run over the AtomSpace, is a subgraph of the metagraph, and it executes by querying and rewriting other subgraphs, including the ones that encode itself.

That is the design. Now the discipline this series holds to: separate what is implemented from what is intended. The metagraph substrate is real and runs. Atoms, Links, edges that point at edges, pattern matching, MeTTa programs represented as subgraphs, all of that exists and works. What remains research-grade is the part the marketing leans on hardest: the distributed AtomSpace running at production scale across many machines with real-time consistency, and the full cognitive architecture of probabilistic reasoning and attention allocation operating uniformly over the substrate. The public material on the distributed layer still reads as prototype and design intent rather than a battle-tested store you would put a customer workload on. So the AtomSpace gives you the correct model and asks you to accept research-grade operational maturity. For a knowledge platform that has to be up, that trade is usually the wrong way around.

Why Neo4j says no

Neo4j is the opposite trade. The labeled property graph model is stable, indexed, queryable, and deployed at trillion-relationship scale. It also structurally forbids the one thing the metagraph needs. A relationship in this model has a type, a start node, an end node, a direction, and a map of properties. The endpoints are nodes. They must be nodes. There is no relationship type whose start or end is itself a relationship, and there is no Cypher syntax for drawing an edge to an edge. You cannot write the pattern where a relationship targets another relationship, because the storage engine, the query planner, and the traversal model all assume a two-sorted world: nodes are one kind of thing, relationships are another, and a path always runs node, relationship, node.

You can put properties on a relationship. You can write since and weight and source as key-value pairs on a :LIKES edge. But a property is not a graph element. You cannot point another edge at a property, you cannot have a third claim reference it, you cannot run a rule that treats it as a first-class subject. The moment you need graph-level structure attached to a relationship, the property map runs out, and the model gives you nothing native to reach for.

The designers chose this deliberately, and it is what the performance costs. The two-sorted assumption is exactly what lets the planner reason about paths cheaply, what makes index-backed traversal fast, and what keeps the storage layout compact. Generalizing the model so relationships could be endpoints would mean redefining what a path is, reworking the type system, and rebuilding the traversal engine. As of the current standardization picture, neither Neo4j nor the emerging ISO standards have done it. GQL and SQL/PGQ, the property-graph query standards converging through 2024 to 2026, both inherit the same labeled-property-graph model: edges have properties, edges are not vertices, edges cannot be endpoints. The triple-store world has moved further. RDF-star, on track to land in RDF 1.2 and already implemented in GraphDB, AllegroGraph, and others, adds the quoted triple: a syntax for writing a statement and immediately making another statement about it. It is the closest mainstream answer to edges-of-edges, but it lives in the triple world, not the property-graph world, and it remains a draft until 1.2 ships. If you are building on a property graph, the standards do not rescue you. You build the bridge yourself.

Four models, one question

It clarifies the whole landscape to ask each major data model the same question: can an edge be the endpoint of another edge, and if not, what is the workaround. The answers sort cleanly into two camps, and knowing which camp your substrate is in tells you exactly how much work the metagraph will cost you.

The AtomSpace answers yes, natively. Both Nodes and Links are Atoms, they live in the same universe, and a Link can take a Link as an argument. There is nothing to work around because the model is a metagraph from the floor up. Classic RDF, the original triple model, answers no in the most painful way: a statement is not a first-class thing at all, so to say something about a triple you reify it with the rdf:Statement vocabulary, spelling out rdf:subject, rdf:predicate, and rdf:object across four or more triples per statement. It works, it is verbose to the point of hostility, and most stores treat the reification as ordinary data with no special optimization. RDF-star is the triple world's modern fix. It introduces the quoted triple, a syntax that lets you write a statement and embed it directly as the subject or object of another. Writing that the marriage of a man and a woman has a start date becomes a single annotated line rather than a four-triple reification block, and SPARQL-star extends the query language to match. RDF-star carries roughly the same expressive power as property-graph edge annotations, every property graph can be rendered as RDF-star, and stores like GraphDB and AllegroGraph already ship it with dedicated indexes. The caveat is maturity and world: it is a draft until RDF 1.2, and it lives in the triple ecosystem rather than the property-graph one.

The labeled property graph, the camp Neo4j and the GQL and SQL/PGQ standards all sit in, answers no and hands you the reification node as the workaround. An edge has identity and properties but is not a vertex, so to attach graph structure to a relationship you promote it to a node and point other edges at the node. This is the same move RDF made, arrived at from a different direction, and it is the move the rest of this essay builds on, because the property graph is what most production knowledge systems actually run on. The lesson across all four is that edges-of-edges is not a feature you can shop for in mainstream property-graph infrastructure. The AtomSpace has it and is not production-hardened. RDF-star has it and lives in a different world with draft-standard caveats. The property graph you will deploy on does not have it. So you reify.

The precondition nobody budgets for

Before any of the reification machinery means anything, the entities the claims are about have to be resolved to canonical nodes, and this is the step teams consistently underestimate. A Claim that says Geoffrey Hinton believes symbolic methods are necessary is only useful if the Hinton it points at is the same node every other claim about Hinton points at. The corpus will spell him as Geoffrey Hinton, Geoff Hinton, G. Hinton, the Godfather of Deep Learning, an at-handle, and a bare surname, and each surface form arrives with its own confidence that it refers to the canonical entity. Entity resolution is the process that collapses those forms onto one node before the claims attach to it.

Get this wrong and the failure is silent and corrosive. Two claims that genuinely contradict each other will not be detected as a contradiction if they hang off two different phantom Hintons, because the contradiction engine looks for conflicting claims about the same subject and these point at different subjects. The disagreement is real in the corpus and invisible in the graph. Worse, a meta-claim that disputes a claim about the wrong Hinton is provenance attached to nothing, an edge-of-edge pointing into a void. The whole value of the reified layer rests on the entity layer underneath it being solid, which is why resolution is not a preprocessing nicety you defer but a load-bearing part of the same build. The metagraph is only as reliable as the entities it resolves.

The bridge: reify the statement

The pattern that crosses the gap is reification, and it is old. You take the thing that cannot be an endpoint, the relationship, and you promote it to the thing that can, a node. A statement that wants to be talked about stops being an edge and becomes a Claim node that carries the subject, the predicate, and the object as its own connections. Once the statement is a node, every other edge in the graph can point at it, and the metagraph you needed exists inside the property graph you can run.

Concretely, you keep the fast direct edge for the common traversal and add the reified node only where you need to say something about the statement. Alice likes ice cream stays as (alice)-[:LIKES]->(ice) so the everyday query is one hop. Alongside it you create a Claim:

MERGE (alice:Entity {id: 'alice'})
MERGE (ice:Entity {id: 'ice_cream'})
MERGE (alice)-[rel:LIKES]->(ice)

CREATE (c:Claim {
  claimId: apoc.create.uuid(),
  subjectId: 'alice',
  predicate: 'LIKES',
  objectId: 'ice_cream',
  createdAt: datetime()
})
CREATE (alice)-[:CLAIM_SUBJECT]->(c)
CREATE (c)-[:CLAIM_OBJECT]->(ice)
CREATE (c)-[:CLAIM_EDGE]->(rel)

The predicate string on the Claim is deliberately redundant with the relationship type. It buys you the ability to query Claims directly by predicate without traversing into the entity layer, which matters once you have hundreds of millions of them. The :CLAIM_EDGE link back to the direct relationship is the seam that lets you jump between the fast graph and the fact layer without re-deriving one from the other. A note on the Cypher itself, because this is a domain where syntax gets misremembered: relationship types cannot be parameterized, so LIKES is a literal in the query text rather than a $predicate binding, and apoc.create.uuid() needs the APOC plugin or your own identifier strategy in its place. Both are easy to get subtly wrong from memory.

Now the payoff. A statement about that statement is just another node pointing at the Claim. A Controversy that disputes it:

MATCH (c:Claim {claimId: $claimId})
CREATE (contro:Claim {
  claimId: apoc.create.uuid(),
  predicate: 'IS_CONTROVERSIAL',
  createdAt: datetime(),
  annotationKind: 'CONTROVERSY'
})
CREATE (c)-[:CLAIM_SUBJECT]->(contro)
UNWIND $disputingClaimIds AS dcid
MATCH (d:Claim {claimId: dcid})
CREATE (d)-[:DISPUTES]->(c)

The meta-claim is itself a Claim, which means you can annotate the annotation, dispute the dispute, attach confidence to the controversy. The recursion the AtomSpace gives you for free, you have recovered, at the cost of a node and a hop per level.

What reification costs

The cost is real and you should price it before you commit. Every reified statement adds at least one hop. The direct traversal (s)-[:LIKES]->(o) becomes (s)-[:CLAIM_SUBJECT]->(c:Claim)-[:CLAIM_OBJECT]->(o), and every layer of meta-claim adds more. This is read amplification, and on a hot path it compounds fast. The discipline that keeps it manageable is to reify selectively. The direct edge with properties handles the ninety-five percent of queries that only ever need shallow metadata, the since and the weight that no other edge will ever reference. You pay for the Claim node only on the statements that genuinely need to be talked about: the ones with multiple sources, evolving confidence, temporal windows, or disputes pointing at them.

When you do reify, the Claim node becomes a central fact table and wants to be indexed like one. A uniqueness constraint on claimId, an index on predicate for the queries that scan by relationship type, and if you denormalize subjectId and objectId onto the Claim, a composite index across the three so you can look up a specific triple without traversing into the entity nodes at all. The denormalization trades write cost for read speed, which is the right trade when reads dominate, which for a knowledge platform they do.

The failure mode that bites at scale is the supernode. Reify many claims about one popular entity and that entity accumulates an enormous in-degree of :CLAIM_SUBJECT edges, and any query that scans all of them pays for the whole fan. The mitigations are structural. You can partition the claims under an entity into buckets by predicate or by time window, so a query about one predicate in one year touches a bucket rather than the entire history. You can flip the query direction and start from the Claim layer using its indexes, traversing out to the entity rather than fanning in from it. And at extreme scale you partition by domain or shard the graph. None of these are exotic; they are the standard shape of working with a hot node, and the reason you want to know the supernode is coming before you have a hundred million claims hanging off one ice-cream concept.

Three levels, cleanly separated

The architecture earns its keep when the layers stay distinct. There are three, and conflating them is where reified graphs turn into mud.

The first level is the object-level claim: a statement about domain entities. Alice likes ice cream. Vaswani introduced the Transformer. These are the ground graph, the facts the system is ultimately about. Each is a Claim node with its subject and object edges and, usually, a parallel direct relationship for fast traversal.

The second level is facts-about-facts: provenance, confidence, temporal validity, controversy. Every one of these is a node or a meta-claim pointing at an object-level Claim. Where this claim came from. How sure the system is. The window in which it held. Whether anything disputes it. The bi-temporal model from essay two lives here, as temporal-validity structures attached to claims rather than as properties buried on edges, which is what lets a claim carry several disjoint validity intervals instead of a single pair of timestamps.

The third level is rules-about-rules. A Rule is a node with an identity, a body that describes a pattern over claims, and a head that describes what to assert when the pattern matches. A rule that marks two high-confidence claims about the same subject as controversial when they disagree. Critically, because the rule's head produces a Claim, and that Claim carries the ruleId that created it, a second rule can reason about the first by querying the claims it generated. A throttle rule that watches how many controversies the first rule produced today and tightens its threshold when the volume spikes. That is a rule about a rule, and it falls out of the same pattern with no new machinery, because at every level the output is a Claim and a Claim is something you can point at.

One caveat about the rule layer that needs stating plainly. Neo4j has no native rule engine. The body and head are Cypher queries that your application stores, interprets, and runs. The graph holds the rule as data, and your engine is what fires it. This is a feature rather than a limitation, because it keeps the firing logic, the scheduling, and the partial-failure handling in code you control and can observe, while the graph keeps the audit trail of which rule produced which claim. But it means the word rule here describes a pattern you operate, not a declarative construct the database executes on its own. Conflating the two is the kind of thing that reads fine in a design doc and falls apart in production.

To make the three levels concrete, walk one disagreement through all of them. The body of a controversy rule looks for two high-confidence claims about the same subject and predicate whose objects differ:

MATCH (s:Entity)-[:CLAIM_SUBJECT]->(c1:Claim {predicate: $pred})
MATCH (s)-[:CLAIM_SUBJECT]->(c2:Claim {predicate: $pred})
WHERE c1.objectId <> c2.objectId
  AND c1.claimId < c2.claimId
  AND c1.value >= 0.8
  AND c2.value >= 0.8
RETURN c1, c2

The c1.claimId < c2.claimId guard is not decoration. Without it the same pair matches twice, once in each order, and you write two controversies for one disagreement. When the body returns a pair, the head asserts a controversy claim that references both, carrying the ruleId that produced it:

MATCH (c1:Claim {claimId: $c1Id})
MATCH (c2:Claim {claimId: $c2Id})
CREATE (contro:Claim {
  claimId: apoc.create.uuid(),
  predicate: 'IS_CONTROVERSIAL',
  createdAt: datetime(),
  ruleId: $ruleId
})
CREATE (c1)-[:CLAIM_SUBJECT]->(contro)
CREATE (contro)-[:CLAIM_OBJECT]->(c2)

The controversy is now a claim like any other, which is what makes the third level fall out for free. A throttle rule can ask how many controversies the first rule produced today and tighten its threshold when the volume runs hot:

MATCH (contro:Claim {predicate: 'IS_CONTROVERSIAL', ruleId: 'R1'})
WHERE contro.createdAt >= datetime().truncate('day')
WITH count(contro) AS n WHERE n > 100
MATCH (r1:Rule {ruleId: 'R1'})
SET r1.confidenceThreshold = 0.9

Read the chain top to bottom. An object-level claim says one thing. A second object-level claim says another. A rule notices the conflict and writes a fact about those two facts, a controversy. A second rule reads the controversies the first produced and adjusts the first rule's behavior. Object claim, fact-about-facts, rule-about-rules, each layer addressing the one beneath, all of it expressed in the same Claim and Rule vocabulary because at every level the thing produced is a node and a node is something the next layer can point at. The recursion the AtomSpace gave you in its type system, you have rebuilt in your schema, and unlike the AtomSpace version it runs on infrastructure that stays up under a customer's load.

What the agent sees

All of this machinery exists to serve a query, and the query comes from an agent that should not have to know any of it. The agent asks the world model a question. The response that comes back carries the object-level claims, their confidence values shaped by the facts-about-facts attached to them, and any controversies the question touched, all in one structured payload. The agent never traverses :CLAIM_SUBJECT edges by hand or reasons about reification. The bridge pattern is plumbing, and plumbing that leaks into the agent's mental model is plumbing built wrong.

This is the deepest reason to build the metagraph rather than flatten it. An agent querying a substrate that represents disagreement, provenance, and uncertainty as first-class structure produces calibrated output without being prompted to. It hedges where the graph is divided because the division is in the payload. It cites because the provenance is in the payload. The calibration of the answer comes out of the data model, and no amount of clever instruction layered on top will produce it. You get that by paying for the extra hop, indexing the Claim node, watching for the supernode, and keeping the three levels clean. The AtomSpace gives you the shape for free and asks you to run research-grade infrastructure. The property graph asks you to build the shape and gives you infrastructure that stays up. For anything a customer depends on, you build the bridge.

The next essay goes inside the confidence values the facts-about-facts layer carries. Not a single number per claim but a pair, strength and confidence, propagating through the graph the way evidence accumulates in a courtroom. Less structure, more epistemics. The PLN-lite truth-value system that makes the hedging real.

---

END OF ESSAY 04 · CONTINUE TO ESSAY 05 →