An approval granted before an action can authorize it. The same approval granted afterward tells a different story. A list containing both events is not enough to explain what happened.
That is an everyday reason to care about a fairly unusual database structure: a topological braid.
We are building 8DB for applications that need to retain more of the meaning in their data. Sometimes that meaning is a relationship. Sometimes it is geometry or uncertainty. Sometimes it is the way several histories interact.
What the braid keeps
A braid has strands and ordered crossings. In a data model, the application defines what those strands and crossings mean. They might represent interacting signals or participants in a sequence of handoffs.
Some changes in crossing order preserve the same braid under its mathematical rules. Others change it. That gives the application a way to distinguish meaningful differences from the specific reorderings its model treats as equivalent.
The mapping matters. A timestamp does not automatically establish causality, and a braid does not automatically establish that an action was valid. Domain rules still decide what the represented history means. Lamport's work on event ordering is useful background: causal order and a chosen total order are distinct concepts. Braids address a different modelling question: which sequences of crossings represent the same structure?
For a concrete algebraic example, take four strands. Crossing the first pair and then the last pair gives the same braid as doing those independent crossings in reverse order: σ₁σ₃ = σ₃σ₁. Crossing the first pair and then the middle pair is different: σ₁σ₂ ≠ σ₂σ₁. The native source tests exercise both cases. The figure lets you compare them with an everyday ordering rule; the workflow and algebra are separate examples.
Compare the histories · illustrative examples
Which reorderings should matter?
History A
- Approval is granted.
- The action occurs.
History B
- The action occurs.
- Approval is granted.
If the rule requires prior approval, only A has the required order. Both final logs contain approval and action. This is a fictional workflow rule, not a deployed authorization test.
Three useful applications
Compare interacting signals. 8DB's time-series work computes rank-braid signatures from stored signals. These describe the sequence in which signals cross in relative rank. The signature provides a different view from their individual values or averages, while retaining the connection to the source series.
Inspect custody and approval histories. An application can represent selected handoffs and interactions explicitly, then compare histories under a declared ordering contract. Bring two histories with the same participants and final state, but a difference that should matter. Also bring a reordering that should leave the interpretation unchanged. Together, those make a useful modelling test.
Record a permitted structural removal. Our erasure work uses a narrowly scoped operation on an isolated crossing and produces evidence of that change. Dependencies can prevent a clean removal. This is a separate question from whether a backup or exported copy still exists. Read what the certificate establishes.
The signal path is an implemented example. Custody and approval are application patterns that need their own domain mapping and acceptance tests.
Why put this in the database?
Tables, event logs and graphs can preserve ordered histories when they are modelled appropriately. A native braid representation gives the ordering structure its own types and operators within the same system as the source records.
That gives applications a shared representation and operators they can reuse, with the opportunity to reduce custom code for comparisons and connections to source evidence. A signal, a braid signature and an inspection report can remain connected while answering different questions. The integration still needs to be tested against the application's rules.
This is the larger idea behind 8DB's native modalities. The database can retain structures that an application would otherwise have to manage around it.
What is implemented
The implementation review for this update covers native braid encoding, strand operations, topology matching, projections and storage codecs. Reopen tests exercise specific representations under test authorization. The time-series rank-braid path computes signatures from stored signals.
Durable semantic-identity ingestion remains gated while its encoding profile is corrected. Query coverage is operator-specific. A screening fingerprint is not a collision-free identity, and a derived graph or vector view need not reconstruct the original braid.
Braid algebra also does not, by itself, confer post-quantum security. Data representations, cryptographic protocols and erasure guarantees have distinct contracts. See the encryption guide for the protection mechanisms described on this site.
Bring us a history that matters
The most useful starting point is a pair of histories that end alike but should produce different answers. Add the source events and the rules that determine which reorderings are harmless.
Send Ashley the example. We can use it to define the representation, the operation and the checks that would make the result useful to your team.
Implementation references: the time-series rank-braid encoder, its store adapter, braid identity policy and braid-conditioned channel tests at 8DB source revision d5d0f58e. This article reviews source behavior; it does not report a fresh database test run. The examples illustrate the scope of the native mechanisms and a practical way to evaluate them.
Evidence scope Native operators · Reviewed implementation scope · Application examples. Explore the evidence.