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

The assessment does not start with a scan. It starts with a question about the boundary: what is inside it, what talks to what, and who can prove any of it. Every component adds a page to the diagram, a set of interfaces to describe, a control to inherit or implement, and a place for a finding to land. The programmes that get through quickly are the ones with the shortest honest answer.

For a fielded data layer the honest answer has usually been long. A relational store, a document store, a search index, a queue for the disconnected periods, a key service the platform cannot reach from the field, a backup tool with its own catalogue, and a folder of scripts nobody wants to inherit. Six or seven components, a dozen interfaces, and a cryptography story that changes depending on which component you ask.

8DB is one component. Persistence, governance, protected transfer, recovery and diagnostics in a single qualified runtime, with a CPU, memory and disk budget that goes into the integration plan rather than being discovered on the platform.¹ Here is what that puts in the binder.

What is inside the boundary?

One runtime. Tables, documents, relationships, vectors, time series and spatial data are projections over one store of sealed atoms, so telemetry, imagery, maintenance records and the relationships between them live in one place with one protection model and one governance model.² There is one sealing path to describe, one access model to map to the control set, and one interface family on the diagram. The diagram fits on a page, and every line on it is the same protocol.

That is not tidiness for its own sake. Every seam between two components is a credential with standing rights on both sides, a synchronisation job someone owns, a place where two inventories can disagree, and an object an adversary can take. Removing the seams removes the pages of the binder that are hardest to defend.

Where are the keys, and what does a captured platform yield?

Nowhere, and ciphertext.

Every record is sealed at write under a key established by ML-KEM-1024 in a hybrid with X25519 and derived at use from a root secret and the record's governance state at the time it was written. Data keys are never stored, wrapped or exported. There is no key table on the platform, no key service the platform must reach, and no hardware security module required, so the same protection runs on a vehicle, a forward kit or an enclave with nothing but its own processor.³ Where hardware custody exists it is used; where it does not, the software-only assurances are documented on their own terms.

A captured unit yields records it cannot open and no table of keys to open them with. Batch integrity is one ML-DSA-87 signature over a SHA-384 Merkle root with a per-record inclusion proof, so a record's integrity can be checked by a party who does not hold the database.⁴

What may it do when it cannot reach anything?

Exactly what its written authorisation says, and nothing more.

Capture, read, export and administration are separately scoped permissions. Offline authorisations are signed and bounded: a platform carries a grant with an expiry, not a standing assumption. A clock that has moved backwards is refused, and uncertain time narrows what the platform may do rather than widening it. When the platform reconnects, current policy is applied before any restricted record is released or accepted, and a device that was revoked while it was away comes back to a quarantine state with a named remediation path, not to its old privileges.⁵

Capture continues throughout. The store acknowledges ingestion only when the defined durability requirement is met, keeps an encrypted delivery queue that survives restarts, retries on reconnection with stable record identities so nothing is applied twice, and retains every record until the destination confirms durable receipt. Backlog, oldest undelivered record, remaining capacity and the overflow rule are all readable by the operator, so a full store is a decision rather than a surprise. The promise is the one that can be tested: no silent loss of an acknowledged record within the tested failure model, through a twenty-four-hour disconnection, process termination at delivery boundaries, and duplicated or reordered transmissions.⁶

What happens when a person or a platform is revoked?

The ciphertext changes what it yields.

Clearance and policy are inputs to key derivation, not a filter in front of plaintext. A revoked reader does not lose an entry in an access list somewhere; the keys that reader could derive are the keys of a governance state that no longer exists. The same rule governs the copies. A backup taken while the reader was authorised, restored into a store that has since revoked them, gives the reader nothing and gives the current reader everything. Unknown or stale policy on the restored copy follows the declared quarantine rule, and a policy change during the restore is handled rather than raced.⁷

This is the question that most often produces a finding, because in a conventional stack a restore is where retired permissions come back to life. Here it is where they are checked.

What happens when the algorithm changes?

It changes on the store, on schedule, while the platform keeps working.

The algorithm is a property of every record. The version travels on the page, in the index entry, in the snapshot and in the replica, so "which records still depend on the profile we are retiring" is a query. Changing the profile is an operation the engine runs: it reads under the retired version, writes under the active one, keeps serving reads, reports completion per record and lists the exceptions. It refuses to declare the migration complete while any registered copy still carries the old profile, because a migration that forgets the copies is the migration that gets harvested. The store reports its own cryptographic posture per dataset and exports it as a CycloneDX 1.6 bill of materials the assessor can read without asking an engineer.⁸

The schedule that matters is already published. NSA's CNSA 2.0 transition requires new national security system acquisitions to be compliant from 1 January 2027 and the roadmap to be exclusively CNSA 2.0 by 2033, with 2035 the outer date for the longest-lived equipment, and NIST deprecates the classical public-key algorithms in 2030 and disallows them in 2035.⁹ Records written to a platform today will still be on it when every one of those dates passes. The transition is a state change here, not a second programme.

What happens when it fails?

It refuses the unsafe write and keeps everything it already promised.

Encryption contexts are reserved durably and allocated from one shared atomic cursor. When a context would be exhausted the store refuses the write rather than reusing a value, and every record already committed stays readable through a reopened handle. The tests cover byte tampering, transplanting a record's identity onto another, concurrent allocation under contention, reopening after close, and termination of the process mid-operation.¹⁰ Warnings arrive before the boundary, context renewal is a safe operation, and backpressure is defined so that capture degrades in a documented way instead of an undocumented one.

Recovery is a kit and a runbook, not a specialist. The independent authority, the root material and the revision anchor are provisioned and retained as part of deployment, with the retention arrangements written down. Recovery packages are encrypted. Replacing a lost device follows a tested procedure. Administration can pass to a successor, not only the original creator. Stale, incomplete or mismatched recovery material is detected before anything is changed. Start from the loss of the original device and the live database, recover with only the supplied materials and the runbook, and a revoked identity is still denied at the end.¹¹

How do I know any of this is true?

Because none of it depends on trusting us.

The evaluator bundle is a pinned, source-free artifact with frozen baselines and public known-answer vectors. It runs on an isolated host under the evaluator's control and returns PASS, FAIL or INCONCLUSIVE for four bounded claims, where a missing vector is INCONCLUSIVE, never PASS.¹² The release harness reproduces the per-record cost across four hosts, two operating systems and two architectures with the same bytes. The ML-KEM-1024 and ML-DSA-87 implementations interoperate with OpenSSL 3.5 in both directions, with negative controls that flip a bit and watch the verification fail. Every number on this site carries the harness that made it, and the tests behind every sentence in this article are named in the technical appendix that accompanies it.¹³

We do not grant authorisations. Nobody outside the programme does. What we do is make the authorisation shorter: fewer components to describe, controls that inherit from one runtime, and an artifact already on the shelf for each question above.

What the platform gets back

Security that reduces the binder is worth having. Security that also makes the platform more useful is worth fielding.

Because telemetry, equipment relationships and event history live as one sealed store, a maintenance finding traces to the observations that produced it, the equipment they came from, the transformations applied, the snapshot and the policy version in force, and whether any expected input was missing. A maintainer sees why the alert fired. A reviewer reproduces the finding from its retained snapshot, and a proof that no longer matches its record is rejected rather than explained away.¹⁴ Cryptographic provenance proves that relationship and that integrity. It does not claim the sensor was right, and neither do we.

If you own a boundary

Write to hello@8braid.com with the subject line "Binder". Send the boundary diagram as it stands, with component names removed if you prefer. We will return the same diagram with one component where the data layer was, the artifact list for each of the seven questions above, and the acceptance tests that turn each artifact into evidence on your hardware. The reply will be an engineer, not a deck.

Sources and further reading

• NSA CNSA 2.0 Cybersecurity Advisory ↗, and the accompanying CNSA 2.0 FAQ for the acquisition and exclusive-use dates
• NIST IR 8547: Transition to Post-Quantum Cryptography Standards ↗
• NIST SP 800-207: Zero Trust Architecture ↗
• NIST SP 800-53 Rev. 5: Security and Privacy Controls ↗
• NIST CSWP 39-upd1: Considerations for Achieving Crypto Agility ↗, sections 4.4 to 4.6 on embedded and operational technology
• 8DB: Four Claims, One Pinned Artifact
• 8DB: One Sealed Store for Every Shape of Data, and It Works With the Network Gone
• 8DB: Before a Fleet Trusts the Model, It Has to Trust the Data Under It
• 8DB: Category 5 Keys in Software, on the Hardware You Already Have
• 8DB: Your Post-Quantum Migration Has 21 Questions

Footnotes

1. The deployment profile: persistence, governance, protected transfer, recovery and diagnostics in one qualified runtime; prebuilt signed packages for the prioritised operating system and processor pairs; budgets for CPU, memory, disk and background maintenance; hardware-acceleration detection with tested fallbacks; an offline self-check and support bundle that contains no secrets and no customer payloads; upgrades that check data-format compatibility before they proceed. Evidence page: the deployment profile. ↩

2. Replace Six Databases With One Sealed Store and Stop Buying a Database Per Noun describe the atom store and its projections, with the evaluation package that checks byte-correct results across shapes from one store. ↩

3. Category 5 Keys in Software, on the Hardware You Already Have, No HSM Required. Key establishment is ML-KEM-1024 in a hybrid with X25519; derivation takes the root secret and the record's governance state at write time. Release builds on four hosts, Windows on a Ryzen 7 7800X3D (2026-07-19), Linux x86_64 on a Xeon (2026-09-11), Windows on a Ryzen 9 9950X3D (2026-09-11, host not quiesced) and Linux aarch64 on a Graviton3 (2026-09-12, host not quiesced): a 115-byte record encrypts to 131 bytes whether its key came from a classical derivation or from ML-KEM, with median per-record times within one percent, 200 operations per arm after warm-up. The post-quantum cost is one 1,616-byte object per established key. ↩

4. The Category 5 Bill Is Paid Once or Paid Per Record. One 4,627-byte ML-DSA-87 signature per batch; on the 100,000-record, 115-byte fixture in the release-build harness, batch-signed integrity added 0.054 percent to encrypted storage on all four hosts. The governed per-write-key profile is measured in its own harness and does not inherit these figures. ↩

5. Offline authorisation: separately scoped capture, read, export and administration permissions; signed, bounded grants; refusal of backward clock movement and narrowing under uncertain time; reconnection applies current policy before release or acceptance of restricted data; named quarantine and remediation states. The acceptance test revokes a device while it is disconnected, manipulates its clock, restarts it and reconnects it, and checks that the documented offline limits held and that old authority was not restored. Evidence page: offline authorisation. The design follows the resource-focused principles of NIST SP 800-207; it is not a zero-trust certification, which does not exist. ↩

6. Protected store-and-forward: durability-gated acknowledgement, an encrypted restart-safe queue, idempotent acceptance on stable record identities, retention until durable receipt is confirmed, readable backlog and capacity, explicit overflow. The acceptance test captures through a twenty-four-hour disconnection with process termination at delivery boundaries and duplicated and reordered transmissions, then reconciles every acknowledged record. Evidence page: disconnected capture and delivery. ↩

7. Governance in key derivation: Make Prompt Injection Harmless to Your Data. Recovery under current authority: trustdb PR #3484, merged to main 2026-09-12, enforces current authority through native data migration and managed recovery with retained-copy accounting; evidence folders protection-lifecycle-2026-09-11, managed-restore-source-2026-09-12 and combined-lifecycle-qualified-2026-09-12 under the public evidence tree. ↩

8. The Database That Reports Its Own Cryptography, Per Dataset, On Demand. Posture exports for managed inventory and managed restore, parent and child stores, in CycloneDX 1.6 with schema validation, are under combined-lifecycle-qualified-2026-09-12 and inventory-parts-qualified-2026-09-12 in the evidence tree. The profile change under live reads, with per-record completion and retained-copy refusal, is described in Your Post-Quantum Migration Has 21 Questions, note 6, with its evidence page. ↩

9. NSA, Commercial National Security Algorithm Suite 2.0 and its FAQ, for the transition schedule; NIST IR 8547 for the 2030 deprecation and 2035 disallowance. CNSA 2.0 is an algorithm suite built on NIST standards, not a certification. 8DB's stored-data profile uses the suite's Category 5 algorithms, ML-KEM-1024, ML-DSA-87, AES-256 and SHA-384; a CAVP algorithm certificate from an accredited laboratory and, for a module, CMVP validation are what a laboratory adds, and CAVP testing for the ML-KEM-1024 and ML-DSA-87 implementations is in procurement. ↩

10. Exhaustion safety: durable context reservation, a shared atomic allocation cursor, refusal on exhaustion, preservation of committed records through a reopened handle. Native tests cover byte tampering, identity transplantation, concurrent allocation, reopen and process termination. Warnings before the boundary, safe renewal, backpressure behaviour and measured recovery time are on the same evidence page, with power-loss durability tested separately from process death. ↩

11. Turnkey recovery: provisioning and retention of the independent authority, root material and revision anchor; encrypted recovery packages; the replacement-device procedure; administrator succession; detection of stale, incomplete or mismatched material before any change. The acceptance test begins from loss of the original device and the live database and ends with a recovered store in which a revoked identity is still denied. Evidence page: recovery kit and runbook. ↩

12. Four Claims, One Pinned Artifact. ↩

13. Every Number on This Site Comes With the Harness That Made It. Interoperation with OpenSSL 3.5: 15 of 15 checks on x86_64 Windows against OpenSSL 3.5.7 (2026-09-11) and 15 of 15 on aarch64 Linux against OpenSSL 3.5.8 (2026-09-12), negative controls included; evidence sets with SHA256SUMS under interop in the evidence tree. Known-answer tests 35 of 35; NIST ACVP demonstration server session 744723, June 2026, which is algorithm-correctness evidence and not a certificate. ↩

14. Provenance-rich results: Show Your Work: Provenance as a Query and Before a Fleet Trusts the Model. The acceptance test reproduces a finding from its retained snapshot, alters one contributing record and rejects the proof, and removes an expected input and reports incompleteness. Evidence page: provenance-rich queries. ↩

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