lgdimaggio/predictive-maintenance-mcp/prognostics

Prognostic Assessment (ISO 13374 Block 5)

Screen degradation trends within a recording and estimate Remaining Useful Life from repeated measurements over time. Three distinct scopes; do not confuse them:

1. Within-recording screening (analyze_signal_trend): is this single

recording stationary, or does a feature drift inside it? This is a screening result, NOT a prognosis.

1. Prognosis (estimate_rul): extrapolation of a degradation trend

across MULTIPLE measurements of the same machine taken days/weeks/months apart. RUL from a single recording is physically meaningless and the tool refuses it.

1. Indicator projection (forecast_asset_indicator, not yet released):

where one indicator's values are heading over the next hours or days. A projection, NOT a prognosis.

RUL estimates are planning input for the maintenance engineer — never a guarantee, never a substitute for engineering judgment.

Prerequisite: The predictive-maintenance-mcp MCP server must be connected.

Workflow A — Within-Recording Screening

Step 1 — Signal Discovery

Call list_signals(scope="memory") for loaded signal_ids, or list_signals(scope="disk") and load_signal(filepath="<file>") to load a recording. This works best on long monitoring recordings or run-to-failure data where degradation evolves within the file. For raw binary files (.bin/.raw/.dat), also declare sample_format and sampling_rate (or provide a companion <stem>_metadata.json) — see the signal-management skill.

Step 2 — Trend + Onset Screening (one call)

Call analyze_signal_trend(signal_id="<id>", feature_name="rms").

The tool segments the recording, extracts the chosen feature per segment, tests trend significance (slope p-value, not bare R-squared), and detects the first post-baseline segment exceeding baseline mean + N sigma — trend AND onset in one result.

Parameters:

• feature_name: "rms" (default), "kurtosis", "crest_factor",

"peak_to_peak", ...

• segment_duration (default 0.1 s) and overlap_ratio (default 0.5)
• onset_threshold_sigma: baseline standard deviations that trigger onset

detection (default 3.0; lower to 2.0 for more sensitivity, with more false positives)

Feature guidance:

Interpreting the result:

• trend_direction is decided by the slope p-value (< 0.05), not by eye
• analysis_scope is "within_recording_screening" — report it as such
• Onset fields: onset_detected, onset_segment_index, onset_time_s,

baseline_segments. Onset inside the baseline window (first half) cannot be detected by construction — say so if the user asks

• The result includes the (truncated) per-segment feature_series: use it to

reduce this recording to ONE measurement point for Workflow B

Decision gate: if the trend is stable or decreasing, report that no degradation trend is detected within the recording. Do NOT proceed to RUL on this basis alone.

Workflow B — RUL from Repeated Measurements

Step 1 — Assemble a Measurement Series

RUL needs at least 3 measurements of the same machine over time, as either:

• Externally measured values (e.g. RMS velocity trended by a data

collector): pass them directly as feature_values.

• One stored recording per measurement session: load each session's

file (batch load works: load_signal(filepath=["session_day0.csv", "session_day7.csv", "session_day14.csv"], signal_unit="mm/s")) and pass the ids as signal_ids — each recording is reduced to a single feature value.

Timestamps are required, one per measurement, strictly increasing, in the unit you choose (time_unit, default "hours").

Step 2 — Choose the Failure Threshold

Ask the user — do NOT guess. If the indicator is broadband velocity RMS in mm/s, the ISO zone C/D boundary for the machine is the standard choice (the same table assess_severity uses): 4.5 (group 2 rigid), 7.1 (group 1 rigid / group 2 flexible), or 11.0 mm/s (group 1 flexible). A site maintenance policy threshold also works.

Step 3 — Estimate

Call estimate_rul(feature_values=[2.1, 2.4, 2.9, 3.5], timestamps=[0, 168, 336, 504], failure_threshold=4.5, time_unit="hours", method="linear")

or, from stored recordings:

Call estimate_rul(signal_ids=["session_day0", "session_day7", "session_day14"], timestamps=[0, 7, 14], failure_threshold=4.5, feature_name="rms", time_unit="days")

Method choice:

• "linear" — steady degradation (default)
• "exponential" — accelerating degradation curves
• "kalman" — needs approximately uniform measurement spacing; also returns

a 95% RUL interval

Step 4 — Interpret the Result Honestly

Possible statuses:

• "estimated": RUL in time_unit, with fit_r_squared (goodness of fit —

NOT a confidence) and observation_horizon. If RUL extends far beyond the observed horizon, the result says so — relay that caution verbatim

• "no_degradation_trend": flat/insignificant series — no RUL number is

produced. Recommend continuing to collect measurements

• "threshold_already_exceeded": the last measurement is at/above the

threshold — inspection is due now, there is no remaining life to estimate

Report: trend significance (p-value), fit quality, RUL with its time unit, observation horizon, and urgency relative to the next maintenance window.

Workflow C: Indicator Projection (not a prognosis; unreleased)

Use forecast_asset_indicator only when the user asks where an indicator's values are heading in the next hours or days. Questions about time to failure, remaining life or when to replace a part go to Workflow B. If the connected server does not list forecast_asset_indicator, tell the user it is not available in this server version; do not substitute estimate_rul or extrapolate by hand.

Call forecast_asset_indicator(observed_at=["2026-10-20T00:00:00Z", "2026-10-20T01:00:00Z", ...], values=[2.1, 2.2, ...], indicator="velocity RMS", unit="mm/s", resolution="1h", horizon_steps=24)

• Every instant needs Z or a UTC offset; an instant without one is refused.

A missing observation is left out, never sent as null, zero or a filled value.

• The unit and, for backend="seasonal_naive", season_length_steps come

from what the user states, never from a guess: ask the user.

• status="insufficient_history" gives a reason, the available and required

amounts and a remedy; follow the remedy, never pad the series.

• Quote the interpretation, method_note and interval_note fields. A flat

naive median repeats the last bin by construction; it does not mean the indicator will stay stable.

• Never derive a time to a threshold, a crossing probability or an ISO zone

from the projection, and never pass its values to estimate_rul or assess_severity.

Important Notes

• RUL estimates are extrapolations — actual failure time depends on

operating conditions that may change

• For RUL results (Workflow B), always use cautious language: "estimated

RUL", "projected time to threshold"

• fit_r_squared measures curve fit, not probability of being right
• A single recording can NEVER produce an RUL — if the user asks, explain why

and offer Workflow A screening plus a measurement-collection plan

• This skill supports expert maintenance scheduling decisions; it does not

replace engineering judgment

• All processing happens locally — raw signal data never leaves the machine