Condition data: designing the feedback loop back to design

In a plant room somewhere on an estate that is being extended this year, a maintenance technician is working off a stepladder because the access door on an air handling unit opens against a wall and there is no room for a platform. He has raised it before. The work orders are in the maintenance system, coded and closed, exactly as the contract requires. Two floors down and a year later, the incoming mechanical designer has specified the same unit, in a room of the same footprint, with the door on the same side.

Nobody in that sequence has been careless. Operations recorded what happened. The designer worked from the brief in front of them. What failed is the trip between the two, and it fails so reliably that most people have stopped expecting it to work at all. The next project buys the same valve, the same plant-room door that will not take a motor, the same filter that needs a scaffold to change.

Three things have to survive that trip if the next design is going to be any different: a failure mode a specifier can actually act on, a tag that still names the same asset across two appointments, and enough issued-set lineage to say which published container produced the object that is standing there. Lose any one of the three and the incoming team will invent the asset again, in good faith, from first principles.

Workshops do not travel

The industry has plenty of rooms for this conversation. Soft Landings, post-occupancy evaluation, the lessons slide at close-out, a facilities briefing that happens once if somebody funds it. Those rooms are genuinely useful, and I would not skip them. They just do not travel. No design team on a new appointment goes hunting through last year's workshop notes. They open the brief, the organisational and asset information requirements, and the most recent issued set anybody can find for them.

If the condition fact is not sitting on one of those objects — as a row, a residual, a "do not repeat" instruction keyed to an identity — it never enters the appointment, and it certainly never enters a price. The estimator cannot price a memory.

ISO 19650 already names the two models between which the fact has to move. The project information model is what delivery used. The asset information model is what operations is supposed to be able to query. The joint nobody specifies is the third trip: out of the AIM, or more honestly out of the maintenance system that actually holds the work history, and back into the next project information model. Handover literature stops at the cut. Asset-management literature starts after occupation. The loop sits in the gap between those two shelves, which is roughly where responsibility for it also sits. CDM residual risk, the health and safety file and the golden thread on higher-risk buildings all assume a receiving object that later people can still read. None of them tells you how to turn a closed work order into a briefing row.

Which is why a better workshop will not fix this. The fix is to write condition facts in a form the next appointment can inherit, without anyone needing to have been in the room.

Failure modes a designer can act on

A work order that says "AHU noisy" is labour coding. It is not a design input. The incoming mechanical lead cannot change a family from "noisy". What they can change is access, isolation, duty, product, or the residual they are obliged to leave on the object for the next reader.

A design-relevant failure mode answers four questions a specifier will actually use.

What failed — the component, not "plant". Bearing, coil, actuator, door, guard, filter frame.
How it failed, in terms a drawing can prevent or reduce: cannot isolate, cannot access without a platform, premature replacement, wrong duty as installed, a substitution that then failed, a residual hazard nobody designed out.
What was actually installed, rather than what the type mark promised. Condition data about a specified unit that was never placed is a complaint about a ghost.
Whether the failure is a specification problem, a maintainability problem, an operations problem or a record problem. Only the first two belong in the next brief as design instructions. The third is a facilities procedure. The fourth is the reason the loop was open in the first place.

Most maintenance codes were never built for this. They exist to roster trades and close jobs, so they group by craft, location or urgency, and none of those groupings answers the question "would this change a future specification?" Someone has to do that mapping by hand, and it is a short classification rather than a census. Do not invent a failure-rate table for a building nobody has counted. Take the assets you already know failed, or fought the maintainer, and sort them into the four questions. The ones that would change a future sheet are the pack. The rest stay in the maintenance system, which is where they belong.

A mode that cannot point at an object is the same orphan as a design-risk row that cannot point at a model or an issued sheet. "Care on roofs" will survive every review and change nothing. "This extract fan cannot be isolated from the corridor side; the next issued set must show a local valve and a reachable handle" is a mode somebody can price.

Tags that survive two appointments

The join is the asset tag, and it is usually where the whole thing quietly comes apart. If operations tagged the casing AHU-03 and the incoming designer's model uses a type mark and a room number, there is no join at all. The new project mints new identifiers, and six years of work history stays in the old system under a string nobody will ever type again.

A tag that can carry a failure home has to be the same string — or sit on a map somebody owns — in four places: the label on the installed object, the asset information model, the maintenance system, and the incoming project information model for any asset that will be retained, replaced or built against. Refurbishment, extension and replacement work is where this gets tested. A new build on a green field has no previous tag to inherit. A live estate always does.

The method is ordinary and completely unforgiving. Keep the unique identity from the first inspection that accepted the instance. Do not allow delivery's package mark, the COBie Name someone typed in a hurry last fortnight, and the CMMS functional location to become three separate inventions of the same unit. Where the owner's naming convention differs from the project's, add a second field rather than overwriting the string that already joins the certificate, the warranty and the work order.

Then the appointment has to say so out loud. The AIR should name which existing tags are in scope and must be reused; "all maintainable assets" is a mood, whereas a schedule of retained identities is something an estimator can read and cost. If the incoming model is free to mint fresh marks for plant that already carries a tag, the loop is cut on day one of the new job and no amount of goodwill later will repair it.

A tag that was never issued against the as-installed object cannot carry a failure home either. A type in a federation is not an instance. A room number is not a unit. Point a condition record at a system rather than a tag and the next designer will improve a family in general, and miss the one door that actually failed.

Issued-set lineage

Condition data without lineage is a grumble about "the AHU". Condition data with lineage says: this failure belongs to the mechanical set that was issued for construction — container, revision, suitability — and to the product that was actually placed, including the substitution if there was one.

That lineage is a chain of four identities rather than a folder called As-built.

The published container issued for construction: drawing or model, number, revision, date, and the transmittal that made it current.
The as-installed fact: what was placed, omitted or substituted, recorded against the same tag.
The condition record: the work order, replacement or residual that operations later wrote against that tag.
The next briefing object: a row in the new AIR, a residual in the pre-construction information, or a "do not repeat" schedule the incoming designer is being paid to answer.

Break the first link and a designer revises a family that was never installed. Break the second and they treat the issued set as truth and the plant room as hearsay. Break the third and they have an identity with no behaviour attached. Break the fourth and the first three sit in a maintenance export nobody was appointed to read.

Link	What it is	If broken
Published container	Drawing/model, number, revision, date, transmittal	A designer revises a family that was never installed
As-installed fact	What was placed, omitted or substituted, against the same tag	The issued set is treated as truth and the plant room as hearsay
Condition record	The work order, replacement or residual written against that tag	An identity with no behaviour attached
Next briefing object	A row in the new AIR, a residual, a "do not repeat" schedule	Sits in a maintenance export nobody was appointed to read

Document controllers already know this discipline; the only difference here is who it is being kept for. Revision and version are not the same thing. Suitability for construction issue is not suitability for the asset register, and neither is suitability for the next brief. The job on the loop is to keep the published identity alive so that a stranger, two appointments later, can still say which sheet produced the object that failed.

The usual breaks are unglamorous: a redline photographed on a phone, a substitution agreed in a mailbox, a "build as drawing" that was not built as drawing. Those are the same breaks that empty an AIM at handover. If the as-installed fact never entered project custody, the condition record has nothing honest to stand on, and no later effort can invent a lineage the first job never wrote.

A pack you could assemble on a Monday

None of this needs a consultant. It needs a sample and a named receiver.

Pick a short sample of assets that failed, were replaced earlier than the O and M implied, or could not be maintained as drawn. Five is enough. This is not a reliability study; you are only asking whether the join exists.
For each one, produce three fields on a single page: the persistent tag, the design-relevant failure mode, and the issued container and revision that authorised what was built — plus the as-installed product where it differs.
Ask whether that page could be inherited by the next AIR or briefing without a guided tour of the last job. If it only exists as a maintenance export, recut it until a stranger could price a response.
Name the person who will accept those rows into the new requirements: a role on the next appointment, not a system. If the answer is "we will mention it at the kick-off", nobody owns it.
If you cannot join tag to issued set to condition, stop there. That is the finding, and it is worth more than a slide about lessons from operations. Brief the missing join, and decide who is paid to write it before the tender goes out.

The pack stays small on purpose. A hundred pages of maintenance history is what operations already have and what nobody reads. The subset that changes a sheet is the part with any value at the briefing table.

Where this stops

This is not a reading of ISO 55000, and it is not reliability-centred maintenance in miniature. Post-occupancy evaluation and Soft Landings can feed the pack very well; holding them does not close anything by itself. There is no failure-rate table here, no share of projects that lose the loop, no building offered as proof, because the evidence on any real estate is local — the tags you can still read, the issued revisions you can still find, the work orders you can still join. Produce those three for five assets and you know where you stand. One good pack does not prove anything about the industry; it proves the join can be written on your estate, which is the only version of the question you can act on.

ISO 19650, the CDM Regulations, the Building Safety Act, NEC, FIDIC, JCT, COBie and the Gulf mandates all have owners, and not one of them writes this instruction for you. The appointing party on the next job has to. Write the surviving tags, the design-relevant failure modes and the issued-set lineage into the organisational or asset information requirements, and name the role that will accept those rows — a person on the incoming appointment, paid to inherit them. That costs a schedule in the brief and the hours to recut the five-asset pack; it does not cost a new standard.

Until that row is in a brief an estimator can price, the incoming designer will specify the door on the same side in good faith, and the technician will still be on the stepladder in four years.