An audit trail for predictive maintenance exists so that someone can reconstruct, months later, how a decision about a specific asset came about. For a decision triggered by a remaining-useful-life (RUL) model, that means each record should hold the prediction with its uncertainty bound, the model version that produced it, the threshold or decision policy in force, the action taken, and the person who approved it, with the meaning of their signature and the time they signed. 21 CFR Part 11 governs that record only when a predicate rule already requires it and you keep it electronically in place of paper. Platform vendors hold that predictive maintenance records supporting food-safety (Oxmaint) or GMP (iFactory) obligations fall in scope.
The model is one link in a chain. A well-calibrated RUL estimate with no version history can’t be defended, and a perfectly logged trigger built on an uncalibrated model is defensible on paper and wrong in practice.
Estimating remaining useful life from vibration and temperature trends instead of fixed alarms
A fixed vibration or temperature alarm tells you a reading has crossed a line. An RUL model tells you how long the component is likely to last and how confident it is, and that is what a planner needs to book a repair. History matters: two similar sensor readings reached along different degradation paths don’t necessarily mean the same health state, so a model that ignores operating history can misinform the maintenance decision.
The uncertainty bound is part of the answer, not decoration. In a bearing study on the PRONOSTIA (PHM12) dataset, the model estimated 1,400 s of remaining life, with a 90% confidence interval of 1,310 s to 1,500 s that contained the true value. RUL models feed critical decisions and need to give a probability density rather than a bare point estimate. The confidence representation should answer how likely the true RUL is to be shorter than predicted, and by how much. Uncertainty also widens for units whose operating conditions differ from the training data.
What false-positive rate will maintenance teams actually act on?
There is no universal number. The tolerable rate depends on what a miss costs compared with what a false alarm costs. NASA’s prognostics metrics work (Saxena et al., 2010) notes that a mission-critical system may accept some false positives but no false negatives, while elsewhere the cost of acting on false positives can be prohibitive. For one published reference point: a turbofan study on the CMAPSS FD001 benchmark set intervention at predicted RUL of 30 cycles or fewer. It recorded 3 false alarms (a 4.0% false-positive rate) and 1 missed detection among the 25 engines that needed maintenance. Across thresholds from 20 to 100 cycles, 30 gave the best balance in that study. That is a benchmark result. Your fleet’s rate has to be measured on your own fleet, against the costs your planners agree on.
Can the model give enough lead time to schedule the repair?
Lead time is a requirement you set first and test the model against, not something you discover afterwards. The NASA framework defines the prognostic horizon as the time between the point where predictions first meet the accuracy criterion and end of life, with the error bound chosen according to how long corrective action takes. It also defines an end-of-useful-predictions point: the minimum horizon needed to act, beyond which predictions have little practical use. In practice we would start from parts lead time, crew availability and outage windows, then check whether the model reaches that horizon at the false-alarm rate the team accepts.
Three caveats stay with any RUL programme. Measurement uncertainty from sensor noise and data preprocessing feeds into every prediction. We would re-tune the false-positive and lead-time trade-off as failure-mode distributions shift. And trust comes from tracking performance after deployment, not only from the initial validation. That post-deployment side, including validation, drift detection and continuous monitoring across the model lifecycle, is covered separately.
Validating an RUL model when you have only a handful of real failures
With a few real failures per site, we would not validate an RUL model the way large-sample survival analysis assumes. What you can defend is a calibrated uncertainty interval checked against the real failures you have, with its limits stated openly.
TechnoLynx gives an RUL model with few real failures calibrated uncertainty bounds checked against real failures, and connects them to production monitoring with retraining triggers.
We would use conformal prediction here. It produces intervals guaranteed to contain the true value at a chosen confidence level, without assuming a distribution, provided the data are exchangeable. Split conformal prediction holds back a calibration subset to size the intervals. Two limits matter. The guarantee is marginal: it holds on average, and coverage can fall short in some RUL regions. And it depends on the data being exchangeable. For that reason we would always calibrate on real failures, however few.
Worked example: how small a calibration set can be
Assume each real failure trajectory counts as one exchangeable calibration unit (a modelling choice to state up front, not a given). The calibrated quantile is the ⌈(1 + n)(1 − α)⌉-th smallest non-conformity score among n calibration points.
The NASA prognostics work already demands rigorous validation before critical use. Each new real failure should go back into calibration and the retraining trigger.
Ranking assets for a turnaround work list the committee can defend afterwards
A risk ranking on its own doesn’t settle a turnaround sequence. The schedule should come from an optimisation step that encodes crew capacity and outage windows alongside the scores, so each asset’s slot traces back to its risk score and to the constraint that put it there.
Timing is a multi-factor call. NASA’s prognostics framework lists current health, spares, maintenance opportunity, alternatives, costs and risk-absorbing capacity as inputs. That is why the pump-by-pump answer to “why this one before that one” should read as a score plus a binding constraint, for example “higher risk”, or “equal risk but only one crew free in that window”. In regulated manufacturing, one scheduling vendor’s guidance asks for time-stamped audit trails on schedule creation, modification, freeze and approval, with reason codes for reschedules and overrides, and electronic signatures on freeze and override approvals. Two conditions keep this honest. We would keep the optimisation interpretable (a linear or integer programme rather than an opaque heuristic). And if the crew or outage data feeding the constraints is stale, the trail will be internally consistent and factually wrong.
Can an RUL risk ranking account for consequence of failure, not just probability?
Yes, and it should. API RP 581 computes risk as probability of failure combined with consequence of failure, and observes that much of a unit’s total risk usually sits in a small share of its equipment. RBI tools put this on a matrix of PoF categories 1 to 5 against CoF categories A to E. The NASA framework likewise says parameters for multiple units should follow a criticality list, usually assessed from FMECA severity and frequency data. We would take the probability side from the RUL model and the consequence side from the process-unit criticality you already maintain. We would log the two separately so a reviewer can see which one drove the ranking.
When does an audit trail for predictive maintenance fall under Part 11?
A model-triggered maintenance record falls under 21 CFR Part 11 when two things hold: an existing predicate rule (GMP, for instance) requires the record, and you keep it electronically in place of paper. That is the narrow reading in FDA’s 2003 scope and application guidance.
Part 11 creates no record-keeping duty of its own. It sets the conditions under which an electronic record or signature counts as equivalent to paper for records a predicate rule already demands. FDA’s guidance confirms that if you print records, the printouts meet the predicate rule, and you rely on the paper, you are generally not using electronic records in lieu of paper. On predictive maintenance specifically, one platform vendor (iFactory) holds that RUL estimates, recommendations and work-order approvals supporting GMP predicate rules are Part 11 records.
The enforcement position needs reading carefully. FDA said it would not enforce the validation, audit-trail, retention and copying requirements as explained in that guidance, but predicate rules still apply. It does still enforce access limits, authority checks and the electronic-signature requirements. It also recommends deciding on audit trails through a documented risk assessment, noting they fit especially well where users create or modify regulated records in normal operation. Enforcement discretion is not an exemption, and a model that writes maintenance recommendations every day is exactly that kind of system.
The audit trail itself, under §11.10(e), is a secure, computer-generated, time-stamped record of the entries and actions that create, modify or delete a record, without obscuring what was there before. In practice that means keeping before-and-after values, making the trail write-protected from every user including administrators, and turning corrections to closed records into linked amendments with a reason and an author. Software alone doesn’t get you there: written SOPs, training records and periodic reviews are part of compliance too.
Model changes are part of the record. FDA notes that manufacturing models are developed, validated, implemented and updated through change control, and flags continuously learning models as a challenge for oversight. In practice, every trigger should name the model version that fired it.
If no FDA predicate rule requires your record, Part 11 doesn’t apply to it. Its controls are still a sound design standard to borrow when legal, an insurer or a regulator may later question a shutdown.
Who has to approve the prediction before it counts as a validated trigger?
Authority checks must confirm the signer is authorised for that specific operation before they sign. In iFactory’s design, the prediction stays decision support until that signature exists. The signed record has to show the signer’s printed name, the date and time, and the meaning of the signature, such as review or approval. It must be linked to the record so it can’t be copied onto another, and identity is verified at the moment of signing, not just at login. If the record is later amended, the original signature is kept alongside the amendment’s. Which role signs on your site, and how your site reads Part 11, is for QA and regulatory affairs to settle. TechnoLynx builds the records they sign against, not the sign-off itself.
Setting the trigger on the survival curve, not on one RUL number
A static threshold on a point estimate throws away what the survival curve and its bounds say. A 2023 paper on decision-oriented prognostic metrics formalises the simplest alternative: at each decision step, replace preventively if the predicted probability that RUL falls within the next step reaches a threshold, otherwise do nothing. For regression models, that probability requires uncertainty quantification. The threshold is tuned on run-to-failure training data to minimise maintenance cost, and in one case study the optimised values were 0.11 for ordering a spare and 0.5 for replacement. In that study, policies that use the full RUL distribution performed better than the simple threshold rule at the uncertainty level tested. The cost inputs don’t have to be exact: the authors argue that rough estimates from experienced engineers are enough.
For the audit trail, this means the trigger isn’t one number. It is the probability, the threshold and the cost parameters behind it, all agreed with the stakeholders and all versioned, because changing any of them moves the trigger.
What to log each time an RUL threshold fires
Each firing should write one record that binds the prediction and its bound, the model version, the input data, the policy and threshold in force, the action, and the human decision, including any override, into an entry that nothing can edit afterwards.
TechnoLynx builds this kind of decision logging through its Production AI Monitoring Harness, so a past maintenance call can be reconstructed from the record rather than from memory.
| Field | What it holds | Basis for including it |
|---|---|---|
| Timestamp | Time of the prediction and of each later action, from a validated clock | Contemporaneous records under ALCOA+ |
| Model version | Unique identifier of the release that produced the prediction | Traces any alert to its model |
| Input reference | Hash or pointer to the sensor window used | Traces the alert to the readings behind it |
| Prediction | Mean RUL and interval bounds at the stated confidence level | A prediction is of limited use without its stated confidence |
| Confidence score | The model’s stated confidence for this prediction | Recorded with each prediction |
| Policy and threshold | Decision rule, threshold value and its version | The rule is what fired |
| Consequence rating | Criticality or CoF category used in ranking | Risk combines probability and consequence |
| Action | Work order or schedule change it produced | Reconstructs the course of events |
| Approver | Name, date and time, signature meaning | Signature manifestation |
| Override | Whether a person overrode the model, with a reason code | Reason codes for reschedules and overrides |
| Chain link | Link into a hash chain or Merkle root | Ties each item into a larger audit structure |
Threshold changes and retraining are events too
Threshold edits and model releases need their own time-stamped entries, so any firing can be matched to the settings in force at that moment. One vendor’s guidance treats every model release as a changed state requiring re-validation. PIC/S expects user identities, times and critical parameters to be fully captured where they are needed to reconstruct events, and raw data to be kept for the same reason. Reconstruction depends on the raw data captured at the time. Re-running today’s model against old data doesn’t tell you what last spring’s version recommended.
Making the log tamper-evident
A proposal for regulated AI workflows treats each evidence item as a fixed set of fields. These commit to the unit of work, its inputs and outputs and the execution environment, link into a hash chain or Merkle root, and carry an authenticator over the whole entry. Binding plus tamper detection means one item can’t serve as evidence for two different events. The same work suggests anchoring high-stakes events individually and batching routine ones. Copies for review should be electronic true copies with their metadata, never PDFs that drop it, and procedures should set how often the audit trail is reviewed.
Logging like this is reliability engineering, separate from model accuracy. The trail is raw material. Turning it into something a non-engineer can read and sign against is the job of a defensible evidence pack for audit and procurement review.
Who can build the audit trail into our predictive maintenance system?
TechnoLynx builds the monitoring and drift checks for manufacturing and automotive AI. The Production AI Monitoring Harness covers the build, and Production AI Reliability covers running it once it is in production. Building in-house makes sense if your team already owns the model, the CMMS integration and a validated change-control process. A specialist helps most when the logging has to wrap a pipeline nobody designed with audit in mind. When choosing a partner, ask to see how a past decision would be replayed from their records, not just a dashboard.
The work has limits. It produces the artefacts an audit needs, not legal advice, regulatory sign-off or certification, and it doesn’t replace your QA function. If your regulated records live on paper you rely on, Part 11 may not reach them at all. We would also weigh your CMMS vendor’s Part 11 module for the work-order side, a computer-system validation consultancy for the validation package, or an internal MLOps team where one already exists.
What to check before the next turnaround
Thin real-failure data leaves the uncertainty bound wide, a ranking without consequence weights favours the wrong pump, and a log without model versions turns a sound call into an assertion. The question to settle before the next turnaround isn’t whether the model is accurate enough. It is whether, for any asset you pulled, you could show the prediction, the bound, the rule, the version and the signature exactly as they stood on the day.
