The process industry does not lack standards activity. What it still lacks, in many cases, is dependable execution between engineering systems.
That distinction matters. DEXPI 2.0 is now available, and the broader lifecycle-information conversation has also moved forward with the publication of the new PIDMIC best-practice document on asset lifecycle information management. The direction is encouraging. But progress at the standards level does not automatically create continuity in live project environments.
The real problem is familiar to anyone involved in engineering data handover. Information is created across multiple disciplines, tools, contractors, and project phases. Even when everyone agrees on interoperability in principle, continuity still breaks in practice: between process and plant data, between EPC tools, between project delivery and operations, and between document packages and the structured information that should make them usable.
That is why the recent PIDMIC publication matters. It frames lifecycle information management as an industry-wide challenge involving structured engineering and operational information across the full asset lifecycle. It promotes model-based engineering, interoperable vendor-neutral data structures, and less dependence on document-centric workflows. That is a useful step forward. It also makes the deeper point: the hard work begins after the standard is published.
DEXPI’s own 2.0 release reinforces the same point. The specification defines a standardized data model for plant and process models, expands support for process industry requirements, and is the first version that fully uses DEXPI XML without relying on the older Proteus XML schema. That is real progress. But better schemas do not remove the need to solve ownership, validation, version control, and change propagation across systems and organizations.
For engineering managers, interoperability should be treated as a delivery capability, not only a compliance topic. If tags, objects, and attributes do not remain coherent across tools and revisions, the cost appears as rework, manual checking, delayed decisions, and fragile downstream automation.
For EPCs, the implication is equally direct. A project can look digitally mature while still handing over information that is difficult for the owner-operator to absorb. Delivering more files is not the same as delivering more usable lifecycle information.
For digitalization leaders and owner-operators, the bigger lesson is that interoperability is as much an operating-model problem as a technical one. Standards such as DEXPI and CFIHOS create a common basis for exchange and handover, but they do not decide who owns data quality, how engineering intent is preserved across lifecycle phases, or how changes propagate through connected systems. CFIHOS itself is framed around safer, faster, standardized information handover, which is necessary, but not sufficient on its own.
This also connects directly to the wider AI and digital-twin discussion. ISO/IEC 5259-5:2025 formalizes a governance framework for data quality in analytics and machine learning, reinforcing a point many industrial companies are now running into: higher-level automation ambitions depend on trustworthy underlying data. The same applies to engineering information. If system-to-system execution is weak, every digital initiative built on top of it becomes more brittle than it looks.
The opportunity is not just broader adoption of DEXPI. It is using that momentum to force a more serious conversation about execution reality.
Standards matter. They create the conditions for interoperability. But the practical advantage will go to the companies that treat engineering data as operational infrastructure: governed, connected, and managed across the lifecycle rather than handed over as a project afterthought.
That is where interoperability stops being a presentation topic and starts becoming a capability.