CFIHOS, Explained. What Instrumentation Engineers Actually Hand Over.
CFIHOS, JIP36 defines the data an owner-operator receives at handover. Tag classes, ISDD properties, document links, and as-built reconciliation.
CFIHOS, Capital Facilities Information HandOver Specification, said "see-foss" is the standard that defines what structured data an owner-operator needs to run a facility, and the form the EPC has to deliver it in. It has been governed by IOGP as JIP36 since 2020, and the current release is V2.0, out in late 2025. Every document is free from jip36-cfihos.org.
For an instrumentation engineer it reduces to one obligation. Every tag you own gets classified against a Reference Data Library class, its required properties filled in as real data, its documents linked, and the register reconciled against the as-built drawing before handover closes. The rest of this is what that means in practice.
The short version
- CFIHOS defines what the owner-operator receives and in what structure. It is not software and not a file format.
- Five parts. The specification, the data model, the Reference Data Library, RDL, implementation guides, and software requirements.
- You own the tag objects. The owner owns the plant hierarchy. The vendor stream supplies equipment data. All three meet before handover.
- Signal class, AI, AO, DI, DO and controller allocation are properties on the tag, not a separate spreadsheet.
What CFIHOS is, and what it is not
CFIHOS solves one problem. At the end of a project, the data for a single instrument lives in a dozen incompatible systems, and the operator's CMMS, EAM, and DCS have to absorb the gap. The standard fixes the target so every contractor hands over the same shape of data.
It is not.
- Software. Hexagon SDx, AVEVA AIM, Omega 365, Sharecat, and others implement it. The standard itself is documents plus a downloadable RDL.
- Mandatory on its own. It binds only when an owner-operator writes it into the contract.
- A drawing format. That is DEXPI's job.
- A schema you design. The RDL is handed to you. You classify against it.
It began as a Shell initiative inside USPI in 2012, moved to IOGP as JIP36 in 2020, and now has roughly 80 member organisations behind it. Operators, EPCs, equipment suppliers, and software vendors.
The five parts
| Part | Identifier | What it covers |
|---|---|---|
| Specification | C-SP-001 | Scope, requirements, the handover procedure. The contract document. |
| Data model | C-DM-001 | How objects, classes, properties, and documents relate. |
| Reference Data Library, RDL | jip36-cfihos.org, posccaesar.org | The class, property, and unit dictionary. Extends ISO 15926 Part 4. |
| Implementation guides | C-GD-001, owners, C-GD-002, contractors | What each party has to do. |
| Software requirements | Separate document | What a compliant tool must support. |
The RDL is where you spend your time. At V1.5.1 it ran to 139 tables and 665 fields, which is exactly why V2.0 split it into a mandatory Core and an optional Extended set.
Tag Class vs Equipment Class
Every object in the RDL has a class type. Two matter to you.
| Class type | Represents | Who owns it | Example |
|---|---|---|---|
| Tag Class | The functional instrument, as tagged on the P&ID | Instrument engineer | FT-101, classified as a flow measurement device |
| Equipment Class | The physical item, purchased and installed | Vendor, confirmed by EPC | The actual transmitter body, make, model, serial |
| Both | A logical and a physical identity on one object | EPC and vendor | A control valve. Tag FCV-302 plus body, actuator, positioner |
This is the split you already work with. The tag is functional. It is on the P&ID, it has a loop number, a signal class, a SIL requirement. The equipment is physical. A purchase order, a serial number, a datasheet. CFIHOS wants both, linked.
ISDDs, Industry Standard Datasheet Definitions sit inside this. An ISDD names which datasheet fields for a class have to be structured data instead of a line in a PDF. Design pressure, process connection, sensing principle. Those become queryable attributes. Everything else can stay in a linked document.
What is actually yours to produce
Most CFIHOS write-ups describe what the owner receives and skip what you do to make it. Four things are yours.
A tag register classified to the RDL. Every tag on the IFC set mapped to its Tag Class, carrying the properties that class marks mandatory. For a pressure transmitter. Design pressure, process connection, output range, sensing principle. For a SIF. SIL class and proof-test interval.
Structured datasheet properties. Only the fields the ISDD names have to be data. The rest can stay in a linked document. Your job is to know which ISDD applies to each equipment class and fill it.
Document links off each object. Calibration record, loop diagram, vendor datasheet, commissioning record, each tied to the tag or equipment object, not buried in a folder no system can read. The operator then pulls the loop diagram for PT-101 by querying the tag, not by searching a file server.
As-built reconciliation. The register has to match the as-built P&ID. Construction changes, commissioning additions, and late revisions all pull the two apart, and closing that gap is yours before the conformance check passes. V2.0's automated check surfaces the gaps earlier. It does not resolve them for you.
Why handover data rots
The failure is structural, not personal. At project end the same instrument exists in the engineering tool, the procurement tool, the vendor's configurator, the commissioning database, and a spreadsheet someone kept because the integrations were slow. None of them emits CFIHOS by default. The package gets stitched together late, and it comes out partial. The recurring failure modes.
- Incomplete vendor data. Vendors fill the fields their own system captured and leave the rest empty.
- Format mismatch. One transmitter under three naming conventions across three systems, merged by hand.
- P&ID-to-register drift. Field changes marked on paper, photographed, filed, and never pushed back into the index.
- Deferred focus. Handover treated as a close-out task instead of a thread from FEED, so the reconciliation lands when the schedule is tightest and the people who made the changes have rolled off.
- Supplier adoption gap. Tier-1 operators and EPCs are fluent. Smaller suppliers often are not, and the EPC absorbs their data.
CFIHOS, ISO 15926, and DEXPI
These three get mentioned together and confused constantly. They sit at different layers.
| Standard | What it is | Scope |
|---|---|---|
| ISO 15926 | Semantic data model for process-industry data | The interoperability backbone. CFIHOS extends its Part 4 |
| CFIHOS, JIP36 | Handover specification built on ISO 15926 | Construction-to-operations handover. Which classes, which properties, what completeness |
| DEXPI | Digital P&ID standard, XML, ISO 15926 aligned | The drawing itself. Topology, connections, tag placement |
Put plainly. A DEXPI P&ID confirms FT-101 exists and shows its connections. CFIHOS carries what FT-101 is, its class, its properties, its calibration, its documents. ISO 15926 is the semantic scaffolding both align to, and most instrument engineers never touch it directly.
What V2.0 changed
V2.0, late 2025 went after the V1.x adoption barriers.
- Core, Extended RDL split, so you adopt a workable Core instead of the full 665-field set.
- Energistics UOM alignment, so ranges and calibration values cross systems without unit ambiguity.
- Automated conformance checking against a published schema, which surfaces gaps before you submit.
- Tighter JIP33 and ISO 14224 alignment, cutting the remap when the same equipment data has to feed both handover and the reliability programme.
- SIS property additions for SIL-classified loops, plus new nuclear and GHG content.
Common questions
Is CFIHOS mandatory.
It is a voluntary standard. It binds when an owner-operator writes it into the EPC contract or the procurement documents. Conformance is checked at conformance.jip36-cfihos.org.
Who owns the tag register.
The EPC instrument engineer owns the tag objects. The owner-operator owns the plant hierarchy. The vendor stream supplies equipment data. All three meet before handover closes.
CFIHOS or DEXPI.
Both. DEXPI is the digital P&ID. CFIHOS is the structured data record for each tag on it. A complete handover uses both.
Does CFIHOS set the I/O list format.
No. Signal type and controller allocation are properties on the tag record, not a prescribed column layout.
Do I build the RDL.
No. It is published and free. You classify each tag against the right class and fill its required properties.
What changed in V2.0.
The Core, Extended split, Energistics UOM alignment, SIS property content for SIL loops, tighter JIP33 and ISO 14224 alignment, and automated conformance checking.
Where it leaves you
The recurring job is not the handover package itself. It is keeping the tag register complete, classified, and reconciled against the as-built set through every revision, so the last drawing cycle feeds straight into the handover instead of triggering a fresh paper walk. The engineering record that serves the project is the same one the operator inherits. Tagsight builds that record from the drawings. Every tag read, classified to its standard, and kept current as the revisions land. Start a workspace at tagsight.io.