The model says a component needs attention. The maintainer asks why. Answering well may require a sensor history, the identity of the installed part, a recent service event and the exact model that raised the warning. If those records disagree about the asset or the time, the investigation starts with reconciliation.
8DB, our omnimodal database, offers native representations for connected records, relationships and signals. The opportunity for a sustainment team is to keep the alert close to the evidence needed to inspect it, and to preserve that connection when the case is reviewed later.
Start with one warning that was difficult to explain. It is a better test of the data layer than another dashboard of unconnected readings.
Give the warning a path back to its inputs
Imagine a vibration alert on a pump that was replaced during the previous service visit. The reviewer needs to distinguish the old component's history from the replacement's readings. They also need to know whether the model used data from before or after the service event.
A useful record links the alert to the input interval, asset and component identities, processing steps, model version and resulting recommendation. Keep the maintenance action and subsequent observation alongside it. That makes it possible to compare what the system predicted with what the team found.
W3C's PROV overview provides a helpful vocabulary: data entities, the activities that produced them and the people or systems involved. Our proposed maintenance record applies that idea to an operational question. A customer pilot must verify which relationships the integration actually captures.
Illustrative pump inspection · Connected evidence
What belongs behind this warning?
The reviewer needs to trace the alert back to the equipment, observations and computation that produced it.
Which component?
Asset identity, installed part and replacement event distinguish the current pump from its predecessor.
Which readings?
Capture interval, sensor identity, calibration and missing samples define what the model could see.
Which model?
Input selection, transformations, model version and output bind the warning to an actual computation.
Keep inspection findings and later observations with the alert so the team can evaluate its usefulness.
Let each data shape do useful work
Readings have order and intervals. Components have relationships. A replacement is an event. A procedure is a document. Shared identity helps these views contribute to the same investigation without treating them as interchangeable.
8DB's native multimodal design provides building blocks for this approach. A graph can identify the installed component, a time-series operation can examine its signal, and related records can preserve the service context. The protection, freshness and recovery behavior of that combined application must be tested on the selected configuration.
Specialist time-series stores, asset registries and maintenance systems can also be integrated successfully. Compare the whole workflow: how much work connects the records, how quickly a reviewer reaches the relevant evidence, and what happens when an input is corrected. Native breadth matters when it improves that job.
Check three different kinds of trust
| Question | What can support the answer |
|---|---|
| Was this the recorded input? | Bound source identity, capture metadata and integrity verification |
| Did the input describe the equipment accurately? | Sensor calibration, time alignment, missing-data checks and inspection |
| Was the warning useful? | Model evaluation, observed outcomes and the cost of false alarms or missed faults |
An integrity proof can help establish that disclosed data matches an authenticated record. It cannot establish that a sensor was calibrated or that a predicted failure would occur. A subsystem relationship can help an investigation without proving a causal explanation.
This separation makes the data layer more valuable. It lets the team locate the uncertainty instead of hiding different problems behind a single confidence score. Preserve simulated, measured and model-derived data as different evidence types, with the transformations between them recorded.
Keep the investigation usable in the field
Decide which evidence must remain available without a connection, what a local acknowledgement promises and what the receiving system must contain after synchronization. Our offline workflow guide follows these questions through restart and reconnection.
8DB’s public recovery evidence includes process-kill and same-store-reopen checks on typed records, alongside recipient checks and local resealing in the protected-node path. A fleet evaluation can build on those components: bring a telemetry schema, a maintenance decision and the interruption the field system must survive. Explore the qualification record.
For a telemetry pilot, qualify the actual schema, device and interruption conditions. Access controls can restrict approved operations, but an authorized process that sees plaintext also needs appropriate operating-system and network controls. A captured-device threat model must include secret custody and the state of the running system.
Choose a pilot that can change a decision
NASA's C-MAPSS dataset provides simulated engine data for prognostics research. Such data can help exercise a repeatable pipeline before sensitive fleet records are available. It does not substitute for the equipment, operating conditions and maintenance outcomes of a customer deployment. We report no new NASA-dataset experiment here.
For a first customer evaluation, select one historical alert and its associated records. Freeze the model and inputs, reconstruct the evidence, then introduce a controlled correction or component change. Measure missing links, reviewer effort and whether the affected conclusion is identified correctly. Test storage protection and recovery separately from prediction quality.
The result should be a clearer explanation of that alert and a concrete account of the integration work required. Fleet availability, reduced maintenance cost and better predictions are outcomes to measure in a later operational study.
Bring us one maintenance alert that was hard to explain. Start with a non-confidential description of the platform, available records and the question your maintainer could not answer. We can define a focused evaluation around that gap.
Evidence scope Maintenance workflow design · Primary provenance research · Scoped component evidence. Explore the evidence. The reviewed integrated profile uses a defined structured-record schema; integrating and qualifying your schema is the first step of an evaluation. Methods and retained scope notes.