Pivot x SurrealDB: why we made the assertion the unit of analysis

SurrealDB has published a case study on how Pivot built its assertion graph for financial disclosure. This post explains what we built, why, and what the numbers measure.

The problem with summaries

In a financial remedy matter, each party discloses their assets and income on Form E, the sworn financial statement the court prescribes. The other side then tests that disclosure against the documents: bank statements, payslips, pension valuations and title registers.

A common approach with AI is to summarise the document bundle and load the summary into a language model's context. A summary is a new account of the material with no author behind it. It can drop material, and it can add material that is not there. Any answer built on it inherits those errors, and its citations point to the summary rather than the source.

Omissions are where this fails worst. A summary describes what the documents contain. Disclosure work is often about what they do not contain: the missing statement, or the account nobody mentioned. A summary cannot reliably show an absence.

So we stopped treating the document as the unit of analysis. In Pivot, the unit is the assertion.

What an assertion carries

An assertion is a single statement made by a single voice. Every assertion carries its provenance: who made it, which document it came from, which page, and the figure it states.

Take a simple case. A party declares a salary of £68,000 on Form E. Their payslips total £91,000. Pivot keeps both, each with its own voice, document and page. Nothing is averaged, overwritten or resolved by the system. The fee earner, the lawyer running the matter, sees both sources side by side and decides what the difference means.

Each assertion also carries two timestamps. One records when something was true in the world, such as a valuation date. The other records when it entered the record. This is called bitemporal storage, and it lets the record show exactly what was known on a given date.

Why one store matters

Holding this across three systems (a graph database, a vector store and a relational database) would have meant keeping them in step with application code. Every boundary between them is a place where they can disagree.

SurrealDB removed that problem. In SurrealDB, an edge (the link between two things in a graph) is a full record. The voice, source document, page, figure and both timestamps sit on the edge itself. One statement in SurrealQL, SurrealDB's query language, traverses the graph and reads the record.

Merging without rewriting. Each party's disclosure is held separately. When the lawyer decides to merge the two, ordinarily after Form E exchange, the merge creates same_as edges linking matching entities. Nothing is rewritten, so the pre-merge record stays auditable.

Isolation per matter. Table and field permissions are evaluated on every record, with access denied by default. Each matter is isolated inside the database engine itself.

Vector search in the same boundary. Vector search finds material by meaning rather than exact wording. In Pivot it runs inside the same engine as the graph, scoped to one matter's documents. There is no middleware holding the ontology together across stores, because there is only one store.

What the numbers measure

The case study reports results against one baseline: loading a full disclosure bundle into a model's context.

• 20 to 40 times lower token cost per query. Tokens are the units a language model is billed on. Pivot retrieves only the relevant part of the graph rather than the whole bundle.
• 0.27 seconds retrieval latency, against 3.4 seconds for bundle loading.
• Four entity states a fee earner can check. Every account, property or pension is Corroborated, Uncorroborated, Contradicted or Unasserted. Each state opens to the records behind it, and the fee earner works through them as a queue.
• One store for the graph and the vectors. States are computed at query time and never stored, so they cannot drift out of line with the evidence.

What comes next

Financial remedy has a shape that recurs across contested areas of law: several voices making attributed claims about the same things, tested against evidence. We are also exploring SurrealDB Agent Memory as the memory layer for each matter. Its versioned history would make the time field on every record checkable.

From the case study:

"An assertion edge carries the voice that made it, the document and page it came from, the figure it states and the dates it holds for. SurrealDB stores that as one record and queries it in one statement. We did not write middleware to hold the ontology together, because there is nothing to hold together."

Read the full case study on SurrealDB's website: Pivot x SurrealDB.