A 1,200-asset MEP handover for a hospital tower lands on the owner's-rep desk as a stack of files: a contractor-delivered COBie spreadsheet, an IFC model, a folder of OEM O&M PDFs, the warranty terms, and the commissioning record. The job is to turn that pile into something the facilities team can actually run the building from: a warranty matrix, an asset register, and a CMMS load file that imports cleanly into IBM Maximo (or Archibus, FM:Systems, or Brightly) with preventive-maintenance frequencies and warranty expiration dates. Done by hand, this is weeks of transcription and the moment the building turns over is exactly when nobody has weeks. AI assembles the load file and reconciles the contractor's COBie attributes against the OEM nameplate data in hours. But a wrong attribute loaded into the CMMS misdirects maintenance for the life of the building, so the owner's rep owns the verification, and the artifact that proves it is the variance memo flagging the assets where the COBie does not match the nameplate. This lesson designs that workflow: generative assembly plus analytic reconciliation, with the owner's rep verifying before the load.

The Receiving Seat: COBie Comes In, the CMMS Has to Run the Building

The prior lesson sat on the contractor's side of the warranty and O&M handover, generating the COBie deliverable from the federated model and reconciling it against the commissioning agent's punch. This lesson sits on the other side of the same transaction: the owner's rep and the facilities-management team receiving that handover and turning it into a working CMMS (computerized maintenance management system). The contractor's job ends at delivering a compliant COBie; the owner's-rep job begins at making the building maintainable from it, which is a different problem with a different verification.

The receiving side has to do three things. It has to assemble the warranty matrix, which is not one warranty but a layered set: the 1-year general warranty that covers the contractor's work, plus the manufacturer's extended warranties running 2, 5, or 10 years on specific equipment (compressors, roof membranes, chillers), each with its own start date, term, and conditions. It has to build the asset register, the authoritative list of every maintainable asset with its identity, location, and attributes. And it has to produce the CMMS load file, the structured import that creates each asset in Maximo or Archibus or FM:Systems with its preventive-maintenance (PM) frequency and its warranty expiration, so the system knows what to service, when, and while which warranty is still live.

These three are linked. The asset register is the spine; the warranty matrix hangs warranty terms on each asset; the CMMS load file is the register and the matrix expressed in the import format the specific platform expects. The contractor's COBie is the raw material for all three, but it is raw material, not the finished product, because COBie is a delivery format and Maximo is an operating system, and the gap between them is where the owner's-rep work lives.

What the AI Assembles: Warranty Matrix, Asset Register, Load File

The AI does two distinct kinds of work here, and keeping them separate is the key to the whole lesson. The first is generative assembly: ingesting the heterogeneous inputs (the COBie spreadsheet, the IFC model, the OEM O&M PDFs, the warranty terms, the Cx record) and assembling them into the three structured outputs. The COBie carries the asset list across its tabs (Facility, Floor, Space, Type, Component, System, Spare, Resource, Job), so the AI maps Component and Type records into asset-register rows, pulls Space and Floor for location, reads the warranty terms to populate start dates and durations, and emits the result in the column structure the target CMMS expects.

This assembly is real work the AI is good at: it is reading and reformatting across formats, the kind of transcription and mapping that consumes the owner's-rep weeks when done by hand. The AI reads a warranty PDF that says the chiller compressor carries a 5-year parts warranty from substantial completion, computes the expiration date, and writes it into the load file's warranty-expiration field. It reads the O&M manual's recommended service interval and proposes a PM frequency (quarterly filter changes, annual chiller inspection) for the CMMS to schedule against. It maps the contractor's equipment tags to the asset-naming convention the facilities team uses. Multiply that across 1,200 assets and the time savings is the entire value of the assembly step.

But assembly is generative, which means the AI is composing the output from the inputs, and composition can introduce error: a misread warranty term, a PM frequency proposed for the wrong equipment class, a date computed from the wrong start point, an attribute carried forward from a COBie field that was itself wrong. The assembly produces a plausible, complete-looking load file fast, and the speed is the benefit, but the plausibility is also the trap, because a load file that looks complete and is wrong loads cleanly and misdirects maintenance silently. That is why the second kind of work, the reconciliation, is not optional.

The Reconciliation: COBie Attributes Against OEM Nameplate

The second kind of AI work is analytic reconciliation: comparing the contractor's COBie attributes against an independent source of truth, the OEM O&M nameplate data. The nameplate is the manufacturer's authoritative statement of what the equipment actually is: model number, serial number, capacity, voltage, refrigerant type, rated load, service requirements. The COBie attributes are what the contractor's team entered, which should match the nameplate but often does not, because COBie attributes get populated from the design model, from submittals, or by hand, and any of those can drift from the equipment that was actually installed.

This is where the two sides of the handover diverge in a way that matters. The contractor delivered a COBie that is internally consistent and compliant with the BIM Execution Plan; that does not mean every attribute matches the physical nameplate on the unit that got installed. A chiller substituted late in procurement, a pump that shipped with a different motor, a model number transcribed with a digit wrong: the COBie says one thing, the nameplate says another. The reconciliation is the AI comparing the two fields across all 1,200 assets and flagging where they disagree, the analytic counterpart to the generative assembly.

The AI assembles the CMMS load file and reconciles the COBie against the OEM nameplate, but the owner's rep owns the verification, and a wrong attribute loaded into the CMMS misdirects maintenance for the life of the building, so the artifact is the variance memo flagging the mismatches, not the clean-looking load file that hides them.

The Life-of-Building Asymmetry: Why a Wrong Attribute Persists

The verification asymmetry here is more severe than in most of the workflows this program has covered, and it is worth being precise about why. A wrong RFI answer gets caught in the field within days. A wrong takeoff quantity gets caught when the work is built. But a wrong asset attribute loaded into the CMMS does not get caught, because the CMMS is the system of record from which the facilities team operates for the building's entire life, often decades, and the wrong attribute quietly misdirects maintenance the whole time. A filter size off by one drives the wrong replacement part ordered for years. A wrong PM frequency under-services or over-services equipment. A wrong warranty expiration date means a claim is missed because the system thinks the warranty already lapsed, or a service is paid for that the warranty would have covered.

This is the same false-negative asymmetry the program has applied to the submittal register and to pay-app backup, but stretched across a much longer time horizon. A false negative here, an attribute that is wrong but passes into the load file uncaught, is not a single missed catch; it is a standing error that the maintenance program executes against repeatedly for years. The cost is not paid once at handover; it compounds over the operating life, in wrong parts, mistimed service, and missed warranty recoveries, which is exactly the kind of slow, invisible loss that no single event surfaces.

So the verification weights heavily toward catching the mismatches before the load, because the load is the point of no easy return: once 1,200 assets are in Maximo and the facilities team is operating from them, finding and correcting a wrong attribute means an audit nobody schedules. The cheap moment to catch the error is now, at the load, with the nameplate data still in hand and the reconciliation already run, which is why the reconciliation output and its verification are the heart of this workflow.

The Owner's Rep Owns the Verification: The Variance Memo

The AI runs the reconciliation and flags the mismatches, but flagging is not verifying. The reconciliation might flag 40 mismatches across the 1,200 assets, and the owner's rep has to work each one: is this a real discrepancy where the COBie is wrong and the nameplate is right, or a benign formatting difference (the same model number written two ways), or a case where the nameplate field was misread by the AI? The owner's rep resolves each flag against the source documents, decides which is authoritative, and records the disposition. This is the same verification discipline as pay-app backup and submittal review, applied to asset data: the AI proposes, the responsible party verifies and owns the result.

The artifact of that verification is the owner-rep variance memo: the document that lists each flagged asset, states the COBie attribute and the conflicting nameplate value, gives the owner's-rep determination of which is correct, and assigns the correction back to the contractor where the COBie is wrong. The memo is the proof of verification and the instrument of contractual recourse, because a wrong COBie attribute is a deficient deliverable, and the variance memo is how the owner's rep documents it and pushes the correction back to the responsible party before accepting the handover and loading the CMMS.

This is the spine point of the lesson, and it is the same one carried through the program: the AI accelerates the assembly and the comparison, but the owner's rep owns the verification, because the load file is consequential and a wrong attribute persists. The variance memo is to this workflow what the verified pay-app backup is to the pay application and what the marked OPR is to the owner-side authorship: the artifact where the human's verification is recorded and where their ownership of the consequential output is made explicit. The AI does not own the CMMS data; the owner's rep does, and the memo proves it.

Loading Into Maximo, Archibus, FM:Systems: The Format Is Not the Data

The target platform shapes the load file, and the owner's rep has to know the difference between getting the format right and getting the data right. IBM Maximo expects assets in its asset hierarchy with location codes, classification, PM job plans, and meter definitions; Archibus structures around space and the asset-to-room relationship; FM:Systems and Brightly each have their own import schema and field requirements. The AI can map the assembled register into any of these formats, and a clean import (no rejected rows) is a real and useful result, because a load file that fails import is its own delay.

But a clean import is a format check, not a data check, and conflating the two is the trap. A load file can import perfectly and be full of wrong attributes, because the CMMS validates structure (is this a valid date, a recognized location code, a non-null required field) not truth (is this the actual warranty expiration, the actual filter size, the actual PM interval the equipment needs). The import succeeding tells you the file is well-formed; it tells you nothing about whether the data is right. So the owner's rep verifies the data through the reconciliation and the variance memo, and separately confirms the format imports cleanly, and does not let the clean import stand in for the data verification.

The PM frequencies and warranty expirations deserve particular attention at the load, because they are the fields the CMMS will act on automatically. A PM frequency drives the maintenance schedule the system generates; a warranty expiration drives whether the system flags a repair as warranty-covered. These are not passive reference fields; they are operating parameters, so an error in them is an error the system executes. The owner's rep gives the PM frequencies and warranty dates the heaviest verification because they are the fields with the most downstream automatic consequence, the same proportioning-by-consequence the program applies everywhere.

The Applied Problem: The Hospital Tower Load File and Variance Memo

Here is the exercise. You are the owner's rep receiving a 1,200-asset MEP COBie handover for a hospital tower. Ingest the contractor-delivered COBie and IFC, the OEM O&M PDFs, the warranty terms, and the Cx record. Produce two artifacts. First, the Maximo asset-import file: the asset register mapped into Maximo's import schema, with each asset carrying its location, classification, PM frequency derived from the O&M service intervals, and warranty expiration computed from the warranty terms and the substantial-completion date, layered to capture the 1-year general and the 2/5/10-year manufacturer extended warranties.

Second, the owner-rep variance memo. Run the reconciliation of the COBie attributes against the OEM nameplate data across all 1,200 assets, which surfaces roughly 40 assets where the contractor's COBie does not match the nameplate. For each flagged asset, the memo states the COBie value, the conflicting nameplate value, your determination of which is authoritative, and the disposition: correct the load file, or kick the deficient attribute back to the contractor for a corrected COBie before acceptance. The memo is your verification record and your instrument of recourse, and it is what stands between the AI's plausible load file and a CMMS that misdirects maintenance for the building's life.

The deliverable is the Maximo asset-import file plus the variance memo, and the lasting product is a verified CMMS load: the facilities team gets a system that knows what to service, when, and under which live warranty, and the owner's rep has a documented record that the consequential attributes were checked against the authoritative source before the load. This is the receiving end of the COBie handover, the last lesson of the level, and it closes the loop: the contractor generates the COBie and the owner's rep reconciles it, generative assembly on one side and analytic verification on the other, with the human owning the consequential data on both. The professional who masters this turns a 1,200-asset pile into a working CMMS in hours while owning the verification that a wrong attribute, once loaded, would otherwise carry silently for the life of the building.

Key Takeaways

• This is the owner's-rep / FM seat, the receiving side of the prior lesson's COBie handover: the contractor's job ends at delivering a compliant COBie, and the owner's-rep job begins at turning it into a working CMMS, a different problem with a different verification.
• The receiving side assembles three linked outputs: the warranty matrix (the 1-year general plus the 2/5/10-year manufacturer extended warranties), the asset register (the authoritative maintainable-asset list), and the CMMS load file (the register and matrix in the platform's import format with PM frequencies and warranty expirations).
• The AI does two distinct kinds of work: generative assembly (ingesting the COBie, IFC, O&M PDFs, warranty terms, and Cx record into the three structured outputs) and analytic reconciliation (comparing the contractor's COBie attributes against the independent OEM nameplate data). Keeping the two separate is the key to the workflow.
• The assembly is fast and plausible, but plausibility is the trap: a load file that looks complete and is wrong imports cleanly and misdirects maintenance silently, which is why the reconciliation against an independent source of truth is not optional.
• The life-of-building asymmetry: a wrong asset attribute loaded into the CMMS is not a single missed catch but a standing error the maintenance program executes against for years, in wrong parts, mistimed service, and missed warranty recoveries, the false-negative asymmetry stretched across the operating life.
• The owner's rep owns the verification: the AI flags the roughly 40 mismatches, but flagging is not verifying, so the rep resolves each flag against the source documents, decides which is authoritative, and records the disposition, the same discipline as pay-app backup and submittal review applied to asset data.
• The artifact is the owner-rep variance memo: it lists each flagged asset, the COBie value, the conflicting nameplate value, the rep's determination, and the disposition (correct the load or kick the deficient attribute back to the contractor), making it both the proof of verification and the instrument of contractual recourse.
• A clean import is a format check, not a data check: the CMMS validates structure, not truth, so the owner's rep verifies the data through the reconciliation and the memo and gives the PM frequencies and warranty expirations the heaviest verification because they are the operating parameters the system acts on automatically.