A delivered file is not an accepted record

At taking over, a contractor hands across the information the contract asked for: the as-built records, the operation and maintenance manuals, the equipment lists, the warranties. Somebody checks the transmittal against the contract's list, the Engineer raises no objection, and the deliverable is closed.

Everything in that paragraph is a fact about files. None of it is a fact about whether the maintenance system that has to schedule the first service holds a single record it can use.

File delivery and operational acceptance are two events with two different tests. Where a contract tests the first and nothing tests the second, the contract's stated information obligations can be performed in full and the operator can still start without an operating baseline. This piece separates the two, sets out four tests that together amount to acceptance, and names the six places the information can fail on the way.

What the contract tests

The 2017 FIDIC books make a worked example, because they tie the information to a certificate the contractor needs. What follows is Victoria Tyson's published commentary on them, and every statement here about FIDIC is the commentary's.

That is a real lever, and as the commentary describes it, it is a test of two things: that the documents were supplied, and that the Engineer did not object to the records. Both are tests of the delivered material against the contract. Neither asks whether the material was loaded into anything, by anybody, or whether it worked when it was.

Why the review has to happen before the certificate, not after

, read: At handover, every review arrives after the leverage has goneAt handover, every review arrives after the leverage has gone

What the ISO 19650 guidance separates

ISO 19650-3 is the part of the series written for the operational phase. What follows is the UK BIM Framework's published guidance on it, and the guidance does not present delivery and use as one event.

These are clause titles as the guidance lists them, and nothing here says what those clauses require in detail. What the titles show is structural: in the sequence presented by the guidance, accepting what was delivered and incorporating it into the model the organisation operates from are different steps, and the links to the systems that will use the information are something the owner establishes, not something the delivery produces.

The same guidance is plain about the standard's force: it describes it as voluntary, with no obligation of its own, and says the obligation has to be created, by a contract or by an organisational policy. The guidance therefore presents this separation as an arrangement an organisation can adopt through a contract or internal policy; the guidance itself creates no obligation.

Four tests, kept separate

Acceptance is not a single judgement that a pack is complete. It is four questions, and each can pass while the next fails.

The four are not a checklist to be ticked together. A pack can pass receipt and fail schema, because a document list says nothing about attribute values. It can pass schema and fail identifier, because a record can be valid in isolation and match nothing in finance. It can pass all three and fail the transaction, because the maintenance schedule references a task library, a spares list or a location hierarchy that was never loaded. Only the last test exercises the information the way the operator will.

Why the project's identifiers may not survive onto the asset record

, read: The project crosswalk reaches capitalisation. What survives it?The project crosswalk reaches capitalisation. What survives it?

Six places the information can fail

The failure is not one thing, and treating it as one produces the wrong remedy. The information passes through six locations between the contract and the operator's first work order, and each fails for a different reason.

Mapped against the four tests: receipt catches production, and only production. Schema catches validation, and exposes transfer as well, because it is the first test that has to run inside a receiving environment. Identifier catches import. Transactional catches operational adoption, which no earlier test can see, because data can load cleanly and still have nobody maintaining it. For specification, a later review can identify the omission, but only a pre-contract review can place the requirement in the original delivery obligation, by asking whether the information requirement names what the operator will run on.

Why production failure is a different kind of problem

Of the six, production is the one the existing machinery handles. The contractor owed a deliverable and did not deliver it; the contract has a remedy, a certificate to withhold, and a party to hold to it.

Where the contract requires only production and delivery, the other five failures can coexist with complete performance of those stated obligations. A contractor can supply every document, to the specification, on time, with the Engineer's Notice of No-objection, and each of them can still occur, because they are failures of specification, of receiving architecture, of correspondence between two valid structures, and of ownership on the operating side. Where the contract also requires validation, mapping, import or operational testing, failure of those tests may itself be contractual non-performance. If the delivery contract never made those outcomes obligations, it may provide no remedy for their absence.

That is why "the contractor did not hand over properly" and "the information never became usable" are different findings, and why treating the second as a version of the first sends the owner looking for a claim when what is missing is a receiving system, a mapping and an owner.

What handover costs the organisation that inherits the asset

, read: Handover is where the cost lands, and the Gulf is now taking deliveryHandover is where the cost lands, and the Gulf is now taking delivery

What reduces the risk

The mechanism is conditional, and so are its limits. Each of the following arrangements reduces the risk at one or more locations, and each is a condition an owner can check rather than a claim about what any owner does. None of them guarantees that acceptance will succeed.

Where the receiving schema is specified in the contract and the delivered data is validated against it before acceptance, there is a test for specification and validation failures before acceptance, because the contractor is asked to produce to the structure the operator will use.

Where one owner holds the identifier mapping before production starts, the risk of import failure is reduced, because the codes the contractor assigns are issued from, or mapped into, a structure that already exists.

Where the receiving environment is configured and tested before the data arrives, a transfer failure can be detected before acceptance. This is a requirement for a receiving architecture, not for any particular product, and when and in what form it is built depends on the operating model and on the enterprise systems already in place.

Where the contract involves the operating function before handover and assigns a named role to accept the data as usable, responsibility for accepting the data for operational use is assigned before operation begins.

Where all four arrangements exist, the tests can be run before handover, so failures can be detected and assigned for correction before operational acceptance. Where they do not, the contractual process may stop at receipt.

What the data has to be once it is in use, and where ISO 55001 Clause 7.6 fits

, read: Nothing tells you when a record stopped being trueNothing tells you when a record stopped being true

What to examine

What does the contract test at handover? Read the clause that releases the certificate or closes the deliverable. If it tests supply and absence of objection, it tests receipt, and the other three are somebody else's to arrange.

Is there a receiving schema, and does the contract refer to it? A list of documents is not a schema. Ask for the attribute list the receiving system will reject on.

Who owns the mapping between the physical tag, the project code, the financial record and the operational record? If the answer is a spreadsheet with no named owner, the identifier test has nothing to run against.

Has any delivered asset been used in a transaction? Choose one asset, raise a test work order against it in the receiving system, and see whether it plans, assigns and closes. The result is a yes or a no.

Which of the six locations would a failure here sit in? A production failure is a contractual matter. The other five need a different owner and a different remedy, and finding which one applies decides who has to act.

What the acceptance test should hold

---

Sources. Victoria Tyson, Howard Kennedy, FIDIC 2017: Clause 11, Defects After Taking Over, page 5, on Sub-Clause 11.9 and the Notice of No-objection to the as-built records as a precondition to the Performance Certificate; every statement about FIDIC here is attributed to that commentary. UK BIM Framework, Information management according to BS EN ISO 19650, Guidance Part 3, Operational phase of the asset life-cycle, edition 1, September 2020: Figure 2 for the transfer from the project information model to the asset information model, section 2.0 for the standard being voluntary unless a contract or policy creates the obligation, section 3.1 for the eight process steps, and Tables 3 and 4 for the titles of clauses 5.1.6, 5.1.10, 5.1.11, 5.7.2 and 5.8.1; every statement about ISO 19650-3 here rests on that guidance.