Introduction
A new petrochemical plant reaches mechanical completion, but the operations team still can't locate a reliable equipment list. Sound familiar?
This scenario plays out across capital-intensive industries every year. EPCs hand over thousands of documents and tags to owner-operators, but the data structure behind them rarely matches what operations actually needs.
The cost shows up fast. Industry professionals estimated that a standardized project information handover specification could improve project delivery time by roughly 8.26% and boost post-delivery asset availability by 7.57%, according to IOGP's 2019 Data Standards Opportunity Survey.
Without a shared data structure, teams re-key information, delay start-up, and carry unnecessary compliance risk into operations.
This article breaks down what the CFIHOS data model is, its core components, how it functions on real projects, and what successful implementation actually requires.
Key Takeaways
- CFIHOS standardizes EPC-to-owner data exchange through a normalized structure, not a flat tag list
- The model runs on entities, attributes, reference data, and unique identifiers for consistency
- Successful adoption hinges on clear ownership, phased rollout, and disciplined governance
- Specialized AIM expertise helps migrate, enrich, and validate legacy data to CFIHOS
What Is the CFIHOS Data Model?
CFIHOS stands for Capital Facilities Information HandOver Specification. It's an open, industry-developed data standard built to structure and exchange asset information, primarily across oil and gas and broader process industries.
The standard didn't emerge from a committee dreaming up theory. In 2012, Shell asked USPI, a process-industry standards organization, to turn its internal Engineering Information Specification into an industry-wide standard capable of serving the entire process-industries supply chain. USPI coordinated development for seven years, publishing Version 1.4 in October 2019.
Governance shifted in January 2020. IOGP (the International Association of Oil & Gas Producers) now maintains CFIHOS under Joint Industry Project 36 (JIP36). The latest major release, CFIHOS Version 2.0 with Extended RDL, launched in November 2025 and is described as the standard's most extensive update yet, according to JIP36's official standards page.
Who Governs and Uses CFIHOS
JIP36 currently counts nearly 80 member organizations and more than 350 contributing individuals. Membership spans:
- EPC contractors
- Equipment suppliers and other institutions
- IOGP and non-IOGP owner-operators
- Software vendors and consultants
That breadth of participation means CFIHOS reflects industry consensus, not the preferences of a single owner or vendor. Adoption isn't legally mandated. Instead, owners typically write CFIHOS requirements into the prime contract's Information Management Scope of Work, making it a contractual expectation rather than a regulatory one. The standard's documents are free to download, which has helped it spread across the supply chain, letting smaller vendors and EPCs adopt it without licensing costs standing in the way.
Where CFIHOS Fits in the Asset Lifecycle
Most people associate CFIHOS with project handover, and that's where it earns its name. But the structured information it produces keeps working long after start-up.
Operations and maintenance teams rely on that same tag and equipment data for years. As organizations build out digital twins and predictive maintenance programs, a normalized CFIHOS dataset becomes the foundation those initiatives depend on, rather than a one-time deliverable that gets archived and forgotten.
Key Components of the CFIHOS Data Model
CFIHOS goes well beyond a spreadsheet of tag numbers. The standard defines a normalized relational structure, published across five core elements: a technical specification, a data model, implementation guidance, a data dictionary and Reference Data Library (RDL), and implementation-software requirements.
Here's what that structure actually contains:
Entities (Tables) Each entity represents an object type, such as Tag, Plant, Equipment, or Corrosion Loop. Every entity groups the data points relevant to that object, so all Equipment-related information lives in one defined place rather than scattered across disconnected spreadsheets.
Attributes (Fields) Within each entity sit defined attributes, like Tag Name or Tag Description, each with a specified data type, format, and validation rule. This is what separates CFIHOS from an ad hoc naming convention: the fields are pre-defined, not invented project by project.
Foreign Key Relationships Many attributes link directly to other entities. A Corrosion Loop Code on an Equipment record, for instance, points back to the Corrosion Loop entity itself. These relationships:
- Enforce data integrity across the model
- Prevent duplicate or conflicting entries
- Create a relational web that mirrors how physical assets actually relate to one another
Reference Data Library (RDL) The RDL supplies pre-populated, standardized lookup values, covering tag classes, equipment classes, disciplines, document types, pick lists, and units of measure. Rather than each project party inventing its own list of valid values, the standard supplies them. Some values even tie to external references, such as explosion-protection concepts referenced to EN 50014.
Unique Identifiers Every table, field, and reference value carries a permanent, unique ID assigned by the CFIHOS project itself. That persistent ID enables traceability across versions. It also lets different software systems reference the exact same data element without ambiguity, which matters when EPC and owner platforms need to talk to each other.
How the CFIHOS Data Model Works in Practice
CFIHOS assigns responsibility for delivering specific data, not just defining what the data should look like.
Built-in Ownership
The Principal (typically the owner) defines the project's information-management requirements upfront, while the Contractor (the EPC) delivers against those requirements through the contract's Information Management Scope of Work. The Reference Data Library, or RDL, supplies the controlled vocabulary both sides draw from.
Each role covers distinct ground:
- Principal: Sets Plant Breakdown Structure values like Site, Plant, and Process Unit, plus numbering, tagging, and drawing conventions
- Contractor: Delivers Tag-level data limited to the contracted scope, per the Information Management Scope of Work
- RDL: Provides the shared vocabulary that keeps both sides aligned
That division matters because it clarifies who's accountable for what, before disputes start.
Phased Adoption, Not All-or-Nothing
Organizations rarely implement every table and attribute on day one. Official guidance notes that information delivery is typically phased over time and split into individual packages, with the first six to nine months of configuration work being the most intense.
Teams select the tables and attributes relevant to their project scope and build out from there.
Flexible Exchange Formats
CFIHOS handover data can move between systems in several formats, including databases, XML, and CSV, depending on what the Principal specifies for the project. This flexibility lets EPC and owner platforms exchange structured data without forcing a single rigid file format on every project.
Why the CFIHOS Data Model Matters for Asset-Intensive Industries
Poor handover data creates costly disputes, rework, and delayed start-up between builders and operators. IOGP's survey work reflects why the industry keeps investing in fixing it. The estimated 8.26% improvement in project delivery time cited earlier isn't a guarantee, but it captures why owner-operators keep pushing for standardized handover specifications.
Safety and compliance benefits
The RDL's structured lookup values extend to safety-relevant properties, including explosion-protection classifications referenced against recognized standards like EN 50014. Consistent capture of these safety-critical attributes gives compliance and operations teams a dependable, auditable record instead of inconsistent notes buried across disparate documents.
A foundation for digital transformation
Normalized, well-structured data is more compatible with modern analytics tools than a pile of inconsistent spreadsheets. Organizations building digital twins, predictive maintenance models, or advanced analytics platforms get there faster when the underlying asset data already follows a consistent, relational structure. That's the practical payoff behind all the standardization work: less time spent cleaning data, more time spent using it.
Common Implementation Challenges — and How ReVisionz Helps
CFIHOS delivers real value, but getting there isn't simple. Most organizations run into the same friction points.
The scale problem. Hundreds of interrelated tables and attributes can overwhelm internal teams that don't have dedicated data governance resources. It's easy to underestimate how much configuration work sits behind "just adopting a standard."
The brownfield problem. Legacy asset data almost never maps cleanly onto CFIHOS's normalized structure. Years of inconsistent tagging, duplicate records, and missing attributes require serious cleansing, migration, and enrichment effort before the data is usable.
The alignment problem. Getting EPCs, owners, and technology vendors to agree on a shared responsibility matrix, without a common methodology guiding that conversation, tends to cause friction and rework late in the project.
ReVisionz's Asset Information Management (AIM) practice exists to close these gaps. The team applies a proven data migration and enrichment methodology to map, cleanse, and validate asset data against standards like CFIHOS, whether the project is greenfield or a brownfield environment carrying decades of inconsistent records.
In one engagement, the team rebuilt trusted asset registry records within a client's existing Maximo system with zero rework. The client later requested the same approach for a subsequent greenfield project.
For organizations looking to accelerate that work, ReVisionz's AI-powered Main Information Contractor+ (MIC+) service speeds up lifecycle-ready data transformation. It also reduces the manual errors that creep into large-scale enrichment efforts.
Speed and automation help, but implementation still needs to fit each client's environment. Because ReVisionz takes a technology-agnostic approach, clients can implement CFIHOS in phases that align with their existing systems, project maturity, and business priorities, rather than being pushed toward a one-size-fits-all rollout.
That flexibility shows up in engagements like establishing handover standards to support startup readiness, where structured governance was built around the client's actual operating environment.
Frequently Asked Questions
What is the CFIHOS data model?
CFIHOS is a standardized, normalized data model used to structure asset information exchanged between EPCs and owner-operators during capital project handover. It defines entities, attributes, and relationships rather than relying on a flat tag list.
What are the components of a data model?
Core building blocks include entities (tables), attributes (fields), relationships between entities (foreign keys), and reference or lookup data. CFIHOS applies all four through its data dictionary and Reference Data Library.
Who governs and maintains the CFIHOS standard?
IOGP maintains CFIHOS through Joint Industry Project 36 (JIP36), having taken over governance from USPI in January 2020. Nearly 80 member organizations drive periodic, community-based updates to the standard.
Is CFIHOS mandatory for oil & gas capital projects?
No. Contractual or owner requirements written into the Information Management Scope of Work typically drive adoption, not legal mandate. The industry treats it as best practice rather than a regulatory obligation.
How does CFIHOS differ from other data standards like ISO 15926?
CFIHOS is a practical, handover-focused specification defining specific tables, attributes, and reference values. ISO 15926-2 is a broader conceptual data model and ontology framework designed for representing lifecycle information across process plants generally.
How long does it typically take to implement the CFIHOS data model?
Timelines vary based on scope, whether full or phased adoption, data readiness, and governance maturity. Official guidance notes the first six to nine months of configuration tend to be the most intensive period.
