How do you validate COBie data before handover?

A COBie file can pass every automated check and still send a technician to the wrong room for the wrong model of pump. That is why validation has to work at three levels. The first asks whether the file follows the agreed structure; the second, whether the information is internally consistent and meets the owner's rules; the third, whether it truly describes what was installed. Automated tools handle the first well and help with the second. Only people, working from evidence on site, can confirm the third.

Level 1: is the file well formed?

NIBS notes that several freely available tools can check the structure of a COBie file, or check COBie data in a design or construction model before the file is generated, either for structure or against project requirements. Structural checks confirm, among other things, that:

• required tables and fields are present;
• no fields are blank (COBie expects "n/a" for inapplicable text and "0" for numbers);
• each record has a unique key, normally its name;
• references between tables resolve, so that every component's type and space exists;
• pick-list fields use permitted values.

These checks are cheap, and they should run automatically at every delivery. Their value is in stopping obviously broken files before they reach people.

Level 2: does it meet the owner's rules?

COBie leaves many decisions to the project, and the second level checks the data against them: naming and identifier conventions, the classification system and its codes, the asset types that must be present and those that should not be, any fields required beyond the COBie minimum (and where "n/a" is not acceptable), and document references that point to files that actually exist and open.

Much of this can be automated if the rules are written precisely. What matters is how defects are reported. A single pass or fail gives the project team little help; a report that names the record, the rule broken and the party responsible gets things fixed.

Duplicates deserve particular care. When two trade packages each number their own equipment from 1, schedules combined carelessly will collide, or one record will silently replace the other.

Level 3: is it true?

The third level samples records against installed equipment and supporting evidence such as nameplates, approved submittals and commissioning records. The sample should lean towards critical or high-value assets, cover each contractor and package, and include equipment changed late or substituted. If errors repeat, the sample should grow, because a pattern points to a systematic problem in how one party produced the data. The results are kept as evidence for acceptance.

Then comes the test that matters most to the operator: a trial import into the receiving maintenance system, after which maintenance staff carry out representative tasks. Can they find an asset by room, identify its make and model, retrieve the manual and see the warranty? If they cannot do so without rebuilding data by hand, the deliverable is not ready.

Spread the checking across the project

Checking only at the end leaves no time to fix systematic problems while the people who caused them are still on site. The three levels work best spread across the deliveries:

The owner's information manager usually runs the first two levels. The third needs people who can read a nameplate and a schematic, such as the commissioning team or the maintenance contractor, supported by the information manager.

Defects, corrections and resubmissions

A useful defect record identifies the table and record affected and the rule broken or discrepancy found on site. It attaches the evidence, whether a photograph, a document reference or a checker's output, and grades the severity: prevents acceptance, must be fixed before final delivery, or recorded for information. It names the party responsible and the date due, and later records the evidence that closed it.

The requirements should also say whether a corrected delivery must be a complete file or may contain changes only. Either way, the automated levels should be rerun on every resubmission, because fixing one table can break a reference in another. And if a sample fails, it should be extended to the rest of that contractor's package; a fresh random sample could miss the pattern.