Capped at three failure-tagged closed work orders.
Methodology whitepaper · v1.0
A maintenance signal, not a maintenance verdict.
This model card documents what Revolution Road scores, how confidence is earned, when a model may be promoted, what never leaves the operational boundary, and where the result can be wrong.
01 / Baseline model
Transparent by design
The active forge-heuristic-1.0.0 model produces a 0–1 risk index for a 30-day horizon. Low is below 0.30, moderate begins at 0.30, high at 0.55, and critical at 0.75. It does not estimate remaining useful life. estimated_days_to_failure remains null until a supervised model passes validation.
Important: a score is advisory. It does not diagnose a failure, guarantee uptime, replace an inspection, or automatically edit a preventive-maintenance schedule.
02 / Feature contract
Five inputs, one versioned snapshot
Share of recent good-quality readings beyond a three-sigma baseline.
Normalized to 500 operating hours.
Normalized to 180 days; missing PM evidence adds no risk.
Capped at two overdue preventive work orders.
Confidence begins at 35% and rises with four evidence groups: usage readings, sensor history, work-order history, and a PM template. This keeps sparse assets from looking more certain than the data supports.
03 / Validation
Measure misses as well as hits
A prediction matures after its stated horizon. Revolution Road labels the outcome only from work orders explicitly marked failure_event=true. The backtest publishes sample size, confirmed positives, threshold, precision, recall, F1, false positives, and false negatives. Before any supervised candidate can be promoted, the connected-history gate requires at least 30 matured predictions, 5 failures, precision of 0.60, and recall of 0.60. These are initial operational gates, not claims of universal accuracy.
Current public sample metrics are intentionally blank: the preview contains illustrative records, not production history. Revolution Road does not turn demo data into an accuracy claim.
04 / Drift & retraining
Watch the data that made the model useful
The daily pipeline compares rolling 30-day prediction distributions with the prior window. A mean-risk shift of 0.10 enters watch; 0.20 requires action and a retraining review. The external analytics worker can add per-feature population stability index. Retraining creates a candidate version; it never replaces the active model automatically.
05 / Security & privacy
Derived maintenance evidence only
The export contract allowlists asset ID, timestamp, usage hours, failure count, days since PM, sensor anomaly score, overdue PM count, completeness, and feature-schema version. It excludes user IDs, names, emails, locations, free-text work-order titles and descriptions, notes, feedback text, filenames, and attachments. Tenant IDs are used for routing inside the service but are not included in the analytics payload.
Feature snapshots, predictions, feedback, model versions, validation runs, and drift evidence all carry immutable organization_id ownership and Postgres row-level policies. Model endpoints require the same role checks as the CMMS.
06 / Known limitations
Where judgment still matters
- Failure labels are only as reliable as the team’s
failure_eventclassification. - A three-sigma sensor rule may miss gradual degradation or overreact to a changed operating regime.
- Weights are a starting policy, not a learned causal relationship.
- New or lightly instrumented assets receive lower confidence and may still fail unexpectedly.
- Risk is not comparable across unlike asset classes until class-specific validation exists.
- No prediction should override safety procedures, manufacturer instructions, inspections, or statutory maintenance.