IAES Specification v2.0

1. Purpose

IAES defines how industrial asset signals, diagnoses, and maintenance intents are represented and transferred across heterogeneous operational systems.

IAES is not a product. It is a data contract. Any system — sensor platform, AI engine, CMMS, historian, or dashboard — can produce or consume IAES events without knowing the implementation details of the other side.

2. Principles

1. Vendor neutrality — No dependency on SAP, PI System, Odoo, or any specific vendor.
2. Legacy compatibility — Events map cleanly to CMMS, historians, SCADA, and IoT platforms.
3. Event-oriented — Each object represents something that happened (measurement, diagnosis, intent).
4. Complete traceability — Every event traces back to its origin via event_id, correlation_id, source_event_id.
5. Extensibility — The data payload and metadata field allow new fields without breaking consumers.

3. Terminology

4. Common Envelope

Every IAES event is wrapped in a common envelope. The envelope carries identity, traceability, and routing information. The event-specific payload lives inside the data field.

{
  "spec_version": "2.0",
  "event_type": "asset.health",
  "event_id": "uuid",
  "correlation_id": "uuid",
  "source_event_id": "uuid | null",
  "batch_id": "string | null",
  "timestamp": "RFC 3339",
  "source": "vendor.system.subsystem",
  "content_hash": "sha256_16char",
  "asset": {
    "asset_id": "string",
    "asset_name": "string | null",
    "plant": "string | null",
    "area": "string | null"
  },
  "data": {}
}

Field Definitions

Asset Identity

The asset block identifies the target asset. Only asset_id is required; the remaining fields provide human-readable context and hierarchical location.

{
  "asset": {
    "asset_id": "PUMP-001",
    "asset_name": "Main Cooling Water Pump",
    "plant": "Plant A - Monterrey",
    "area": "Cooling Tower Area"
  }
}

5. Event Types

IAES v2.0 defines 7 event types organized into 3 domains: asset signals, maintenance actions, and sensor lifecycle.

asset.measurement v1.0

A single measurement reading from an asset. This is the most fundamental event type — it captures raw sensor data from vibration, temperature, current, pressure, or any other measurable quantity.

{
  "spec_version": "2.0",
  "event_type": "asset.measurement",
  "event_id": "e7f1a2b3-c4d5-4e6f-8a9b-0c1d2e3f4a5b",
  "correlation_id": "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
  "source_event_id": null,
  "batch_id": null,
  "timestamp": "2026-03-08T14:32:00Z",
  "source": "wertek.vibration.collector",
  "content_hash": "a3f8c1e2b4d6f790",
  "asset": {
    "asset_id": "PUMP-001",
    "asset_name": "Main Cooling Water Pump",
    "plant": "Plant A - Monterrey",
    "area": "Cooling Tower Area"
  },
  "data": {
    "measurement_type": "vibration_velocity",
    "value": 4.2,
    "unit": "mm/s",
    "units_qualifier": "rms",
    "sensor_id": "SENSOR-045",
    "location": "bearing_drive_end",
    "sampling_rate_hz": 25600,
    "acquisition_duration_s": 2.0
  }
}

asset.health v1.0

A health assessment for an asset. Produced by AI engines, rule-based systems, or human experts. Links to the measurement(s) that triggered it via source_event_id and correlation_id.

{
  "spec_version": "2.0",
  "event_type": "asset.health",
  "event_id": "b2c3d4e5-f6a7-4b8c-9d0e-1f2a3b4c5d6e",
  "correlation_id": "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
  "source_event_id": "e7f1a2b3-c4d5-4e6f-8a9b-0c1d2e3f4a5b",
  "batch_id": null,
  "timestamp": "2026-03-08T14:32:05Z",
  "source": "wertek.vibration.ai_engine",
  "content_hash": "f7e6d5c4b3a29180",
  "asset": {
    "asset_id": "PUMP-001",
    "asset_name": "Main Cooling Water Pump",
    "plant": "Plant A - Monterrey",
    "area": "Cooling Tower Area"
  },
  "data": {
    "health_index": 0.16,
    "anomaly_score": 0.92,
    "severity": "critical",
    "failure_mode": "bearing_inner_race",
    "fault_confidence": 0.87,
    "rul_days": 5,
    "recommended_action": "Replace bearing immediately",
    "estimated_downtime_hours": 4,
    "iso_13374_status": "imminent_failure",
    "iso_14224": {
      "mechanism_code": "1.1",
      "mechanism_label": "Mechanical wear",
      "detection_method": "2",
      "detection_label": "Condition monitoring"
    }
  }
}

maintenance.work_order_intent v1.0

A recommendation to create a maintenance work order. This is an intent, not a work order itself. The receiving CMMS decides whether to accept, modify, or reject it. This decoupling is fundamental to IAES — the AI or rule engine recommends, the CMMS decides.

{
  "spec_version": "2.0",
  "event_type": "maintenance.work_order_intent",
  "event_id": "c3d4e5f6-a7b8-4c9d-0e1f-2a3b4c5d6e7f",
  "correlation_id": "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
  "source_event_id": "b2c3d4e5-f6a7-4b8c-9d0e-1f2a3b4c5d6e",
  "batch_id": null,
  "timestamp": "2026-03-08T14:32:10Z",
  "source": "wertek.vibration.ai_engine",
  "content_hash": "d4e5f6a7b8c9d0e1",
  "asset": {
    "asset_id": "PUMP-001",
    "asset_name": "Main Cooling Water Pump",
    "plant": "Plant A - Monterrey",
    "area": "Cooling Tower Area"
  },
  "data": {
    "title": "Bearing failure predicted",
    "description": "Inner race defect detected by AI diagnosis",
    "priority": "emergency",
    "recommended_due_days": 3,
    "triggered_by": "ai_diagnosis"
  }
}

maintenance.completion v1.1

Reports the completion (or cancellation/deferral) of a maintenance activity. Links back to the original work order via correlation_id and provides outcome data for reliability analytics.

{
  "spec_version": "2.0",
  "event_type": "maintenance.completion",
  "event_id": "d4e5f6a7-b8c9-4d0e-1f2a-3b4c5d6e7f80",
  "correlation_id": "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
  "source_event_id": "c3d4e5f6-a7b8-4c9d-0e1f-2a3b4c5d6e7f",
  "batch_id": null,
  "timestamp": "2026-03-09T10:15:00Z",
  "source": "wertek.cmms.work_orders",
  "content_hash": "e5f6a7b8c9d0e1f2",
  "asset": {
    "asset_id": "PUMP-001",
    "asset_name": "Main Cooling Water Pump",
    "plant": "Plant A - Monterrey",
    "area": "Cooling Tower Area"
  },
  "data": {
    "status": "completed",
    "work_order_id": "WO-2026-0042",
    "actual_duration_seconds": 7200,
    "technician_id": "TECH-003",
    "checklist_completion_pct": 100,
    "completion_notes": "Bearing replaced. Post-repair vibration 0.8 mm/s.",
    "spare_parts_count": 1,
    "failure_confirmed": true,
    "failure_mode": "bearing_inner_race"
  }
}

asset.hierarchy v1.1

Declares or updates the hierarchical position of an asset within an organization. Used to synchronize asset trees across systems (CMMS, historians, digital twins).

{
  "spec_version": "2.0",
  "event_type": "asset.hierarchy",
  "event_id": "f6a7b8c9-d0e1-4f2a-3b4c-5d6e7f809a1b",
  "correlation_id": "f6a7b8c9-d0e1-4f2a-3b4c-5d6e7f809a1b",
  "source_event_id": null,
  "batch_id": null,
  "timestamp": "2026-03-07T09:00:00Z",
  "source": "wertek.cmms.asset_registry",
  "content_hash": "a7b8c9d0e1f2a3b4",
  "asset": {
    "asset_id": "MOTOR-042",
    "asset_name": "Pump Drive Motor 42",
    "plant": "Plant A - Monterrey",
    "area": "Turbine Hall"
  },
  "data": {
    "hierarchy_level": "equipment",
    "relationship_type": "child_of",
    "parent_asset_id": "AREA-TURBINAS",
    "asset_type": "motor",
    "serial_number": "WEG-2024-78432",
    "manufacturer": "WEG",
    "model": "W22 Premium 75HP",
    "is_active": true
  }
}

sensor.registration v1.1

Declares or updates a sensor's lifecycle state. Tracks sensors from discovery through calibration to decommissioning, enabling fleet management and audit trails for measurement provenance.

{
  "spec_version": "2.0",
  "event_type": "sensor.registration",
  "event_id": "a8b9c0d1-e2f3-4a4b-5c6d-7e8f9a0b1c2d",
  "correlation_id": "a8b9c0d1-e2f3-4a4b-5c6d-7e8f9a0b1c2d",
  "source_event_id": null,
  "batch_id": null,
  "timestamp": "2026-03-05T11:20:00Z",
  "source": "wertek.iot.gateway",
  "content_hash": "b8c9d0e1f2a3b4c5",
  "asset": {
    "asset_id": "MOTOR-042",
    "asset_name": "Pump Drive Motor 42",
    "plant": "Plant A - Monterrey",
    "area": "Turbine Hall"
  },
  "data": {
    "sensor_id": "MCSA-T41-001",
    "registration_status": "registered",
    "sensor_model": "Wertek MCSA CT Module",
    "device_serial": "T41-2026-00042",
    "firmware_version": "1.0.3",
    "measurement_capabilities": ["current_waveform", "current_spectrum", "current_rms", "thd"],
    "calibration_date": "2026-03-05",
    "communication_protocol": "mqtt"
  }
}

maintenance.spare_part_usage v1.1

Records the consumption of a spare part during a maintenance activity. Links to the work order via work_order_id and enables inventory tracking, cost analytics, and procurement automation.

{
  "spec_version": "2.0",
  "event_type": "maintenance.spare_part_usage",
  "event_id": "e5f6a7b8-c9d0-4e1f-2a3b-4c5d6e7f8091",
  "correlation_id": "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
  "source_event_id": "d4e5f6a7-b8c9-4d0e-1f2a-3b4c5d6e7f80",
  "batch_id": null,
  "timestamp": "2026-03-09T10:15:30Z",
  "source": "wertek.cmms.inventory",
  "content_hash": "f6a7b8c9d0e1f2a3",
  "asset": {
    "asset_id": "PUMP-001",
    "asset_name": "Main Cooling Water Pump",
    "plant": "Plant A - Monterrey",
    "area": "Cooling Tower Area"
  },
  "data": {
    "work_order_id": "WO-2026-0042",
    "spare_part_id": "SP-SKF-6205",
    "quantity_used": 1,
    "part_number": "SKF 6205-2RS",
    "part_name": "Deep groove ball bearing 6205-2RS",
    "unit_cost": 28.50,
    "currency": "USD",
    "total_cost": 28.50
  }
}

6. Severity Standard

IAES defines five severity levels. They describe the condition of the asset, not the urgency of the maintenance response — priority on maintenance.work_order_intent carries that, and the two catalogues share the words low, medium and high while meaning different things by them. Neither may be presented as the other.

IAES defines no mapping from health_index to severity. The schema constrains health_index to the range 0–1 and severity to those five values, and leaves the relationship to the producer: a vibration model working from published evaluation zones and an oil-analysis model will divide the range differently, and both conform. A page of this site used to publish one such division as though the specification required it. It did not, and the ranges were a vendor's calibration; they are gone.

7. Idempotency

IAES provides three mechanisms for deduplication and idempotent processing:

1. event_id — Every event has a globally unique UUID. Consumers must track processed event IDs to avoid reprocessing.
2. content_hash — A deterministic hash of the data payload. Two events with the same content_hash for the same asset and event type are semantically identical.
3. correlation_id — Links related events. If a consumer already has a work order for a given correlation_id, it should not create a duplicate.

content_hash Computation

The content_hash is computed as follows:

1. Serialize the data object as canonical JSON (keys sorted alphabetically, no whitespace).
2. Compute the SHA-256 hash of the resulting string.
3. Take the first 16 hexadecimal characters.

8. Producers

IAES events are produced by systems capable of interpreting operational signals — not by the signals themselves.

A PLC, sensor, or gateway knows vibration_rms = 4.6. That is telemetry, not a diagnosis. IAES begins where interpretation begins: an AI model that classifies a bearing fault, a rule engine that triggers on a threshold, or a technician who hears cavitation.

Intelligence layer producers

Signal sources (upstream of IAES)

Operational systems such as PLCs, SCADA platforms, sensor gateways, and historians typically emit raw signals or measurements. These are converted into IAES events by downstream intelligence layers.

Industrial Signals              IAES Events
(PLC / Sensors / SCADA)         (semantic, interpreted)
      │                               │
      ▼                               ▼
  Telemetry Layer               ┌──────────────┐
  (OPC UA / Modbus / MQTT)      │  CMMS        │
      │                       │  Dashboards   │
      ▼                       │  Historians   │
  Intelligence Layer     ──────>│  Integrations │
  (AI / rules / human)         └──────────────┘

An edge device MAY produce IAES events directly if it has sufficient intelligence (e.g. edge AI, embedded rule engine). But the typical flow is: signals are ingested by an intelligence layer, which then emits IAES events.

The source field is what makes IAES vendor-neutral. A technician with a stethoscope and an AI model both produce the same asset.health event — the consumer doesn't need to know the difference.

9. Producer Guidelines

Required

1. Generate a unique event_id (UUID v4) for every event.
2. Set spec_version to "2.0" (or the version you implement).
3. Compute and include a valid content_hash for every event.
4. Use RFC 3339 timestamps in UTC with a timezone designator. RFC 3339 is a profile of ISO 8601: ordinal dates, week dates and some offset forms are valid ISO 8601 and are not valid RFC 3339. No schema enforces this in either direction, because format is an annotation in Draft 2020-12.
5. Include all required fields for the chosen event_type.

Recommended

1. Set correlation_id = event_id for the first event in a chain; propagate the same correlation_id for subsequent linked events.
2. Set source_event_id to the event_id of the directly upstream event.
3. Use the dot-notation format for source: vendor.system.subsystem.
4. Use failure modes from Appendix A when applicable.
5. Include ISO 14224 and ISO 13374 fields when the data is available to maximize interoperability.

10. Consumer Guidelines

Required

1. Validate spec_version and reject events from unsupported versions.
2. Implement deduplication using event_id or content_hash (see Section 7).
3. Ignore unknown fields in data without raising errors (forward compatibility).

Recommended

1. Use correlation_id to group related events for display and analytics.
2. Map IAES severity to your system's native priority/urgency model.
3. Store the full IAES event as an audit record, even after mapping to native format.
4. Implement retry logic with exponential backoff for transient processing failures.
5. Log rejected or malformed events for troubleshooting.

Severity Mapping Reference

11. Typical Flow

A typical IAES event chain follows this pattern. All events in the chain share the same correlation_id, and each event references its direct predecessor via source_event_id.

// All events share the same correlation_id
correlation_id: "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d"

// Event chain via source_event_id:
measurement  (event_id: AAA, source_event_id: null)
    ↓
health       (event_id: BBB, source_event_id: AAA)
    ↓
wo_intent    (event_id: CCC, source_event_id: BBB)
    ↓
completion   (event_id: DDD, source_event_id: CCC)
    ↓
spare_part   (event_id: EEE, source_event_id: DDD)

12. Event Type Usage Guide

When to use each event type, who produces it, and who consumes it.

Guidance: asset.measurement and sensor.registration are high-frequency by nature. Consumers building intelligence dashboards SHOULD filter by asset.health and maintenance.* event types for actionable signal. Raw measurements belong in time-series storage, not intelligence layers.

13. System Compatibility

IAES events are designed to map naturally to common industrial systems. The table below shows how IAES concepts map to each platform.

14. Versioning

Governance, the compatibility policy, and the change process are normative and live in GOVERNANCE.md. This section summarises how versions are numbered; GOVERNANCE.md states what implementers may rely on, which changes are compatible, how long a version is supported, and how a change is proposed.

IAES uses semantic versioning for the specification itself:

• spec_version in every event envelope identifies which version of the spec was used to produce it.
• Minor versions (1.1, 1.2) add new optional fields, new event types, or new triggered_by values. They never remove existing fields or change required fields. Consumers built for 1.0 SHOULD accept events from 1.x without error.
• Major versions (2.0) may introduce breaking changes: removing fields, changing required fields, renaming event types, or changing envelope structure. Consumers MAY reject events from unsupported major versions.
• Producers MUST set spec_version to the version they implement.
• Consumers SHOULD accept events where the major version matches, even if the minor version is higher than what they support.

Version history

15. References

What this specification depends on, and how much of that dependency its machine-validity artifact actually checks. Measured from the artifacts on 2026-09-06.

Two questions, and they are independent:

• Normative for meaning — must the value satisfy this document for the event to conform to IAES? That is decided by this specification.
• Enforced by the schema — does the schema reject a value that does not? That is decided by JSON Schema and by what the schemas actually declare.

They are not the same question, and where they disagree the disagreement is the defect.

An event can be schema-valid and non-conforming

Broken rather than read, against the validator this repository publishes:

timestamp = "banana" accepted event_id = "no-uuid" accepted correlation_id = "12345" accepted dataschema = "esto no es uri" accepted

Each of those satisfies the schema and violates this specification. An implementer can run the official validator, get green, and produce something this document forbids. That gap is the finding, not the accepted values.

Switching JSON Schema's format assertion on does not close it. Measured with the checker enabled, uuid is rejected while date-time and uri are still accepted, because their checkers live in optional packages — so whether an event is valid would depend on which packages the reader happens to have installed, and two conforming readers would disagree about the same bytes.

Why this is not simply fixed

The schemas already assert event_type, source, spec_version and currency with pattern, which every validator applies, while merely annotating the six identifier and date fields. No document says why the two groups are treated differently.

Adding a pattern to close the gap is not available inside 1.x: GOVERNANCE.md §4.2 lists adding a pattern where none existed as a narrowing change, therefore MAJOR, and the compatibility guard implements that. Values that validate today would stop validating.

So this is a decision with real consequences and it belongs in a memo, not in a references table. This section records the measurement the memo will need.

Three of these documents were unnamed until 2026-09-06. The schemas have always used uuid, uri, date-time and date, so the specification has always meant to depend on the documents that define them; it named none of them, and named ISO 8601, which JSON Schema does not use and which the editor does not hold. An implementer could satisfy the schema and had nowhere to read why.

The ISO 13374 entries say series rather than a part on purpose. The unqualified citations cover at least two different subjects — health status levels and a six-block processing model — which cannot both be the same part, and the editor holds only ISO 13374-4. A citation that does not identify a document cannot be checked. rfc/IAES-RFC-002.md withdrew the ISO 13374 attributions in 2.0; the field names are retained for compatibility with 1.x, and the values are declared as IAES's own.

Appendix A: Failure Mode Taxonomy

Standardized failure mode values for the failure_mode field in asset.health and maintenance.completion events. Organized by equipment domain.

Rotating Equipment

Electrical

Fluid & Thermal

Appendix B: ISO 14224 Codes

The iso_14224 object provides optional failure coding based on ISO 14224:2016 classification (Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data). This object can appear in asset.health and maintenance.completion events.

iso_14224 Object Structure

{
  "iso_14224": {
    "mechanism_code": "string",
    "mechanism_label": "string",
    "cause_code": "string | null",
    "cause_label": "string | null",
    "detection_method": "string | null",
    "detection_label": "string | null"
  }
}

Failure Mechanism Codes

Failure Cause Codes

Detection Method Codes

Appendix C: ISO 13374 Mapping

ISO 13374 (Condition monitoring and diagnostics of machines) defines a 6-block processing model for condition monitoring. IAES maps naturally to this standard. The iso_13374_status field in asset.health events provides explicit alignment.

iso_13374_status Levels

Usage Example

{
  "event_type": "asset.health",
  "data": {
    "health_index": 0.16,
    "severity": "critical",
    "failure_mode": "bearing_inner_race",
    "iso_13374_status": "imminent_failure",
    "iso_14224": {
      "mechanism_code": "1.1",
      "mechanism_label": "Mechanical wear",
      "cause_code": "D",
      "cause_label": "Operation / maintenance",
      "detection_method": "2",
      "detection_label": "Condition monitoring"
    }
  }
}

ISO 13374 Processing Model → IAES Events

Version History

License

IAES is an open specification licensed under CC BY 4.0. Implementations may be proprietary.

IAES v2.0 — September 2026 Created by the Wertek AI team. Implementations are listed in README.md. None of them is privileged: conformance is measured on the wire, not against any one of them.