Skip to content
8BraidCreators of
8DB
Journal→Fielded Systems

Engineering note · Tested claims · Evaluator harnesses · Explicit non-claims

One Sealed Store for Every Shape of Data, and It Works With the Network Gone

Edge nodes hold telemetry, geospatial data, imagery, relationships and time series, usually in five engines with five governance models and no connection to the services that were supposed to protect them. 8DB holds all of it in one sealed store, survives power loss, works with no reach-back, and moves sealed intelligence between nodes when a link appears. Each of those is a tested claim an independent evaluator can run on an isolated host.

Published
Reading time6 minutes
DDIL data storeTactical edge databaseMulti-modal databaseEmbedded encrypted databaseOffline database encryptionSealed data transferPost-quantum databaseEdge computing data at rest

The reference architecture for a modern data platform assumes the network is there. Keys come from a key service, identity from an identity provider, each data shape from the engine built for it, and governance from a policy layer that reaches all of them. Remove the network and every one of those assumptions fails at once. The node still has to ingest, store, query and protect data, and when the link comes back it has to share what it learned without exposing it to whoever is listening.

This article is for the system engineers, security architects and integrators who build for that environment: platforms, sensors, forward sites and vehicles that operate disconnected, intermittent and low-bandwidth by design or by adversary. It describes the four properties a data substrate needs there and what 8DB has demonstrated for each to an independent evaluator.

Four things the edge needs from its data store

  1. One sealed store for every shape of data, so fusion does not mean five engines and five governance models on a box with one power budget.
  2. Protection that does not need a network, so keys, identity and policy work when reach-back is gone, and a captured unit yields ciphertext.
  3. Survival of the ordinary failures, power loss above all, without corrupting committed data or leaking plaintext during recovery.
  4. A way to share sealed intelligence between nodes that does not depend on the transport being trustworthy and does not reopen the data to move it.

One store, many shapes

8DB is a single content-addressed atom substrate with an index over it, not a collection of engines behind a facade. On the tested store and write path it persists key-value records, batches, blobs, labelled records, vectors with nearest-neighbour behaviour, spatial operations, dynamic time warping, directed edges and n-ary hyperedges, and returns byte-correct results for each.1 Because there is one protection path, the picture a node fuses from telemetry, geospatial data, imagery references, relationships and time series has one governance model, not the weakest of several.

Protection with no network

Persisted content is sealed as it is written with AES-256-GCM-SIV, and the evaluator scans raw storage for known plaintext markers to confirm they are absent. Per-page keys are derived on demand from a root trust anchor and the record's governance state, and are not persisted in exportable form, so a captured device gives up ciphertext and no key table. The store cannot yield plaintext at rest through any default API path; a store the shipped bindings can construct is always sealed.

Labels, clearances and policy epochs are inputs to that key derivation, so access control is enforced by decryption outcome rather than by a check in front of plaintext, and the evaluator exercises it with the network disabled. The engine is embeddable and runs in process, with no external key management or identity service required by the core tested operations.2

Survival of failure

The harness includes simulated crash and power-loss behaviour over committed data and sealed persistent indexes, and acceptance requires committed data to recover with no plaintext exposed during recovery. In the package's own record, 64 of 64 crash and power-loss trials recovered with zero corruption and zero plaintext leak. This is the unglamorous property that fielded systems fail on most often, and it is a formal claim precisely because it can be tested in an evaluator's isolated environment.

Sealed exchange between nodes

When a link appears, nodes need to share what they hold without decrypting it to do so. 8DB's tested transfer primitive uses ML-KEM-1024 and ML-DSA-87 operations, protects the channel with a hybrid key exchange, and rejects the included tamper, wrong-key, man-in-the-middle and replay cases through an engine-enforced anti-replay window. The payload carries already-sealed at-rest ciphertext between two stores without exposing application plaintext, so the transport is defence in depth and not the security boundary. That matters when the link is a radio, a removable medium or a courier.3

Where the evidence comes from

Every property above maps to a formal claim in our independent evaluation package, with named harnesses, frozen baselines and PASS, FAIL and INCONCLUSIVE rules an evaluator applies on an isolated host without our source code. The cryptographic algorithms are corroborated by a NIST demonstration-server result and an offline known-answer suite.4 The full shape of the package is described in what an independent evaluator should be able to run.

What to bring us

  • One node profile. Processor, memory and storage envelope, the data shapes it holds and at what rates, and the retention horizon. We will return an acceptance plan that names which tested claims apply and what deployment tests remain yours.
  • One connectivity pattern. Outage durations, link types and the backlog you need to hold. The sealed-transfer primitive and the protected store-and-forward path are tested; the run on your transport is the integration test we will help you design.
  • Your target hardware. The evaluator bundle and the known-answer suite are meant to run where you will deploy, not on our laptops.5

Write to hello@8braid.com with the subject "Edge data substrate: node profile". You will hear back from an engineer.

Sources and further reading

Footnotes

  1. The tested claim is bounded to the shapes listed, which are the ones the evaluator harness covers. Additional research modalities exist in the engine and are not formal claims until evaluator-visible tests exist for them. We do not claim every modality without trade-offs, and we attach no performance or competitive thresholds to this claim. ↩

  2. The non-claims are explicit: a root trust anchor still has to be provisioned and protected, entropy and custody are the deployment's responsibility, and none of this is a CMVP module validation. ↩

  3. The claim stops at the primitive. It is not a validation of any production transport, mesh, MQTT, TLS, radio or satellite path, and it makes no end-to-end claim about routing, availability, congestion or packet loss under DDIL conditions. Those are integration tests a program runs on its selected transport, and we would rather say so than let a primitive's pass be read as a network's. ↩

  4. We describe the NIST demonstration-server result and the offline known-answer suite as algorithm-correctness evidence and never as a certificate. ↩

  5. The aarch64 Linux build is CI-gated and runs natively: the release harness, the 35-vector known-answer suite and the OpenSSL 3.5.8 interoperation set ran on an AWS Graviton3 self-hosted runner on 2026-09-12, with logs and SHA256SUMS in the public evidence tree. The run on your board is the first item in the acceptance plan. ↩

Continue the technical conversation

Where could this help your work?

Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.

Discuss this work

Continue reading

The next layer of the argument.

Engineering note

Fielded Systems

One Component in the Boundary, No Keys in the Field, and an Artifact for Every Question the Assessor Will Ask

A data layer for platforms that operate cut off, keep records longer than the algorithms that protect them, and have to be assessed on what can be shown. 8DB puts persistence, governance, protected transfer, recovery and diagnostics in one qualified runtime, leaves no key table on the platform, and answers each of the seven questions an assessor asks with an artifact that already exists. Here is what goes in the binder, question by question.

14 min readTested claims · An evidence page per question · Four-host release harnessRead article ↗
Engineering note

Fielded Systems

Before a Fleet Trusts the Model, It Has to Trust the Data Under It

Predictive maintenance for a fleet lives or dies on whether a maintainer believes the alert, and that belief rests on the data layer, the part nobody designed. 8DB gives a sustainment program a substrate in which telemetry, subsystem relationships and events are captured on the platform, sealed at write, kept from leaving where they may not go, attributable to their source, and provable to a reviewer months later, with every one of those guarantees tested under independent evaluation.

7 min readTested claims · Deployment boundaries stated · Model layer excludedRead article ↗
Engineering note

Post-Quantum Databases

The Next RFP Question Is About Your Stored Records. Build the Answer, or Embed It

Every product that stores sensitive data for years will be asked the same question by federal, defence and regulated buyers: when an algorithm retires, how do the records already written move, and how do we prove it? 8DB is an embedded engine that makes the answer a property of your product instead of a project for each customer. Your interface, your customer relationship, our substrate doing the cryptographic, governance and provenance work you would otherwise have to build.

9 min readMeasured components · Embedded engine · Two 8Braid products built on itRead article ↗