V.2.0 CFIHOS Implementation Guide For Principal
V.2.0 CFIHOS Implementation Guide For Principal
C-GD-001 2024
Acknowledgements
Its aim is to offer practical, standardized specifications for information handover that work
across the supply chain – operators, contractors and suppliers. The most recent CFIHOS
industry standard (Version 1.4) was published in October 2019 by USPI with support from
the Engineering Advancement Association of Japan (ENAA). This document, describing the
scope and procedures of CFIHOS, is part of this standard.
Following a member vote in 2019, the future governance, development, and maintenance
of the CFIHOS project and standard moved from USPI to IOGP in January 2020, becoming
Joint Industry Project (JIP)36.
Disclaimer
Whilst every effort has been made to ensure the accuracy of the information
contained in this publication, neither IOGP nor any of its Members past present or
future warrants its accuracy or will, regardless of its or their negligence, assume
liability for any foreseeable or unforeseeable use made thereof, which liability is
hereby excluded. Consequently, such use is at the recipient’s own risk on the basis
that any use by the recipient constitutes agreement to the terms of this disclaimer.
The recipient is obliged to inform any subsequent recipient of such terms.
This publication is made available for information purposes and solely for the private
use of the user. IOGP will not directly or indirectly endorse, approve or accredit the
content of any course, event or otherwise where this publication will be reproduced.
Copyright notice
The contents of these pages are © International Association of Oil & Gas Producers.
Permission is given to reproduce this report in whole or in part provided (i)
that the copyright of IOGP and (ii) the sources are acknowledged. All other rights are
reserved. Any other use requires the prior written permission of IOGP.
Page 2 of 31
CFIHOS – Implementation Guide for Principal
Page 3 of 31
CFIHOS – Implementation Guide for Principal
1.4.1 December 2020 Minor text changes to Section 3 ‘How to use the
CFIHOS Standard on a Project’ - following bug fixes
to the CFIHOS Standard to ensure continued
alignment.
1.5 October 2021 Minor change correcting spelling error in Figure B-1
1.5.1 2022-11 Minor text changes for bug fixes throughout the text
of the document
2.0 2024-10-31 Version 2.0, no change
Page 4 of 31
CFIHOS – Implementation Guide for Principal
Foreword
The Capital Facilities Information Handover Specification (CFIHOS) is an industry standard developed
to improve how information is exchanged between the companies who own, operate, and construct
equipment for the process and energy sectors. Starting with a common equipment naming
taxonomy and supporting specifications, its goal is to become a common language for the exchange
of information in these sectors.
The initial focus is on information, both structured data and traditional document formats, which
must be handed over when a project moves from its development to operations phase. Ultimately,
the aim is for CFIHOS to become the de-facto standard for information exchange throughout the
physical asset lifecycle, from vendor information through to decommissioning.
The Reference Data Library or “RDL” lies at CFIHOS’ heart. This library gives a standard and unified
naming convention for equipment, its attributes, disciplines, and documents. The CFIHOS RDL
includes:
A list of classes for Tag and Equipment (what the equipment does and what it is)
A list of properties (attributes, measures, characteristics etc.)
Lists of requirements by class (data and document requirements)
Standard unique coding of data to facilitate digital design and other workflows
A list of document types
A list of disciplines.
At present, CFIHOS covers only the exchange of structured data and documents - not graphical,
geometry, and model data. In the future, CFIHOS could be extended to include graphical and design
tool and support spare parts procurement, inspection, test requirements, commissioning check
sheets, Work Packaging, configuration management, and even drive payment.
CFIHOS is being developed collaboratively by project members as a practical standard to ensure the
systematic and reliable exchange of information between all participants involved in the information
supply chain, thereby reducing cycle times and costs. More than 70 organizations contributed to the
development of CFIHOS Standard, which is supported by several leading software industry design
tools.
Page 5 of 31
CFIHOS – Implementation Guide for Principal
Contents
Foreword............................................................................................................................ 5
1 Introduction................................................................................................................ 7
1.1 General............................................................................................................ 7
1.2 Scope............................................................................................................... 7
1.3 Target Audience............................................................................................... 7
1.4 CFIHOS Document Structure............................................................................7
1.5 Terms, Definitions, Acronyms and Abbreviations.............................................9
1.6 Information Management Principles and Processes in Projects........................9
2 Contract Information Requirements..........................................................................10
2.1 Contractual Information Requirements Overview...........................................10
2.2 Contract Information Management Scope of Work.........................................11
2.3 Contract Information Specification.................................................................11
3 How to use the CFIHOS Standard on a Project..........................................................12
3.1 Specify Information Requirements.................................................................13
3.1.1 Select CFIHOS Contract Scenario Template...................................................14
3.1.2 Identify Additional Project Specific Requirements..........................................14
3.1.3 Adjust CFIHOS Template for Local Needs.......................................................15
3.1.4 Generate Reference Data...............................................................................15
3.1.5 Add Reference Data to Specification..............................................................16
3.1.6 Finalize Contract Information Requirements..................................................16
3.1.7 Incorporate in Tender Documents..................................................................17
3.1.8 Adjustments Due to Bidder Clarification.........................................................17
3.1.9 Finalize Information Specification at Contract Award.....................................17
3.2 Generate Information Deliverable..................................................................17
3.2.1 Contractor Actions......................................................................................... 18
3.2.2 Principal Reviews and Validates Information Delivered..................................18
3.2.3 Principal Returns Comments..........................................................................19
3.2.4 Contractor Incorporates Comments...............................................................19
3.3 Handover of Information................................................................................19
4 Where to retrieve CFIHOS Documents, Tools and Templates....................................20
Annex A: Data, Information, and Documents...................................................................21
Annex B: Contract Scenario Templates............................................................................22
Annex C: Contract Information Requirements Package – Overview.................................30
Table of Figures
Figure 1 CFIHOS Document Structure................................................................................7
Figure 2 How to use CFIHOS on a Project - Overview.......................................................11
Figure 3 Process for creating a Contract Information Specification based on CFIHOS......12
Figure 4 Overview of the CFIHOS templates....................................................................13
Figure 5 Process for Generating Information Deliverable based on CFIHOS.....................17
Page 6 of 31
CFIHOS – Implementation Guide for Principal
1 Introduction
1.1 General
This document describes how to implement the Capital Facilities Information Handover Specification
(CFIHOS) from a Principal’s (Owner/Operator’s) perspective. This guide does not discuss the
expected organizational Information Management (IM) maturity required for effective
implementation of the Specification.
1.2 Scope
This document describes how to implement the CFIHOS standard:
Use of the specification in contracts for projects and assets
How to create a specification for the handover of engineering information between
Contractor and Principal that is tailored to the scope of the project or asset
How to use and adopt the CFIHOS Reference Data Library (RDL)
How to exchange information.
When using this document, it is recommended that the following should be referenced and
understood together:
CFIHOS Specification Document [C-SP-001]
CFIHOS Implementation Guide for Contractor [C-GD-002]
CFIHOS Reference Data Library [C-ST-001]
CFIHOS Data Model [C-DM-001]
CFIHOS Scope and Procedure [C-TP-001]
CFIHOS Contract Scenario Templates.
For further instructional material on how to read the CFIHOS Data Model, refer to the Data
modelling Training Material [C-DM-901] on the CFIHOS SharePoint site.
Page 7 of 31
CFIHOS – Implementation Guide for Principal
It is recognized that Principals may have different ways of organizing their contract documents for
Capital Projects. For example, some Principals might include detailed descriptions of requirements
within a Scope of Work, whereas others’ Scopes of Work might be a high-level description, with
detailed requirements described in separate Specifications and Administration or Coordination
Procedures.
Another difference is that some Principals collect all of their Information Requirements into a single
Information Management Scope of Work, whereas others define Information Requirements
alongside requirements for different parts of the Scope of Work.
However the Principal chooses to organize its Information Requirements, the following must be
included in order to benefit from the CFIHOS standard:
Page 8 of 31
CFIHOS – Implementation Guide for Principal
This symbol identifies important points to consider for the specific section where it is located.
Contract Information Management Scope of Work (IM SoW): In this contractual document the
Principal specifies the terms and conditions for information delivery by the Contractor. Where it is
applicable and feasible, quality benchmarks and criteria on how the Contractor is to fulfil these
requirements may be included. For any details there could be either referred to specific specification
documents or included in the scope of work. The term Project Information Management Scope of
Work can also be used.
CFIHOS Scope and Procedure document [C-TP-001] is used as a reference to create the project or
contract specific Information Management Scope of Work.
Contract Information Specification (CIS): The resulting document when this CFIHOS industry
guideline is applied to a particular project describing the specific set of requirements to be fulfilled.
Linked to this document is a Reference Data Library that describes the data characteristics and
document types.
The CFIHOS Specification Document is the basis for creating a project or contract specific
Information Specification.
Discipline Document Type: An association between Disciplines and Document Class names. In the
CFIHOS context, the term Discipline Document Type is a unique identifier for types of documents,
which allows deliverables to be specified and content owners to be assigned by discipline. This term
has been developed to cater for situations where a document class is common to more than one
discipline. For example, a Data Sheet can be produced by different disciplines depending on the
nature of the associated equipment.
Contractor (EPC Contractor): This is the party that carries out all or part of the design, engineering,
procurement, construction, commissioning or management of a project or operation of a facility.
The Principal may undertake all or part of the duties of the Contractor.
Principal (or Owner / Operator): This is the party that initiates the project and ultimately pays for it.
The Principal may also include an agent or consultant authorised to act for, and on behalf of, the
Principal.
Prime Contract: This is the main contract for the project/scope of work between the Principal and
the Contractor. There might be additional sub-contracts related to the project/scope of work, which
must refer to the main contract and its terms and conditions - for example, contracts between
contractor and sub-contractors.
Reference Data Library (RDL): Reference Data Library of the metadata of Data and Documents
described in CFIHOS Specification Document [C-SP-001]
Page 9 of 31
CFIHOS – Implementation Guide for Principal
From a Principal perspective, the information management process involves three steps:
1. Specify the Information Requirements to support both project execution and
operations/maintenance activities. CFIHOS seeks to establish a consistent industry standard
for such Information Requirements, to make the process of specifying easier and to reduce
the cost of the information asset. The overall Information Requirements are contained in the
Prime Contract.
2. Control the content to validate that the information generated by Contractors,
Suppliers/Manufacturers (Vendors) and others is compliant with the Information
Requirements; to track quality, progress and completeness against the Contract Information
Specification (CIS). Controls should ideally be executed as closely as possible to the source of
information to reduce the time and cost of correcting any issues.
3. Capture, Handover, Use & Share the information asset to optimize its value, e.g. from
Suppliers/Manufacturers (Vendors) to Contractors to Principal Project and Asset Operations
teams.
The focus of this guidance is on step 1, i.e. how to use the CFIHOS standard to select and specify
Principal’s Information Requirements to Contractors and other parties contracted by the Principal.
The objective of the Principal typically is to ensure that the Contractor delivers the minimum set of
information required to effectively execute the project and manage its projects and assets. To this
end, the Information Requirements need to be articulated and embedded in the Prime Contract.
These Information Requirements normally consist of the following elements to be created by the
Principal (based on the CFIHOS Standard) and contractually mandated to the Contractor via the
Prime Contract:
Page 10 of 31
CFIHOS – Implementation Guide for Principal
and management.
Depending on the structure of each Principal’s Prime Contract, the contractual requirements
covering information management and handover may not necessarily be centralized into a single
Information Requirements Package and may be found dispersed throughout the Prime Contract.
However, in this guide, the terms “Information Requirements” and “Information Requirements
Package” have been used interchangeably as described above.
In addition to the Information Requirements, the complete Contractual Requirements include the
Technical Requirements, also containing Scope of Work and Specifications. The Information
Requirements will cover the handover of the information asset, while the Technical Requirements
cover the physical asset.
Note: The specification for the internal processes of the Contractor or the Principal is not part of the
scope of CFIHOS and are not covered in this document. The Technical requirements for the physical
asset are not within the scope of CFIHOS and are also not covered in this document.
The goal of the Contract IM SoW document is to define the scope, processes, interdependencies and
acceptance criteria for the exchange and handover of information between Contractor and Principal.
It should allow Contractor to understand the expected deliverables, their timing and other success
criteria, and it should enable the Principal to monitor the quality and progress of information
creation and delivery in a progressive manner before the final handover. In summary, the IM SoW
will point to the relevant Contract Information Specification (which identifies what information
needs to be delivered in executing a contract). The IM SoW will then also typically define (See
CFIHOS Scope & Procedure Document [C-TP-001] for details):
IM Standards
Information Lifecycle, principles and security
Manage Information and Data
Change Management
Interface Management
Data Governance
IT requirements related to IM
IM organization and roles
IM processes, activities, phases and milestones.
Page 11 of 31
CFIHOS – Implementation Guide for Principal
full generic “super-set” of information that may be produced in a project. Principals may choose to
augment this “super-set” of requirements with their project specific requirements.
However, Principals are encouraged to challenge and consider the costs vs. benefits of their
additional requirements. In practice, information delivery is phased over time and the information
delivery scope is split into individual packages. To facilitate implementation, CFIHOS therefore
defines five templates that reflect typical contracting scenarios, and which can be tailored to reflect
the scope of information to be delivered by a Contractor. These contract scenario templates are:
This chapter describes how the CFIHOS Standard should be applied to a project. As shown in Figure 2
below:
Section 3.1 explains how to use CFIHOS to Specify Information requirements - from a
Page 12 of 31
CFIHOS – Implementation Guide for Principal
Working through these steps for the first time will take some time, but the generated templates can
be reused for future projects, and the deliverables may be re-used in the asset that is created by the
project for future Brownfield modifications.
The Information Requirements should include not just information deliverables for
Engineering and Construction, but also any requirements that need to be passed from
prime Contractors to Vendors or Sub-Contractors
Page 13 of 31
CFIHOS – Implementation Guide for Principal
Template 2: FEED
Information specification template containing the Information Requirements for a Front-End
Engineering Design (FEED) Contract. In the FEED template, the procurement or delivery of
any hardware, and the associated information is considered to be out of scope
1. Information requirements not covered by CFIHOS: These may include corporate practices or
scope not currently included in CFIHOS. Examples include:
Project specific list of document deliverables
Engineering Discipline or other technical data in any specific application format
Page 14 of 31
CFIHOS – Implementation Guide for Principal
3D Model data in any specific format with specific reference data / Reference documents
and catalogues.
3. Brownfield projects may decide to comply with the numbering and classification structure of the
original asset, in which case such specific requirements should be included at this stage. A result
is a draft Contract Information Specification template that includes Project specific Information
Requirements, a pre-defined information model (entities and fields) and relevant reference
documents.
The changes identified are incorporated into the project template. Finally, if Principal identifies
additional properties which extend beyond those provided in the current version of the RDL, these
should also be incorporated into the project template.
The result is a draft Contract Information Specification that includes Project specific Information
Requirements with a pre-defined information model (entities and fields) and reference documents in
compliance with local requirements.
The RDL is organized as a series of Comma-Separated Values (.CSV) files containing Object
definitions, Tag list, Equipment list, Properties, Units of Measure, Document Types, Pick Lists and any
CFIHOS unique identifiers. The CFIHOS Specification document describes the information model that
ties the RDL CSV’s together.
Page 15 of 31
CFIHOS – Implementation Guide for Principal
The CFIHOS Contract Scenario Templates, described in Section 3.1.1, show the standard expected
RDL CSV’s that should be selected for various Capital Project hand-over scenarios.
In this step, the CFIHOS RDL is tailored to specify the reference data that is expected for the specific
contract scope. The Principal will need to adjust this information model according to their business
requirements and objectives and ensure that the appropriate RDL CSV’s are selected for the
Information Specification created.
The Principal may be able to start to populate the template with reference data already available
from an engineering information repository/Engineering Data Warehouse that will be utilised to
publish the quality checked information during the project. The Principal should also ensure that
any software templates to be furnished by the Principal for use by the Contractor are compliant with
the RDL.
This reference data set can then be attached to the Information Specification. It is recommended to
compile each reference data table into a document with a document and version number so that
any updates can be re-issued as new versions of the reference data pack.
Additionally, relevant reference documents should also be attached. These may include: document
numbering and control procedures, tagging procedures, other data management procedures, etc.
At this point the Contract Information Specification, Reference Data Library, and Reference
Documents are complete.
If milestone payments or other incentives are intended to be used, these need to be defined and
aligned with requirements from other disciplines.
For example, there would be no value in defining a milestone based on the delivery of certain
documents if the responsible discipline does not need them until later in the process.
This step should ensure that delivery of the required information is specified clearly with the correct
timing to meet the needs of different users. For example, equipment information is often targeted
for delivery before commissioning but is also often crucial for to the construction contractor for the
definition of construction work packages and should ideally be targeted for delivery before
construction.
The result of this step is a complete Contract Information Requirements Package consisting of an IM
Scope of Work and a Contract Information Specification that is ready for inclusion in the Tender or
Contract documentation.
Page 16 of 31
CFIHOS – Implementation Guide for Principal
Page 17 of 31
CFIHOS – Implementation Guide for Principal
These steps are discussed in detail in the CFIHOS Implementation Guide for Contractors.
The Contractor needs to understand the Information Requirements, deciding how to meet the
requirement and then configure internal information systems to comply with CFIHOS. The
Contractor also needs to specify CFIHOS compliant deliverables in any sub-contracted work.
Typically, the first 6-9 months of this work is most intense, and much effort should be anticipated to
get the configuration right and the required sub-contracts in place.
Once this is in order, the process of delivery becomes more of an ongoing cycle between the various
parties to receive, review and finalize individual information sets, so as continuously complete
information delivery.
The Principal conducts review and validation steps. Pending the priority and criticality of the
information delivered, the Principal decides on the thoroughness of control of the information. In
case of errors or anomalies, the Principal sends notice to the Contractor for correcting the error,
with an indication of the type of the detected error/anomaly.
The correction follows the same process as the initial creation process. The internal approval and
review process of the Contractor can be different when processing corrections, this should be
defined within the Contractors project quality assurance process and depends on the classification of
the error and the priority and criticality of the information.
Typically, the Principal runs two parallel review processes, one to address deliverables in document
format that is typically reviewed in accordance with a document control process, and a second
process to address deliverables in data formats that are typically more of a “back-office” process to
ensure data compliance, consistency, and more. Joint reviews of larger data deliverables such as 3D
models may also be organized at regular intervals. The results of these parallel reviews are
consolidated together for transmittal back to the originator.
Page 18 of 31
CFIHOS – Implementation Guide for Principal
If the information meets all requirements stated in the Contract Information Specification, the
Principal formally acknowledges that the information was delivered according to the agreed
requirements.
Note that comments should not be used for managing scope changes. If there is a
scope change, the Principal should re-start the process with a change specification.
Note that the quality procedures of the Contractor should cover the process of
handling comments received from the Principal. These procedures should include
guidelines about review and approval, logging and disposition of the remarks.
Typically, the Operations applications used for plant operations and maintenance would be different
from those used for Project execution. A system for validation and transformation and loading of the
required subset of project collected data will usually be required.
A project information handover plan will be in place. This should cover the general scope, role,
responsibility, schedule, Quality Control of information to be handed over from project to
Operations covering all forms of information (document, data, database/model) from the project
team, contractors, and vendors. This plan should also outline how interfaces between various parties
(Owner Project team, Contractors, and vendors) will be managed at various stages of the handover
process. More details in the CFIHOS Scope and Procedure Document [C-TP-001].
Page 19 of 31
CFIHOS – Implementation Guide for Principal
All documents relating to the CFIHOS Standard are published on the CFIHOS website and can be
downloaded from here.
Narrative Documents
Scope and Procedures (C-TP-001)
Specification Document (C-SP-001)
Implementation Guide for Principal (C-GD-001)
Implementation Guide for Contractor (C-GD-002)
Reference Data Library
Reference Data Library (C-ST-001) – Excel version
Reference Data Library (C-ST-001) – CSV zip file
Data Model
Using the Data Model (C-DM-001) – Powerpoint
version
Data Dictionary (C-DM-002) – Full version
Data Dictionary (C-DM-002) – Light version
Supporting Templates
Contract Scenario Templates
Page 20 of 31
CFIHOS – Implementation Guide for Principal
When Data identifies and describes pieces of information, correspondences or documents including
drawings, it is called document metadata. On the other hand, metadata defines data (entities and
attributes in relational databases) by their structures (data models), data dictionaries and reference
data libraries.
Page 21 of 31
CFIHOS – Implementation Guide for Principal
The CFIHOS Project delivers five generic information management specification templates. Industry
experience shows that these covers more than 90% of potential cases across the lifecycle of a plant.
The templates must be customized to produce an information management specification to meet
the specific needs of a contract.
The lifecycle phases that a plant may go through are defined in the CFIHOS RDL Picklist Activity ‘life
cycle activity class’.
The asset is not static during operation but undergoes continuous change through a management of
change process. For larger changes the same phases apply (brown field project).
Templates
The information scope is covered by the following templates:
Template 2: FEED
Information specification template containing the Information Requirements for a Front-End
Engineering Design (FEED) Contract. Procurement or delivery of any hardware is out of scope.
Page 22 of 31
CFIHOS – Implementation Guide for Principal
Page 23 of 31
CFIHOS October
C-GD-001 2024
Page 25 of 31
CFIHOS – Implementation Guide for Principal
Page 26 of 31
CFIHOS – Implementation Guide for Principal
Page 27 of 31
CFIHOS – Implementation Guide for Principal
Page 28 of 31
CFIHOS October
C-GD-001 2021
The selected template forms the basis of the draft Contract Information Specification. Copy the
template and rename it appropriately according to your company standards and guidelines.
The template specifies what information a Principal should deliver to a Contractor (e.g. naming
conventions, classifications etc. to be used) and what information the Principal expects to be
delivered back by the Contractor (e.g. design data and equipment documentation). Note that this
can differ from contractor to contractor even for the same type of information, depending on the
capability (maturity) of the contractor, equipment suppliers and the requirements for the exchange
of information. The result of this first step is a draft Contract Information Specification template.
While each of the CFIHOS templates identifies Plant Breakdown Structure objects that
would typically be delivered for the kind of project, consideration should be made for
the actual project scope. The scope of a particular project may well alter what is
included. For example, if long-lead items are included in a FEED contract scope, the CIS
should include the CFIHOS “Equipment” object and its properties – which would be a
deviation from the template. As such no CFIHOS PBS object or properties are marked
as mandatory to be delivered, what is mandatory for the Contractor to deliver would
depend on the specific requirements of a project/asset.
Within the definition of the data requirements in the CFIHOS specification, the
Principal will need to indicate whether or not the contractor is required to deliver
specific attributes. For example, in a FEED Contract, while a Contractor may be
required to deliver the Plant Breakdown Structure “Tag” data, this may be limited to
only 50% of such Tag properties defined by CFIHOS, because of the project’s particular
scope.
1. Principal selects a CFIHOS Template. The CFIHOS Template defines the structure of the
information to be delivered. Principal needs to decide on the standards to be used.
2. Principal adjusts the CFIHOS Template to create an information specification that reflects the
identified business Information Requirements. This may mean removing some elements
from CFIHOS as they are not required or adding new elements to satisfy local business
requirements.
3. Principal selects the relevant reference data (i.e. classes, properties, document types, etc.)
for use with the information specification. Ideally, these will be selected from the CFIHOS
RDL but may also include additional company and/or project specific reference data.
4. Principal aligns the reference data with the information specification according to selected
business standards. (For example, document type requirements for As-Built documents
completed, etc.)
5. Principal finalizes the information specification and the reference data files.
Note that the Contractor may return clarifications which may prompt the Principal to amend the
information specification or reference data.
CFIHOS – Implementation Guide for Principal
Page 30 of 31
CFIHOS – Implementation Guide for Principal
Page 31 of 31