Define what matters.
Supply the scientific model, candidate scores, benefit and cost directions, dependencies and the decision you need to make.
8DB architecture / A technical reference
Reuse the algorithms behind your next data feature.
8DB gives applications reusable machinery for comparing alternatives, working with uncertain observations and protecting connected data. Your domain supplies the meaning. Native operations do more of the work behind the answer.
In BraidEra BioTwin, a drug discovery and development platform built on 8DB, 8DB's lattice operator retains candidates worth considering across six decision criteria. BioTwin supplies the scores and directions; the reusable comparison machinery comes from 8DB.
01 / What your application inherits
Keep domain meaning.
Reuse the machinery.
A graph, a bounded observation and a set of competing candidates need different operations. 8DB provides native representations and reusable mathematical structures that applications can compose around their own questions.
Connect meaning to operations.
Map observations or candidates into the appropriate types. Register dependencies and arrange the required updates.
Reuse operations and supported storage paths.
Call ordering, interval, graph and other native operations. Use the persistence, indexing and protection supported by the selected path.
Responsibility map for the examples below. Each integration has its own execution and lifecycle boundary.
Connected representations can share an entity's identity while using specialized indexes and physical layouts. The practical value is in the operations they support and the coordination the engine handles. The model references describe those operations individually. Compare with database extensions and other multimodel systems →
02 / One reusable operation, a useful decision
Keep the candidates you still have a reason to choose.
A candidate can be cheaper while another offers greater benefit. Choosing one blended score too early can hide that tradeoff. An explicit partial ordering keeps alternatives that remain worth considering: a candidate is dominated only when another is at least as good on every criterion and better on at least one.
| Candidate | Benefit ↑ | Cost ↓ | Result |
|---|---|---|---|
| A | 8 | 5 | Retain. More benefit than B. |
| B | 6 | 3 | Retain. Lower cost than A. |
| C | 5 | 6 | Dominated. A and B each improve both criteria. |
The useful answer is A and B. The application can now ask what evidence or preference would settle the remaining choice.
BioTwin defines six criteria→
SolutionOrder→lattice::ops::maximal→Non-dominated candidatesThe inspected BioTwin integration follows that call chain in typed Rust. The domain defines its scores and what “better” means; 8DB supplies the reusable frontier operation. The small table above explains the rule using invented values. It is separate from an executed BioTwin or engine test.
Technical detail: the inspected integration uses fixed-point score inputs. Rounding and missing-value conversion affect the ordering, so the input policy belongs in a deployment evaluation. See finding D03 in the dated implementation summary.
The same foundations support different meanings.
The time-series integration maps point readings, bounded values, below-detection observations and absence into typed interval and lattice operations. Its adapters preserve those distinctions when computing stored summaries. A measurement known only to lie within a range can stay a range as the application reasons about it. Follow the time-series operations and update paths →
Partial orders and Pareto frontiers are established mathematics. The 8DB contribution illustrated here is reusable native implementation with concrete consumers. For a builder, the question is how much of the next feature is already supplied by the database. Read more about building on the reusable core →
03 / The answer can stay the same while its support changes
A new justification can change what needs checking next.
Imagine a scientific result retains the same value after its supporting source changes. Comparing result values alone would miss the change in its foundation.
BioTwin maintains separate content and lineage fingerprints. Its scientific-lineage consumer registers dependencies, marks affected work stale and prepares a dependency-ordered rerun queue. That gives the application a concrete starting point for review, even when the answer's value has stayed the same.
The domain application owns dependency registration and acting on that queue. Multi-process publication and complete recovered-history coverage require separate qualification. Inspect the lineage example →
04 / Follow the exact execution path
From an operator to a running system.
How are the operations composed?
The BioTwin frontier example calls shared operators in Rust. The published graph, spatial and time-series shipping query also uses typed Rust composition. These examples establish those execution paths. SQL planner integration, costing and index selection need evidence for the particular query interface under evaluation.
Inspect the shipping-query methodology →What commits together?
In the separately reviewed protected indexed-record path, source changes and lexical-index changes share a write transaction. The read path checks source/index correspondence. That gives a specific integration contract to inspect; other model combinations need their own transaction boundary.
Read the indexed-record example →What keeps derived data current?
Time-series rollup cells have an explicit rebuild path. Writing a new raw observation does not by itself refresh every rollup. The application must use the relevant maintenance and late-data repair path. Historical interpretation also needs the cadence and deployment context associated with the observations.
Inspect update and version semantics →Where does protection apply?
The published protected-node profile combines recipient-protected exchange with local resealing at the receiving store. Payload protection remains attached to the recipient boundary through forwarding intermediaries. Its cryptographic, record and recovery evidence identifies the tested profile and build.
Follow the protection boundary →05 / Inspect, then evaluate
Take the shortest route from claim to evidence.
This reference brings existing evidence together. The BioTwin examples draw on the September 23–24 source review at revision 7a3654189fb29a1ddf26843575ee9749ab5c7243. They retain that source-inspection status. The public qualification reports cover their separately named builds and executed fixtures.
Inspect the implementation findings.
The public summary names the consumer, source revision, finding and evaluation scope for each example.
Read the dated source-review summary →Inspect retained tests and verifiers.
The public evidence repository provides reports and verification instructions. Its qualification status explains what each build and test establishes.
Open the public qualification map →Understand the scientific application.
BraidEra BioTwin applies the foundation to drug discovery and development. Its foundation guide follows scientific questions, dependencies and competing candidates.
Explore BioTwin's foundation →Run a relevant engine evaluation.
Public verifier replay and a fresh engine run answer different questions. For a fresh run, agree on the evaluation build, platform, binding, inputs, expected outputs and recovery checks.
Plan an evaluation →Editorial review: September 25, 2026. Underlying evidence dates remain attached to their sources. Open the full evidence library.
One useful next step
Which part of your application are you rebuilding around the database?
Bring one operation and the result it must produce. We can map what 8DB supplies, what your domain retains and the evidence that would make the choice clear.
Explore an evaluation ↗