The gap between a diagnosis and a work order

A model concludes a bearing is failing. A maintenance system has to act on it. Between the two sits an integration written by hand, every time.

The question this page answers is not what is IAES. It is the one people arrive with:

How do I send an asset-health diagnosis from a model to any CMMS without inventing another proprietary API?

Today the answer is: you write the integration. You choose a JSON shape, you pick a transport, you agree the field names with whoever is on the other end, and you do it again for the next pair. The work is not hard. It is just never finished, and none of it is reusable, because nothing about it was ever agreed anywhere.

The industry is not short of standards

Each of these settles something real. None of them settles this.

StandardWhat it settlesWhat it leaves open
OPC UA How to model and move values between industrial systems What a finished judgment looks like. A value is not a diagnosis
Sparkplug B Efficient, stateful telemetry over MQTT The same. It carries readings extremely well and says nothing about conclusions
Asset Administration Shell How to describe an asset as a digital twin What to emit when something changes about it
ISO 14224 How to record reliability and maintenance data How that record travels between two systems that never met

They occupy different layers, and IAES does not compete with any of them. An IAES event can ride Sparkplug B, be produced from OPC UA data, describe an asset an AAS models, and carry ISO 14224 codes. The missing piece is smaller and more boring than any of them: what a finished industrial judgment looks like on the wire, so that anything can emit it and anything can read it.

What the missing piece looks like

One envelope. Published event types. A pattern, not a closed list.

A diagnosis leaves the model as an event with a stable envelope: who produced it, about which asset, when, correlated with what came before, and a payload whose shape is published. The receiving system does not need to know the producer. It needs to know the envelope.

{
  "spec_version": "2.0",
  "event_type": "asset.health",
  "event_id": "3f2504e0-4f89-11d3-9a0c-0305e82c3301",
  "correlation_id": "3f2504e0-4f89-11d3-9a0c-0305e82c3302",
  "timestamp": "2026-09-08T14:22:05Z",
  "source": "acme.vibration",
  "asset": { "asset_id": "MOTOR-001" },
  "data": {
    "health_index": 0.31,
    "severity": "high",
    "failure_mode": "bearing_outer_race"
  }
}

That is the whole idea. The specification says what each field means and what a producer and a consumer must do; this page does not repeat it.

What it deliberately refuses to do

The refusals are the design. Each one is a thing a standard in this position is tempted to absorb.

No asset hierarchy. IAES carries an asset identifier and says nothing about what a plant, an area or a line is. Every organisation already disagrees about that, and a standard that took a position would be adopted by whoever happened to agree with it.

No equipment catalog. A pump is whatever the producer says it is. IAES does not ship an equipment taxonomy or an equipment catalog, so it does not need anyone to accept ours. It does publish a failure-mode taxonomy, in Appendix A, and that one is optional too.

No commercial terms. Nothing in the standard depends on any vendor's infrastructure, namespace or operating model — including the steward's. That boundary is checked mechanically in every repository carrying the IAES name.

No certification. Conformance is measured on the wire. A library claims the SDK profile and anyone checks it; nobody grants it. The steward is a vendor, and a rule that needs a vendor's judgment to be meaningful is not a rule.

No borrowed authority. IAES cites industrial standards where they supply a vocabulary, and citation is not conformance. Claims that could not be verified against the cited document were withdrawn rather than kept because they sounded good.

What you get for adopting it

One integration instead of N×M. A producer that emits IAES reaches every consumer that reads it, and a consumer that reads IAES does not break merely because the producer or the event type is new: the catalog is open, an unknown event_type MUST NOT cause an error, and an unsupported custom event may be logged and skipped.

An open specification under CC BY 4.0, with schemas that resolve at a permanent URI, SDKs in Python and TypeScript, nodes for Node-RED and n8n, and a compatibility policy that says in writing what will not break and for how long.

And an unusually blunt account of the limits: the specification publishes what its own schemas do not check, because an event can be schema-valid and still not conform. The philosophy explains why that is a feature.

Start Building with IAES

An open event standard, with production-ready SDKs and schemas you can resolve.