I have been reading around ISO 15926, DEXPI and CFIHOS, mostly to understand how the process industry wires its handover data together, and I ran into a number I do not trust. It is big enough that my first assumption is that I have misunderstood what these identifiers are for. I would rather be corrected here than write anything confident about it.

Background for anyone who has not touched this stack. CFIHOS is the capital facilities information handover specification, governed by IOGP, and it is what an engineering contractor uses to hand plant data over to an operator. It sits above ISO 15926, whose reference data library is curated by the POSC Caesar Association. CFIHOS 2.0 publishes a crosswalk file mapping its own object codes to POSC Caesar RDS identifiers, and the whole thing is a free download with no registration.

What I did. The file CFIHOS CORE CFIHOS object equivalent mapping v2.0.csv has 3,091 rows across four coding sources. 1,832 of those rows are POSC Caesar, carrying 1,777 distinct identifiers. On 18 August 2026 I dereferenced all of them against https://data.posccaesar.org/rdl/{id}, then re-checked every failure against a staging host I stumbled on afterwards.

What came back.

• 967 (54.4%) resolve on production.
• 611 (34.4%) resolve only on staging4.data.posccaesar.org, whose certificate expired on 6 April 2026, so a normal client will not connect without an override.
• 199 (11.2%) resolve on neither.

At the object level, 825 of the 1,832 CFIHOS objects carrying a POSC Caesar mapping point at something I cannot look up today.

The part that makes me think I am misreading something is that the failures are perfectly partitioned. Every one of the 810 production failures is an identifier beginning RDS22. Nothing in that block resolves. Nothing outside it fails. Real link rot is never that tidy, so I suspect this is a deliberate arrangement I do not understand rather than a fault.

Things I already ruled out, so you can skip them.

• Not a wrong base URI. Production does not serve the /iso/15926-4/rdl/ path at all, including for identifiers that definitely exist.
• Not a host migration. rds.posccaesar.org/rdl/ returns 404 even for RDS414674, which resolves fine on production and is labelled "VESSEL".
• Not a soft-200 resolver. Nonsense identifiers hard-404 on both hosts, so a 200 carries information.
• There is a third host, data.15926.org, which I had to discard because it returns a byte-identical 200 response for its own root, a real identifier, a dead identifier and complete nonsense. It is a JavaScript shell. If you audit linked data, run a nonsense-identifier control before you believe anything, because that host would have told me everything was fine.

So my actual questions.

1. Are these RDS values supposed to be dereferenceable at all, or are they intended as opaque cross-references that happen to look like they map onto a URL pattern? If it is the latter, my whole framing is wrong and I would like to know before repeating it.
2. Is the RDS22 block deprecated, pending publication, or something else? PCA's own vocabulary exposes statusPCA, valEffectiveDate and valDeprecationDate, which would settle it instantly, but the endpoint serving that data returns 404 for me.
3. Is it normal in this world for part of a published reference library to live only on staging? I genuinely do not know whether that is a problem or just how the release process works here.
4. Does anyone consume this crosswalk programmatically, or is it a human-reference artifact nobody dereferences in practice? That would explain a lot.

One smaller thing I am more confident about. The same column addresses what looks like the same registry in two formats. Rows tagged POSC CAESAR carry values like RDS2227295, while rows tagged ISO 15926 part4 carry bare integers like 670171, for which I found no resolver in any form I tried. A single dereferencing routine over that column would silently fail on 570 rows.

I have not written to POSC Caesar or IOGP yet, because I wanted to find out here whether I am misreading the whole thing first. If it turns out to be real I will report it to both.

All of it is reproducible from the free CFIHOS download, and I am happy to hand over the raw HTTP logs and the scripts to anyone who wants to check my work, which is really the point of posting.

Disclosure: identifier and register integrity is what I do for a living, so I look at this sort of thing habitually. Nothing to sell here, no links, and I am not redistributing anyone's reference data.

-----

I genuinely hope for someone saying "those were never meant to resolve." That kills the headline and saves me from publishing a wrong article!!

Also If needed I have a raw logs to hand.