Cheap to write, careful to read

Tiramemsu articles · 13 October 2026 · companion to the paper Metagraph Encodings over Identified Triples

An identified triple is a row (e, s, p, o) whose id e can stand where a node stands in another row. With that one shape you can store a hyperedge, an edge between edges, a container that holds facts, and a confidence on the fact that something belongs to a container. Metagraphs from one row shape shows the recipes. The paper behind this article asks the question the recipes skip: once the rows are in, can you always get the structure back out?

The short answer is no. The useful answer is a precise list of what you have to check, and a proof that nothing on the list is optional.

Writing is one row per clause

Take a directed hypergraph: vertices, and edges that go from a set of vertices to a set of vertices. Encode each vertex and each edge as an anchor row that gives the atom a type. Then add one role row for each incidence:

(n_e, rdf:type, mg:Edge)     # the edge e exists
(n_e, mg:in,  n_a)           # a is an input of e
(n_e, mg:in,  n_b)           # b is an input of e
(n_e, mg:out, n_c)           # c is an output of e

That is all. The size is exact: one row per vertex, one per edge and one per endpoint. Higher-order metagraphs, where an edge's end can be another edge, use the same rows with a looser type on the object. Nested containers use member rows. Annotated presentations add attribute and annotation rows. Every encoding in the paper is one row per source clause. This is the sense in which statement identity is cheap.

Reading needs an exact image

A store is just a set of rows, and nothing stops a store from containing rows that no hypergraph would produce:

• an edge with outputs and no inputs;
• a role row whose subject is a vertex;
• an extra annotation the decoder does not know what to do with;
• two copies of the same role.

Decode such a store and you get something outside the source domain, or a different structure from the one you meant. Typing the rows does not help, because the problem is often not a row at all.

The paper separates a row language, which only says which shapes are allowed, from an exact image, which says which stores decode to a valid source. For directed hypergraphs the image is six conditions:

Higher-order metagraphs let role objects be edges too, and forbid an edge from naming itself. Basu–Blanning metagraphs add extensionality: no two edges may have the same inputs and the same outputs. That condition is about a group of rows, not a single row. Nested containers add well-foundedness, a condition about the whole member graph.

On an exact image, encoding and decoding are inverse up to renaming of ids. The paper is candid that this part is bookkeeping. The interesting part is that every condition is necessary. For each one there is a store that breaks only that condition, passes all the others, and does not decode to a valid source. A checker runs the validator with that one condition removed and confirms that the witness then slips through. So the list cannot be shortened, and a system that checks only row types is checking less than it needs to.

Tiramemsu does not enforce these images. It stores whatever rows you write. The paper's checkers, and its SHACL and SPARQL validators, show what an application or a validator should check before it decodes a store as a metagraph.

Time: an annotation can outlive what it is about

Give every component two clocks, as tiramemsu does. Classical temporal referential integrity requires a row's valid time to sit inside the valid time of everything it references. For structure that is right: an edge cannot be valid while one of its ends is not. For opinions it is wrong. "This 2020–2021 fact was disputed in 2025" is valid in 2025, outside its bearer's interval.

The paper gives two snapshot policies:

• Policy S (containment). Both clocks nest along references, and a snapshot is what is asserted at that moment.
• Policy R (retained referents). Only transaction time must nest. A snapshot is what is asserted plus everything it references, filtered by transaction time alone.

Under Policy R the dispute appears in the 2025 snapshot together with the fact it disputes. The fact's own stored interval tells a reader that it is context, not a 2025 claim. The snapshot theorem says that under either policy, taking a snapshot commutes with encoding: snapshot the store and decode, or decode and snapshot the source, and you get the same structure.

One family does not survive time. Extensionality is a property of each snapshot, not of any row. Two edges with equal ends, valid [0,5) and [3,8), are fine row by row, but the snapshot at 4 contains both. Practical systems should prefer the identified images, where two edges may share their ends.

Revisions need one more relation. When an edge's target is corrected, the new edge is a new atom. A supersedes row between the two, with lifetimes that are ordered and disjoint, makes versions a set of chains. Each chain has at most one live member at a time, and naming atoms by their chain lets you compare snapshots across time.

Reachable is not the same as executable

A metagraph often describes processes: an edge consumes its inputs and produces its outputs. A metapath from B to C is a set of edges that connects them. The usual definition asks only that every edge lie on a walk. But a process edge needs all its inputs before it can fire. Here is a two-edge example:

e1 : {b, a} → {d}
e2 : {d}    → {a, c}

Both edges lie on a walk from b to c, so this is a metapath. Neither edge can ever fire. e1 needs a, which only e2 makes, and e2 needs d, which only e1 makes.

The paper gives a linear-time check, forward chaining with a counter per edge, that decides whether a metapath is executable. It also proves when the two notions agree: when the dependency graph between edges is acyclic, or when every edge has exactly one input. A SPARQL property path follows walks, so it answers the weaker question.

What depth costs

The rank of a row is how deep its references go: a row that references nothing has rank 0, and a row that references a rank-k row has rank at least k+1. Rank pays for itself in two operations:

• Bulk loading. If no row may be inserted before the rows it references, a load needs exactly 1 + (maximum rank) batches.
• Retraction. A cascade from a row of rank r finishes within (maximum rank − r) rounds after the first.

Anchored encodings keep every structural row at rank 1, however deeply edges nest, so the structure loads in two batches. Annotations on structure add depth. A compact encoding that stores a binary edge as one triple makes rank equal endpoint depth instead. It is smaller, but it costs more batches when edges reference edges.

The paper's memory example shows why the distinction matters for agents. A confidence of 0.9 on the fact "Sarah announced a new job" has rank 1. A confidence of 0.7 that this fact belongs to a particular conversation has rank 2, because it sits on the membership row. These are two different claims, and identified triples keep them apart.

Evidence and limits

• Checkers. Exhaustive bounded enumeration and seeded randomized property tests check every roundtrip and every necessity witness.
• Validators. SHACL shapes and SPARQL queries express the image constraints and are tested for agreement with the Python validators.
• Lean. A Lean 4 proof covers the directed, higher-order and extensional roundtrips under canonical naming.

The paper reports no performance or retrieval results. It does not claim identified triples are a minimal universal primitive, or that these encodings beat relational or graph alternatives. The engine enforces none of the images.

Read the paper

Metagraph Encodings over Identified Triples: Exact Images, Temporal Integrity, and Structural Depth has the source signatures, all image constraints with their necessity witnesses, the temporal theorem, the metapath results and the rank consumers. It is a draft preprint under CC BY 4.0, archived on Zenodo.

Download the PDF About the paper DOI 10.5281/zenodo.23167938

The series in one page → · Next: what leaves the store →