A predictive sustainment program produces one artifact that matters: a warning a maintainer acts on before the failure. Everything else is in service of that moment. The model that raises the warning gets most of the attention, and it deserves scrutiny. But the maintainer's trust does not rest on the model alone. It rests on whether the signals behind the warning were really captured from that platform, were not altered on the way, can be shown to a reviewer later, and never left the boundary they were allowed in. Those are properties of the data layer, and in most fleet architectures the data layer is the part nobody designed.
This article is for the people who own fleet sustainment and platform telemetry programs, the engineers who integrate sensors, models and maintenance workflows, and the assessors who will ask how a fielded system protects and attributes the data it collects. It sets out what the substrate under predictive sustainment has to guarantee, and what 8DB has demonstrated for each guarantee under independent evaluation.1
What the maintainer is actually trusting
Take a warning apart. It says a subsystem is trending to failure, names the signals that drove the conclusion, and points to a procedure. For a maintainer to act, five things have to be true about the data underneath.
- The telemetry was captured on the platform, continuously, across subsystems, not sampled after the fact from whichever bus was reachable.
- The relationships were captured with it: which subsystem feeds which, which events preceded which, so the warning can name a cause rather than a symptom.
- The data was protected from the moment it was written, on a platform that may be captured, and it did not leave the platform except where policy allowed.
- Each datum can be attributed to its source and shown to be unaltered, to a reviewer who does not run the system, months later.
- All of this kept working when the platform had no connectivity, which for a vehicle is most of the time.
One record, several shapes, sealed at write
Telemetry is time series. The vehicle is a graph of subsystems. Faults and maintenance actions are events. Manuals and procedures are documents. In the usual stack these are four stores, and the correlation that makes a warning explainable happens in application code that has to reach all four. 8DB holds them in one sealed store on one protection path: key-value and labelled records, blobs, dynamic time warping for signal comparison, spatial operations, directed edges and n-ary hyperedges for the subsystem graph. The tested claim is that in one store and write path these shapes persist, return byte-correct results, are sealed so known plaintext markers are absent from raw storage, and recover after a simulated crash.2 On a vehicle, that last property is not a corner case; it is Tuesday.
No egress means no egress
Sustainment data about a military platform is sensitive whether or not anyone has classified it: it reveals readiness, usage and weakness. A program needs to say that certain telemetry does not leave the vehicle, or leaves only to a named destination, and needs that to be true rather than configured. In 8DB, governance state is an input to key derivation, so a record can be labelled such that a reader outside its policy fails to derive the key and gets ciphertext. The tested claim is that label and clearance boundaries and policy or epoch changes are enforced through decryption outcomes, with core operations executable while the network is disabled. A captured platform yields sealed data and no key table, because per-record keys are derived on demand and are not persisted in exportable form.
Provenance a reviewer can check
When a warning turns out to be right, someone will ask what the model saw. When it turns out to be wrong, someone will ask harder. Either way, the answer has to be more than a log. In 8DB every record is content-addressed and attributable, and a dataset is authenticated by one ML-DSA-87 signature over a SHA-384 Merkle root with a logarithmic inclusion proof per record. A reviewer can be handed the signals behind one warning, their proofs and the signed root, and verify that those signals were part of the authenticated dataset, without the rest of the data and without trusting the operator. Tampering is rejected through an independent verifier path. The signature is paid once per batch, not once per sample, which is what makes post-quantum integrity affordable on a platform that writes thousands of samples a second.
Working offline, sharing sealed
A vehicle spends most of its life away from a network. 8DB is embeddable, runs in process, and its core tested operations need no external key or identity service, so capture, sealing and local query continue without reach-back. When the platform returns to a depot or a link appears, already-sealed telemetry moves to the higher echelon through a post-quantum authenticated sealed-transfer primitive that rejects tamper, wrong-key, man-in-the-middle and replay cases in the tested harness, without exposing plaintext to move it.3
Where the model layer begins
8DB is the protected data and memory substrate. It is not the anomaly-detection model, the reasoning agent or the sustainment workflow, and nothing we publish validates model accuracy, the quality of a recommendation, or third-party hardware. What the substrate offers the model is inputs that are attributable, unaltered and governed, and a store that keeps working where the vehicle goes. A program that separates those two responsibilities cleanly has an easier evaluation and a more defensible warning.
Evidence notes
The properties above map to formal claims in our independent evaluation package: named harnesses, frozen baselines, PASS, FAIL and INCONCLUSIVE rules applied by an evaluator on an isolated host without source access. Cryptographic algorithms are corroborated by a NIST demonstration-server result and an offline known-answer suite, which we call algorithm-correctness evidence and never a certificate.4 The shape of the package is set out in what an independent evaluator should be able to run.
What to bring us
- One platform's telemetry profile. Signal count and rates, the subsystem relationships you need to preserve, the events you record, and the retention horizon. We will return an acceptance plan mapping each guarantee above to a tested claim and naming the deployment tests that remain yours.
- Your egress rules. Which data may leave the platform, to whom, and under what policy. These become labels the evaluator harness can exercise.
- Your target compute. The evaluator bundle and known-answer suite should run on the class of hardware the platform will carry.
Write to hello@8braid.com with the subject "Data layer for predictive sustainment". You will hear back from an engineer.
Sources and further reading
- NIST SP 800-53 Rev. 5: Security and Privacy Controls
- NIST FIPS 204: ML-DSA
- RFC 8452: AES-GCM-SIV
- 8DB: One Store for Many Shapes, Disconnected
- 8DB: Governance That Changes the Ciphertext, Not the Prompt
Footnotes
-
The model layer is deliberately outside the boundary; a substrate cannot validate a model, and we do not pretend otherwise. ↩
-
The claim is bounded to the tested shapes. Full time-series and other research modalities are real in the engine and are not claimed to carry uniform protected treatment until an evaluator can test them. ↩
-
The claim is limited to the sealed-transfer primitive, and it is not a validation of the program's chosen transport or of any end-to-end DDIL behaviour. That integration test belongs to the program, and we say so. ↩
-
The aarch64 Linux build is CI-gated: the release harness and the known-answer suite run on an AWS Graviton3 self-hosted runner (2026-09-12), with the bench log, 35 of 35 known-answer vectors and the OpenSSL 3.5.8 interoperation set in the public evidence tree. Rugged platform boards inherit that build, and the on-target run is part of the acceptance plan we return. ↩
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