The Integrated Master Schema

Chapter 7 — The Integrated Master Schema

The Brain of the System

The Integrated Master Schema (IMS) is the single linking structure that connects every diagnostic decision in RAPID AI. It is not a database table. It is not a configuration file. It is the ground truth — the authoritative matrix that ensures sensor data, diagnostic logic, maintenance strategy, and dashboard presentation remain consistent across the entire platform.

The IMS is a matrix of 100 rows across 34 columns. Each row maps the complete diagnostic path from sensor input through to dashboard output for a specific failure mode on a specific asset type. When a reliability engineer questions a recommendation, they can follow the chain from the dashboard message back through the RCM logic, through the sensor evidence rule, to the specific failure mode and its physics. Nothing is a black box.

Structure

The 34 Columns

The IMS columns span seven functional groups:

Group 1 — Asset Context (columns 1-4)

Column	Description
schema_id	Unique row identifier (IMS001-IMS100)
asset_type	Equipment family (pump, electric motor, gearbox, etc.)
asset_subtype	Specific variant (centrifugal pump, helical gearbox, etc.)
asset_id_example	Reference asset ID for testing

Group 2 — Failure Logic (columns 5-10)

Column	Description
subsystem	Functional subsystem (bearings, hydraulics, sealing, etc.)
function	What the asset must do (deliver rated flow, support rotor, etc.)
functional_failure	How the function can fail (reduced flow, excess vibration, etc.)
failure_mode	The specific mechanism (cavitation, outer race spalling, etc.)
failure_cause	Root cause description
typical_symptom	Observable field symptoms

This group encodes the RCM logic chain: function -> functional failure -> failure mode -> cause. Every maintenance strategy traces back to a specific function that must be preserved.

Group 3 — Detection (columns 11-16)

Column	Description
sensor_type	Required sensors (vibration, temperature, pressure, current, etc.)
sensor_feature	Extracted features used for detection
sensor_evidence_logic	The detection rule as a parseable expression
detectability	Online, offline, or mixed
confidence_rule	What makes the detection high or low confidence
rul_relevance	How relevant RUL estimation is for this failure mode

The sensor_evidence_logic field is the computational heart of each row. It contains the IF-THEN expression that the rule engine evaluates against live data. For example:

IMS001: IF suction pressure falls AND cavitation signature rises THEN cavitation candidate
IMS002: IF BPFO rises AND envelope energy rises AND temperature rises THEN bearing distress candidate

Group 4 — Risk Assessment (columns 17-21)

Column	Description
consequence_category	Safety, Environmental, Operational, Economic, or Hidden
severity_rank_default	Default severity (1-5)
probability_rank_default	Default probability (1-5)
detectability_rank_default	Default detectability (1-5)
risk_priority_formula	Always S x P x D

These columns feed the RPN (Risk Priority Number) computation described in Chapter 9. The default ranks serve as starting points that RAPID AI adjusts based on real-time sensor data.

Group 5 — Maintenance Strategy (columns 22-30)

Column	Description
rcm_decision_logic	The decision rule that selects the strategy
recommended_strategy	CBM, Planned Replacement, Scheduled Inspection, etc.
maintenance_task	Specific task description
task_type	Condition-based, Preventive, Corrective, etc.
task_frequency	How often (daily, weekly, monthly, at shutdown, etc.)
trigger_condition	What triggers the task
responsible_team	Which team executes (Maintenance, Operations, Reliability, etc.)
spare_requirement	Parts needed
shutdown_requirement	Whether the machine must be stopped

Group 6 — Dashboard Output (columns 31-33)

Column	Description
dashboard_output_widget	Which UI component displays this (Health Card, Risk Banner, Action Tile, etc.)
dashboard_output_message	The human-readable message shown to the user
api_output_field	Which API response fields carry this information

Group 7 — Governance (column 34)

Column	Description
notes	Engineering context, implementation notes, cross-references

The 19 Equipment Families

The IMS covers 19 equipment families with 5-6 rows per family:

Family	Row Count	Example Failure Modes
Pump	6	Cavitation, bearing spalling, seal leakage, misalignment, impeller erosion
Electric Motor	6	Broken rotor bars, insulation failure, bearing damage, cooling failure, voltage imbalance
Gearbox	6	Tooth pitting, lubrication starvation, bearing failure, seal failure, foundation looseness
Fan	5	Blade imbalance, bearing failure, foundation looseness, airflow blockage, rotor rub
Compressor	5	Surge, bearing failure, seal leakage, valve degradation, intercooler fouling
Turbine	5	Blade erosion, bearing wear, seal degradation, governor instability, exhaust overtemp
Valve	5	Seat leakage, actuator failure, positioner drift, packing leakage, corrosion
Generator	5	Insulation degradation, bearing damage, excitation fault, cooling failure, winding fault
Conveyor	5	Belt slip, roller failure, tracking error, drive failure, structure fatigue
Crane/Hoist	6	Wire rope degradation, brake wear, gearbox damage, structural fatigue, control fault
Blower	5	Rotor imbalance, bearing failure, looseness, blockage, rub
Boiler	5	Tube failure, refractory degradation, burner fault, drum level instability, efficiency loss
Chiller	5	Compressor surge, condenser fouling, refrigerant leak, bearing failure, control drift
Heat Exchanger	5	Tube leakage, fouling, corrosion, vibration, pressure drop
Hydraulic Power Unit	5	Pump wear, valve sticking, filter blockage, fluid contamination, seal leakage
Mill	5	Liner wear, bearing failure, drive failure, material blockage, foundation settlement
Transformer	6	Winding fault, insulation degradation, cooling failure, bushing fault, tap changer failure
Actuator	5	Stem binding, positioner drift, seal leakage, motor failure, feedback loss
Agitator	5	Shaft fatigue, bearing damage, seal leakage, blade erosion, coupling failure

How to Read the IMS

Walkthrough: IMS001 (Pump Cavitation)

This single row encodes the complete diagnostic chain for pump cavitation:

Asset: Centrifugal pump (P-101), hydraulics subsystem
Function: Deliver rated flow and head
Functional failure: Reduced flow / unstable flow
Failure mode: Cavitation
Failure cause: Low NPSH / suction blockage / air ingress
Detection: Pressure + Vibration + Acoustics sensors
Evidence logic: IF suction pressure falls AND cavitation signature rises THEN cavitation candidate
Confidence: High if process and vibration data concur
Consequence: Operational (severity 4, probability 3, detectability 3, RPN = 36)
RCM decision: If online detectable with confidence >= 0.70, apply CBM + process correction
Strategy: Condition Based Maintenance
Task: Check suction line, strainers, NPSH, operating point
Frequency: Daily / shift review
Trigger: Suction pressure low with cavitation signature sustained
Team: Operations + Reliability
Dashboard: Process Alert + Advisory Panel
Message: “Probable cavitation detected; inspect suction conditions”
API fields: failure_mode, confidence_score, strategy

This is a “strong process-mechanical fusion case” — the notes field indicates that this diagnosis is strongest when both process data (suction pressure) and mechanical data (vibration signature) agree.

Walkthrough: IMS007 (Motor Stator Insulation Failure)

A safety-critical example:

Asset: Induction motor (M-202), stator subsystem
Function: Maintain insulation integrity
Failure mode: Stator winding insulation failure
Evidence logic: IF current imbalance persists AND temp rises AND IR/PI deteriorates THEN insulation failure risk
Consequence: Safety (severity 5, probability 3, detectability 4, RPN = 60)
RCM decision: If safety consequence and severity >= 4, escalate immediately
Strategy: Immediate Action / Escalation
Dashboard: Critical Alarm + Escalation Banner
Message: “Motor insulation integrity at risk; escalate”

The safety consequence category combined with severity >= 4 forces Tier 1 escalation in the RCM decision logic, regardless of other factors. This is by design: safety-critical failure modes always receive the most conservative response.

How to Extend the IMS

Adding a new failure mode to the system means adding a new IMS row with all 34 fields populated. This constraint forces complete thinking:

Can we detect it? What sensors are needed? What features? What evidence logic?
How serious is it? What are the consequences? Safety? Environmental? Operational?
What should we do? Which maintenance strategy? What task? Who does it?
How do we show it? Which dashboard widget? What message? What API fields?

If any of these questions cannot be answered, the failure mode is not ready for production. The IMS serves as a governance artifact — it prevents half-thought-through rules from entering the system.

Extension Process

Identify the new failure mode and its asset context
Research the detection physics — what sensor evidence reveals this failure?
Define the evidence logic as a parseable expression
Assign consequence category and risk ranks
Select the RCM strategy using the six-tier decision hierarchy from Chapter 9
Define the maintenance task and trigger
Map to dashboard widget and API output fields
Review with a reliability engineer for physics validation
Add the row to integrated_master_schema_library_100.csv
Generate normalized schema records for the runtime database

Current State and Growth Path

The current 100-row IMS covers the most common failure modes across 19 equipment families. The target is 500+ rows covering the full industrial equipment spectrum. Each new row adds diagnostic capability without modifying any service code — because rules are data, not code.

The IMS connects to the FRETTLSM taxonomy through the failure_cause field, to the RCM framework through the rcm_decision_logic field, and to the implementation layer through the normalized schema tables that decompose each IMS row into runtime-queryable relational records.

The IMS as the Single Source of Truth

The IMS is not just a design artifact. It is the operational contract between the diagnostic engine and the user interface. Every diagnosis RAPID AI produces traces back to an IMS row. Every dashboard message corresponds to a specific IMS dashboard_output_message. Every API response field maps to an IMS api_output_field.

This traceability is what distinguishes RAPID AI from black-box systems. When a reliability engineer sees “Probable cavitation detected” on the dashboard, they can trace that message back through the IMS to the sensor evidence logic, to the failure mechanism, to the physics. The chain of reasoning is transparent, auditable, and explainable — because the IMS makes it so.

Standards Alignment

Standard	Relevance to This Chapter
ISO 14224 — Reliability and maintenance data	The IMS’s 34-column structure (asset context, failure logic, detection, risk assessment, maintenance strategy, dashboard output, governance) implements ISO 14224’s standardized equipment taxonomy and failure mode classification for petroleum, petrochemical, and natural gas industries.
ISO 13374 — Condition monitoring and diagnostics of machines	The IMS’s sensor_evidence_logic field encodes the detection rules that implement ISO 13374 Level 3 (State Detection), while the rcm_decision_logic field drives Level 6 (Advisory Generation).
ISO 17359 — General guidelines for condition monitoring	The IMS implements ISO 17359’s recommendation for a structured approach linking equipment function, failure mode, detection method, and maintenance strategy in a single traceable chain.
SAE JA1011/JA1012 — RCM evaluation criteria	The IMS hierarchy (function, functional failure, failure mode, consequence, detection, strategy, task) directly implements the seven questions of SAE JA1011-compliant RCM analysis.
MIMOSA OSA-CBM — Open System Architecture for CBM	The IMS’s dashboard_output_widget and api_output_field columns implement OSA-CBM’s presentation layer requirements, ensuring diagnostic results flow consistently from engine to user interface.

Changelog

Version	Date	Author	Changes
2.1.0	2026-03-17	Rick D	Added standards alignment, living doc metadata, changelog
2.0.0	2026-03-17	Rick D	Enriched with production codebase content
1.0.0	2026-03-17	Rick D	Initial chapter creation

Next: Chapter 8 — Domain Frameworks Previous: Chapter 6 — Engineering Intelligence