Places before things, things before work

A layer can only be created once the thing it points at exists. The right-hand column is what each one hands you on the way out.

A reference to an object that is not there is not a data-quality finding somebody cleans up in a later pass. No record is created at all. That is worth saying plainly, because it decides what a late layer costs: a structure that arrives late does not delay the structure, it delays everything hanging off it, and the list of what hangs off it is the table above.

Two things have to exist before any of it, and neither of them is an object: the classes with their characteristics, and the catalogues the codes sit in. Both are easy to leave until the objects are in, and both cost more once they are. A characteristic is where a duty or a pressure lives; a code is what makes a damage countable. Create either afterwards and the population already exists, so it is a second pass over every object rather than a field on the first.

Three places, and they are the same three every time, because they belong to the model rather than to a plant.

Equipment sits under equipment

A piece of equipment can hang under another piece of equipment, so that layer references itself. Sorting the rows parent-first settles it only while you know the numbers in advance; where the system assigns them, the parent has no number until it is loaded, and one pass cannot satisfy that.

Create the objects flat, then install them. Installation as its own step is not a workaround: an installation has a start and an end, so it is a record about a period and not a field on a master record. The same step then carries equipment into functional locations and equipment into equipment, which is one piece of logic instead of two.

The object nobody is building

The work you carry over names objects. Some of those objects will not be in the new structure: they were merged into one, split into three, or they were never separate things and somebody made them separate to have somewhere to book.

Each one is a decision with exactly three answers. Create the object, re-point the record onto whatever replaced it, or leave the record behind. There is no fourth answer, and the question arrives once per object rather than once per project — which is why it is worth counting them while the count is still a number and not a queue.

The date nobody supplied

An installation is dated. So is a notification, an order, a reading, a confirmation. Where the source carries no date, a load supplies one, and what it usually supplies is the day it ran.

A register in which every machine arrived on the same afternoon reads as obviously wrong to a person and as fact to every report. Decide what an absent date becomes before the load, and prefer a date that is visibly a placeholder to one that is plausibly real.

A functional location is identified by its own label, so the key you designed is the key you get. Equipment numbers are commonly assigned by the system instead, and then the number in your source list is not the number in the register.

Everything after that layer references the new number: the installation, the classification, the notifications, the orders, the readings. So the table mapping the old key to the new one is a deliverable, not a by-product. It has to be rerunnable, it has to be the only one, and it has to outlive the people who ran the load.

The old key also has to land in a field on the record itself, or that table is the sole route back. Which field is a decision somebody makes once. The equipment master offers more than one plausible home — an inventory number, a technical identification number, a sort field — and none of them is the obvious default, so the cost of not choosing is that two loads choose differently.

A specification that cannot be turned into a count cannot be signed off. It can only be agreed with, which is a different act and leaves no record of what was checked.

Every layer above ends in a list. Locations that came out at the top of a tree. Equipment installed nowhere. Notifications with no code on them. Those lists are the acceptance criteria, and they have one property a written description does not: somebody can run them again next year and get a number that means the same thing.

Write each list down before the load rather than after it. A list written once the data exists gets fitted to the data — not dishonestly, just by whoever is looking at both at the same time.

And the signature belongs to whoever is wrong if the register is wrong. That is the planner raising work against the structure, and the person who has to walk up to the object and find it labelled the way the screen says. A project team cannot hold that role: a project ends, and the register is still there.

Master data carries the present tense. Where a machine is now is a field on the record. Where it has been is the run of installation periods behind it, and those are there only if somebody loaded them.

Closed work is the same. A notification and its order are records against an object rather than attributes of it, so a register can load cleanly and arrive with nothing booked against anything: every object right, every history empty.

Starting empty is a legitimate decision, and often the right one. It stops being legitimate the moment nobody writes it down, because the first report comparing two years of failures comes back short and nothing on the screen says whether the plant improved or the history simply stops there. Put the cut-over date where that report is read, not in a document somebody filed.

What does carry over does not improve on the way. A notification whose damage was typed into the long text arrives with the damage in the long text. Moving a record does not create the code it never had, and the count you wanted is still not available — now against two systems instead of one.