Skip to content
8Braid / Defense & national security
8DB / Defense & national security

Keep control of mission data.
Out to the edge.

Bring protected storage, native search and governed exchange into the applications and devices your teams operate. 8DB gives defense developers a common data engine to evaluate under the connectivity, custody and recovery constraints of their mission.

Define a mission-data evaluation ↗Inspect the evidence
The operational problem

A network connection is an operating condition. Your data still needs rules.

A field application may need a maintenance record on a local device, an authorized copy at another site and a reliable account of what changed after reconnection. The difficult work sits between those states: who can read, which copy is current and what a restored device is allowed to recover.

The U.S. DoD’s OCONUS Cloud Strategy identifies disconnected and intermittent access, constrained power and sharing across mission partners as operating challenges.[1] Those constraints belong in the data-system evaluation from the start.

Why an embedded data engine

Put the protection beside the work.

Local operation

Bring the data closer.

Embed storage and search in the application. Define the data that must remain available locally and test the chosen devices within their memory, power and connectivity limits.

Protected exchange

Seal before the network carries it.

The reviewed node path establishes recipient-specific PQC protection at the sending endpoint. A relay carries the encrypted frame without its payload keys; the receiver protects its local copy under independent storage keys.

Connected information

Keep the context with the record.

Native documents, graphs and spatial structures provide a foundation for linking observations to assets, locations and sources. Application schemas and their protected exchange are qualified during integration.

The published Required node profile currently admits canonical lexical records. Mission-data schemas, disconnected authority behavior and device support are defined and tested for the application.[2]

Mission workflow / Evaluation vision

Turn a maintenance record into useful intelligence.
Keep its authority in view.

Follow one inspection report from a field device to a maintenance answer. The same workflow gives an integrator a concrete way to evaluate data utility, access control and recovery together.

  1. Capture the source

    Store the inspection report, the asset it concerns and the rules for who may read it on the field device.

  2. Share with the right team

    Deliver a protected copy to an authorized maintenance team, with an explicit plan for interrupted connectivity.

  3. Build the context

    Connect the report to parts, prior repairs and procedures. Retrieve the supporting information for an AI-assisted answer.

  4. Change permission

    Remove a reader’s access. Check the original, linked context and stored answer, including previously cached results.

  5. Interrupt the work

    Stop a write at a defined publication boundary. Observe which data and authority have become durable.

  6. Recover with control

    Reopen the application or restore a managed copy. Check exact data, current authority and the treatment of stale state.

These are acceptance objectives for a complete mission integration. Measure the engineering effort to implement the flow, the access and recovery tests it satisfies, and the evidence an assessor can inspect.

Explore the shared foundation →Inspect the component experiments →
An inspectable starting point

Start with the retained results. Extend the test to your mission.

The public two-host experiment retained all 512 exact typed records after a receiver-process interruption and same-store reopen.[3] The source-bound architecture record traces endpoint keys, message authentication and the enforced data boundary.[2]

The reviewed composition runs in software without a required HSM or cloud key-service call. Your deployment still specifies endpoint custody, trusted software and the assurance controls its mission requires.

Inspect two-host recovery ↗Follow the cryptographic path ↗Explore the wider evidence ↗
Standards and acceptance

Name the profile. Test the whole deployment.

The reviewed message path uses ML-KEM-1024 and ML-DSA-87, the Category 5 parameter sets selected by CNSA 2.0 for key establishment and signatures, alongside AES-256 payload encryption.[2][4]

From algorithm choices to deployment approval

Algorithm selection is one part of the assurance case. Formal algorithm/module validation, applicable NSA product requirements and mission authorization need their own evidence. The public ACVP results come from the demonstration service; they establish implementation evidence. The evaluation identifies the exact source, operating profile and remaining approval requirements before deployment.[4]

Sources / checked September 16, 2026

Follow the claims to their sources.

  1. U.S. DoD OCONUS Cloud Strategy, April 2021 ↗

    Operating constraints at the tactical edge, including intermittent connectivity, power and mission-partner information sharing.

  2. 8DB protected-node qualification, September 16, 2026 ↗

    Inspected implementation, lexical admission boundary, endpoint custody and current qualification scope.

  3. 8DB retained two-host recovery experiment ↗

    The 512-record process-interruption result and its original conditions.

  4. NSA CNSA 2.0 FAQ, December 2024 version 2.1 ↗

    Algorithm choices and implementation-validation requirements. Consult current program guidance for the intended deployment.