The asset manager who has to live with both series usually keeps two diaries and walks one corridor. Monday is the BIM wrap, with containers and suitability codes. Tuesday is the asset-management review, with criticality and next winter’s labour. The same plant room appears in both, under different names. Boards and BIM execution plans cite ISO 55000 and ISO 19650 as if that were one job. It is two series sitting on the same asset, and they almost never sit in the same meeting.
ISO 55000 is the asset-management family: overview, principles and vocabulary in ISO 55000, requirements for an asset management system in ISO 55001, guidance in ISO 55002. ISO 19650 is the information-management family for the delivery and operational phases of built assets: concepts in Part 1, delivery in Part 2, operations in Part 3. They meet on the information the owner must have in order to decide. They collide when a project information model is treated as a strategy, a common data environment is treated as a maintenance system, or practical completion is treated as the end of the life. ISO has not issued a joint clause table. Mapping papers, national annexes and vendor decks have already invented joins; those inventions are not the standards.
Two series, two jobs
ISO 55000 defines asset management as coordinated activity to realise value from assets. An asset is anything with potential or actual value to the organisation — a building, a plant item, a fleet, a right of way. The asset management system is a management system: policy, objectives, people, processes and documented information. Call it that and you are talking about how the organisation runs, not about a product on a licence schedule. The distinctive planning object is the strategic asset management plan (SAMP): the documented information that says how organisational objectives become asset-management objectives, how asset-management plans will be developed, and what role the management system plays. Beneath the SAMP sit asset-management plans for portfolios, systems and individual assets. The published principles are value, alignment (the line of sight from board objective to activity), leadership and assurance, over the whole life of the asset. ISO 55001 requires the organisation to determine the information it needs in order to support that system. The 2014 first edition and the 2024 revision both keep that demand. Neither edition names a common data environment.
ISO 19650 defines information management around information containers — named, persistent sets of information that can be retrieved — and an agreed source for collecting, managing and disseminating them: the common data environment (CDE). Part 1 sets the cascade most delivery teams can recite: organisational information requirements (OIR), asset information requirements (AIR), project information requirements (PIR), exchange information requirements (EIR). Those requirements produce two information models. The project information model (PIM) is what delivery uses to design and build. The asset information model (AIM) is what the appointing party is supposed to query in order to operate, maintain and later alter. Part 2 is the delivery-phase process and ends at project close-out, when the PIM is archived. Part 3 is the operational phase. The CDE is a workflow and, usually, a solution. Nobody who wrote Part 1 was trying to write an asset-management policy.
The jobs are adjacent. One says how the organisation will realise value, and what information that work needs. The other says how information is specified, produced, checked, issued and kept. Adjacent still leaves a gap you can fall through. A certificate that both series have been “applied” on the same campus does not mean anyone reconciled them. The asset manager walking that corridor already knows this, because they have been asked to brief both meetings from the same half-finished register.
Where they meet
They meet in four published places. None of them is a joint clause table.
Organisational need. ISO 55000 starts from organisational objectives and the context of the organisation. ISO 19650 starts from organisational information requirements. Those documents answer the same prior question — what must this organisation know, and decide, about the assets it holds? — without being the same document. If the OIR was written by a BIM consultant from a template, and the SAMP was written by an asset-management consultant from another template, the meet has already been missed. The information the management system will need at the next investment gate is the information the AIR should have named. You can usually tell, in the first ten minutes of a review, whether those two people ever sat in a room together.
Asset information as a decision input. ISO 55001 treats information as a support requirement for the management system: quality, availability and the attributes needed for the decisions the SAMP and the plans imply. ISO 19650 treats asset information requirements as the specification of what the AIM must contain. The meet is mechanical. Criticality, residual risk, warranty, inspection interval, as-installed duty, access constraint — those are asset-management facts. They are also AIM fields. If the AIR does not come from the SAMP’s decision list, the AIM will be a delivery leftover and the SAMP will be a brochure the operators stop opening after the first winter.
The operational phase. ISO 19650-3 exists because Part 2 stops. It is the published home for information management after handover: trigger events, the continuing AIM, the appointing party’s operational information requirements. ISO 55000 never stopped. Whole life is the default, not a later chapter. The meet is the AIM that Part 3 says should still be managed, serving the plans ISO 55001 says should still be executed. A project that implemented Part 2 and never opened Part 3 has not met ISO 55000. It has finished a delivery process and left the asset manager holding a model nobody is paid to keep.
Identity. Both series collapse if the thing that is managed cannot be found. Asset management needs a unique identity the operator will search, a location they will walk to, and a history they can trust. Information management needs a container that persists, a status that says what it may be used for, and a revision that says which one it is. The meet is the join: this tag, this space, this certificate, this work order. Without that join you have two cupboards, and the person with the torch in the plant room will invent a third.
That is the published overlap. The rest of the industry conversation is a collision wearing the word “alignment.”
AIM versus SAMP
The AIM is an information model. It answers operational questions: what is installed, where, how it is maintained, what residual hazard remains, which warranty still runs. Its reader is a facilities supervisor, an asset owner, a contractor who was not at the coordination meeting. Its test is whether a stranger can query the asset.
The SAMP is a strategic plan. It answers organisational questions: how board objectives become asset-management objectives, what approach will produce the plans, what the management system is for. Its reader is leadership, the asset-management function, the people who will allocate capital and accept risk. Its test is whether activity on the asset can be traced back to an objective.
They meet because the SAMP cannot be executed without the facts the AIM is supposed to hold, and the AIM has no purpose if it does not serve a decision the SAMP named. They collide the moment either document is asked to do the other’s job.
| AIM (ISO 19650) | SAMP (ISO 55000) | |
|---|---|---|
| Type of document | An information model | A strategic plan |
| Answers | What is installed, where, how it is maintained, what residual hazard remains, which warranty still runs | How board objectives become asset-management objectives, and how the plans that follow will be produced |
| Reader | A facilities supervisor, an asset owner, a contractor who was never at the coordination meeting | Leadership, the asset-management function, whoever allocates capital and accepts risk |
| Test | Can a stranger query the asset? | Can activity on the asset be traced back to an objective? |
The usual collision from the delivery side is to treat the AIM as if it were the SAMP. A federated model is renamed “as-built.” A COBie workbook is issued at practical completion. A folder called Asset Information is published from the CDE. Someone tells the board they now have an asset-management system. What the board has been handed is a model, or a dump. There is still no line of sight from organisational objective to intervention. ISO 19650 never claimed that an AIM was a SAMP. Delivery practice makes the claim by exhaustion: the only document the project still has at the end is the model, so the model is asked to be the strategy. The asset manager who has to present that model upstairs already knows it will not survive the first capital conversation.
The usual collision from the operations side is the reverse. A SAMP is written — policy language, a maturity assessment, a commitment to ISO 55001 — and never names the information the AIM must hold. Criticality is a workshop. The register is “to be confirmed.” Condition is a later survey. When the first winter comes, the people who operate the plant invent a third object: a spreadsheet, a computerised maintenance management system rebuilt from nameplates, a consultant’s data-cleansing job. Neither standard names that third object. You get it when the SAMP and the AIM were never introduced.
A further collision is grain. The SAMP speaks in portfolios, systems and risk. The AIM, if delivery produced one at all, speaks in instances: this damper, this doorset, this board. A strategy that cannot descend to an identifier will not be carried out on the thing that fails. A register that cannot ascend to a system will not inform a capital plan. The join is the work, and renaming the folder does not do it.
UK practice already admits two authorisations of information models — project and asset — in the national annex to ISO 19650-2. It does not admit a third authorisation called “this is now our SAMP.” Two codes exist because there are two models. Neither code is a strategic plan.
CDE versus AMIS
The CDE, in ISO 19650, is an agreed source of information for a project or an asset, for collecting, managing and disseminating each information container through a managed process. The process has states — work in progress, shared, published, archive — and a status that is suitability, not state. The unit of management is the container. The recorded facts are who moved it, when, and for what use. A CDE can be more than one technical solution if the workflow is shared. Software does not get certified as “ISO 19650.”
AMIS — asset management information system — is industry language, not a defined term in ISO 55000. The Institute of Asset Management and the surrounding asset-management literature use it for the systems that hold the register, the work order, the condition record, the cost and the risk: a computerised maintenance management system, an enterprise asset-management platform, a financial asset register, sometimes a computer-aided facilities platform. ISO 55000’s “asset management system” remains a management system. The AMIS is the kit that system runs on. Confusing those two sentences is how a licence is sold as a certification.
They meet because operational information has to live somewhere the SAMP’s plans can query. Part 3 of ISO 19650 contemplates a CDE in the operational phase. An AMIS needs identity, a managed update, and a history. Those are CDE virtues pointed at a different reader — the person raising a work order, not the person issuing a drawing.
| CDE (ISO 19650) | AMIS (asset-management information system) | |
|---|---|---|
| Built for | Issue | Intervention |
| Core question | Which container, which revision, which suitability, who authorised it? | Which asset, which condition, which work order, which cost, which risk? |
| Typical lifespan | Busy for two to seven years, then archived on a well-run job | Meant to stay busy for thirty |
They collide on purpose, cadence and state.
A CDE is built for issue. Its question is: which container, which revision, which suitability, who authorised it? An AMIS is built for intervention. Its question is: which asset, which condition, which work order, which cost, which risk? Publishing a CDE archive into a share and calling it the AMIS answers the first question and leaves the second empty. Importing a late spreadsheet into a maintenance system and calling it the AIM answers neither: the container history died at export, and the work order has no provenance.
Cadence is the second collision. Delivery’s CDE is busy for two or four or seven years and then, on a well-run job, is archived. The AMIS is supposed to be busy for thirty. A trigger event in Part 3 — a replacement, a failure, a change of use — is an ordinary Tuesday in asset management. If the only environment that still has the certificate is a project CDE whose licences lapsed at practical completion, the AMIS will be rebuilt from a photograph. That rebuild is the twelve-month handover wearing a different badge.
State is the third. CDE states do not map onto work-order states. Shared does not mean a work order is open. Published does not mean the asset is in service. Archive is not a decommissioning state, and suitability for construction issue is not permission to maintain. Teams that copy the four-folder diagram into a CMMS have not reconciled the series. They have decorated a maintenance system with delivery vocabulary.
The test is ugly and local. Pick an asset that will still need labour next winter. From the CDE, produce the published container, the revision and the certificate. From the AMIS, produce the identifier, the last work order and the inspection interval. If those two retrievals do not name the same thing, you do not have a meet. You have two systems that have not been introduced, and an asset manager who will spend January explaining why the planned maintenance never found the tag.
Handover versus whole life
ISO 19650-2 is a delivery-phase process. Its last act is project close-out: archive the PIM, capture lessons. The AIM is supposed to have been informed by then. The appointments that produced the PIM often end in the same month. ISO 55000 is whole-life by definition. Value is realised across acquisition, operation, maintenance, renewal and disposal. The expensive decades start when the site hut comes down.
They meet if handover is treated as a transfer of owned, identifiable records into a living AIM that the asset-management system will keep using. Part 3 is the published description of that continuance. Soft Landings, where anyone funded it, is a meeting structure for the same cut. Neither of those is a ZIP file.
They collide when handover is treated as the end of information management.
Delivery’s incentives point at completion. The PIM is finished when the taking-over certificate is issued. The CDE is a project cost. The information manager’s appointment expires. Document control demobilises. What leaves is usually an export: a dump of PDFs, a model without the issued set, a workbook generated once. Export is a lossy conversion. Suitability dies. Transmittal history dies. The link from the test sheet to the tag dies unless someone already wrote it as a field. The thing that arrives is a souvenir of the PIM. Asset management is then asked to run a thirty-year plan on a souvenir, and the facilities supervisor who inherits it will not thank the project for the ceremony.
Whole-life information has a different failure mode. The file was not deleted. The file was never the object operations would query, and nobody was appointed to keep the object that would be. Condition collected in year three has nowhere to land that still joins to the as-installed record. A replacement in year seven opens a new row with a new identifier. The SAMP still says “line of sight.” The register is a sequence of amnesias.
A circulated industry slogan says a share of lifecycle data is lost at handover. That figure is not a census, and it is not a clause in either series. What both series actually imply is narrower. ISO 19650 implies a cut from PIM to AIM. ISO 55000 implies that the cut is not the end of the life. If the cut is a dump, the life starts empty. Facilities teams who rebuild the asset register from scratch are not being difficult. They are doing the labour the collision deferred.
The time window that would make the collision visible is not the week of practical completion. It is the first year of occupation, when the AMIS is populated, the first planned maintenance runs, and the first defect is raised against an identifier. If those three acts still need a guided tour of the project that has demobilised, handover and whole life have not met on that job.
A Monday walk, then a contract change
You do not need a joint certification to see whether the two series have been introduced. An hour and five assets will usually do it.
- Find the SAMP and the AIR. If either is missing, the meet was never specified. If both exist, ask whether the AIR’s objects and fields are the decisions the SAMP named — criticality, residual risk, inspection, warranty, access — or a delivery shopping list. A SAMP that never mentions information, and an AIR that never mentions an objective, are two novels.
- Name the AIM and name the AMIS. Who accepts the AIM as the model the operator will query? Which system is the AMIS — not “the CDE,” not “ISO 55001”? If the answer to both is the same share, or the same licence, you have collapsed a model, a workflow and a management system into a folder.
- Walk five assets. For each, produce from the AIM (or the CDE archive that claims to be one) the identity, the as-installed fact and the bound certificate. Produce from the AMIS the identifier, the inspection interval and the last or next work order. Time-box an hour. The join is the finding. A shrug is the collision.
- Ask who is still paid after practical completion to keep the AIM current when a trigger event happens — a replacement, a failure, a change of use. Part 3 assumes that role. ISO 55001 assumes the management system is still running. An appointment that ended at handover is the collision, scheduled.
- Ask what would reject a handover that cannot feed a plan. If nothing in the appointment can fail the PIM for failing to feed the AIM, and nothing in the SAMP can fail an AIM that cannot support a plan, there is no reconciliation. There is hope, and a later data-cleansing invoice.
Five assets are enough. You are not certifying either series. You are asking whether anyone made them speak.
The appointing party — the client, the asset owner, whoever will still be there when the hut comes down — is the one who can make that walk a condition of taking-over, and write the fifth test into the appointment before the PIM is produced. It costs an information manager past practical completion, a variation if the role was never priced, and the political awkwardness of failing a handover that looks complete in the cabin. It may also cost the embeddings, workbooks and “as-built” dumps you were about to accept, because a clean join sometimes means sending them back. Holding both certificates will not do this work for you. The 2024 revision of the ISO 55000 family, and the later parts of ISO 19650, change emphasis and add operational detail. They do not merge the jobs, and ISO has still not issued a clause-by-clause map.
What you can point at is narrower, and it is enough: a SAMP that named the information, an AIR that priced it, an AIM a stranger can query, an AMIS that uses the same identifiers, and a role that still exists when the site hut has gone. If those five are missing, stop treating the collision as a later data-cleansing job. Fund the Monday walk this quarter, and refuse to take over until the five assets join.
Read next: Why facilities teams rebuild the asset register from scratch, Monthly Register — May 2026, The digital twin nobody updates.