The PLOT method is trivial. The model underneath it is not. Here is what a construction model is, who owns it, what engineering has to deliver for it to be possible at all — and what to do when what you inherit is not ready.
The PLOT method is simple on purpose. A plot is a place, a date range and an owner. A foreman can learn it in fifteen seconds, and any version of it that needs a two-day course has already failed.
That simplicity is honest, but it hides where the real work is. A plot’s place is a location in a model. If that model is confusing, out of date, or quietly wrong, then every plot inherits the problem, and the register becomes a well-organised way of being mistaken together.
So before the method, before the register, before anyone appoints a PLOT master, there is one dependency. I call it the construction model, and it is the key factor for everything else in this series.
1. What a construction model is
A construction model is a derivative of the engineering model, produced for the people who have to build it.
Three things it is not, because each is a common misreading:
- It is not an as-built. An as-built describes what exists after the fact. A construction model describes the current intent, now, while it still matters.
- It is not a fabrication model. Fabrication models go deeper for a shop. This one goes shallower, deliberately, for a site.
- It is not a second model maintained by hand. Anything maintained twice will disagree with itself. It is a derivative — produced from the engineering model, and reproduced when that model or the site requirements change.
In the ideal case it is nothing more than the goal itself: the ultimate scope of the project, clear and correct, in a form a foreman can stand in front of without confusion.
And a fourth thing it is not, which is the point of this article: it is not something you receive from engineering. The construction model is the PLOT master’s own deliverable, produced at site, out of what engineering delivers. That defines the architecture of this article, because the two halves are answered by different people holding different knowledge.
What engineering owes is completeness and attribution. Only that, and all of it:
- Everything modelled, once. The scope stated in geometry — no object missing, no object present twice.
- Attributed properly. Every object carries the tag it is known by, and that tag joins to the systems that already track the physical thing.
- Nothing binding left in drawing space. A note, a condition of installation, a sequence, a dimension the site is accountable for — carried back onto the object it governs, as metadata.
What the PLOT master does with it, at site, is three operations:
- Federate the parts into one picture and one coordinate system.
- Decide what is meaningful. Remove what the site does not need to see, reduce to a bounding box what it needs only as a shape, keep what turns out to be useful — and revisit that judgement as the work moves.
- Connect the metadata to the systems that already track the physical world.
2. What the site does not need to see — and who decides
Open an engineering model on an industrial project and a large part of what you see is not the plant. It is the reasoning that produced the plant.
A volume standing for an escape route. An explosion radius. A maintenance envelope, a clearance zone, an analysis body, an alternative that was considered and set aside. These are not clutter — that’s the reasoning why a beam must be at that elevation, why a pipe takes that exact path.
But the moment when an engineering decision is final, these carry only confusion for site. A foreman searching for the steel he must erect this week should not be searching through the argument that produced it.
Reasoning entities belong to engineering. They are engineering’s property and engineering’s business, and nothing here says they should not exist — the next change or inter-discipline review will need them all.
The question is what actually matters for site in the coming weeks.
Engineering cannot answer it, because the answer changes with the stage of the work. An escape route is clutter during erection and becomes the subject of the meeting at pre-commissioning. A maintenance envelope is worth seeing before somebody builds a scaffold straight through it. A clearance zone means nothing to a steel crew and everything to the people testing the valve. So the decision about what is meaningful and what is noise belongs to the PLOT master, standing close to the people who use the picture, and it is revised whenever the site’s questions change. It is a judgement made continuously at one end, not a gate installed between two organizations.
What makes that arrangement safe is an asymmetry worth stating plainly. Taking something out of a view is cheap and reversible. Absence is neither. If an object was never modelled, or an attribute never arrived, then somebody on site has to rebuild it from drawing details — days of work, under time pressure, done by the people least equipped to be authoring engineering content, and wrong often enough to be dangerous. That is the whole reason the demand on engineering is complete and attributed rather than clean.
Duplicates are the exception, and they are more dangerous than they sound. The same physical object modelled twice — by two disciplines, or by an export that ran twice — is worse than a missing object. A gap is visible. A duplicate makes a count wrong, makes a status ambiguous, and makes two people believe they are talking about the same thing when they are pointing at different objects with the same name. That one cannot be solved by hiding, because deleting the wrong copy is authoring engineering content, not filtering a view.
So the first property of a construction model is subtractive, and it is the one nobody gets credit for: it contains the scope, once, and nothing else. The once is engineering’s to deliver. The nothing else is the PLOT master’s to decide.
3. What has to be carried across
The 3D model is usually a contract deliverable. Its data layer is not.
The model is named in the deliverables list, issued and paid for. What the requirements almost never define is what must be attributed, to what schema, checked by whom, and terms of rejection by site.
Problem which should not exist in theory, but appears in reality. People do shortcuts to issue IFC (Issued For Construction) drawings faster, it is tempting to change a dimension value on a drawing, instead of updating the model, add some notes on canvas, instead of embedding into the model body.
Carrying it back — into the model, as metadata on the object it governs — is part of the deliverable, not a favor. If a crew is expected to work from a shared picture, the picture must hold what the crew is accountable for.
Removing content is filtering, and is the PLOT master’s duty. Deciding what a note means, and attaching it to the right object, is authoring — it needs the authority of the person who wrote it. Ask a site to do it and you have asked a site to reinterpret an engineering document under schedule pressure.
Add the ordinary entropy of a large information supply chain: revisions in circulation next to their own replacements, export errors, a typo that breaks a tag match, a link that resolves to nothing. None of this is crucial on its own. But this corrupts data drop by drop, through many files, over years, across organizations.
4. Federated, and joined to the systems that already exist
A construction model is not delivered to you. It is assembled.
The parts come from different vendors, different disciplines, different delivery cycles, in different formats, on different revision clocks — and they have to sit in one coordinate system and behave as one picture. That federation is ordinary BIM work, and it is exactly why this deliverable belongs to somebody with a BIM background rather than to enthusiasm.
What turns the result from a picture into an instrument is the metadata. A tag on an object is a join key. Where the tag is correct and unique, the model can be connected — directly — to the systems that already track the physical world:
- material control and delivery status,
- logistics and yard management,
- ERP,
- and the Excel registers that run more of every project than anybody puts in a presentation.
I include the spreadsheets deliberately. Excel registers are real, they are often the only place a particular truth is written down, and treating them as something to be abolished is how software people lose a room full of experienced site staff. The construction model does not replace any of these systems. It gives them somewhere to stand. You do not migrate the material tracker into the model; you make the tag match, so that the two can be joined and a crew can see readiness in the same place they see geometry.
A spreadsheet joined to the model is a perfectly good source; what a spreadsheet cannot be is the register of plots, which needs coordinates, a shared picture and live conflicts — the distinction I set out in Born Open. All of this is not somehow unknown. The discipline of treating model content as data to be queried rather than geometry to be admired is the central argument of Data-Driven Construction, and the debt is worth stating plainly: DDC frees the data that already exists.
This is where the argument turns from cost into opportunity. Once the geometry is clean, the scope is stated once, and the tags join to the systems that already exist, the digitalization of the construction site stops being a goal and starts being a harvest. Status by area. Progress in space. Material readiness where the work will happen. Visibility for site people far beyond what they can walk to. Those things stop requiring initiatives; they become queries.
And plots — the temporary layer, registered in place and time — become simply one more thing the foundation can carry.
5. In the ideal case, this is contractual
The version of this that works is not heroic. It is boring, and it is written down.
What belongs in the contract is not the construction model — that one is produced at site, by the PLOT master, and no contract can specify a judgement that has to be remade every month. What belongs in the contract is the input: a complete, properly attributed model, with nothing binding left in drawing space. Named in the information requirements, with acceptance criteria, priced like anything else that takes effort to produce. Not a kindness performed by the BIM team after handover, out of goodwill, with no time allocated and no authority to refuse what arrives.
So the PLOT master’s job here divides cleanly, and the division is worth saying out loud because it decides who can be blamed for what: validate the input, produce the output. Everything in section 2 — what to hide, what to reduce to a box, what to keep for the next stage — is production, and it is theirs. Everything below is validation, and it is a check on somebody else’s delivery. That check has two halves, and most projects only ever do the first.
The visual half. Open it. Look at it. Can a person find their area? Is the picture legible at the zoom level a foreman actually uses? Is the scope there, once? Is what you are looking at recognizably the plant that is being built?
The data half. The metadata layer cannot be inspected by eye, and this is the point people miss. Wrong geometry looks wrong; wrong metadata looks like nothing at all. It has to be checked with data analysis: tag completeness and uniqueness, objects with no tag, tags with no object, duplicates, orphan references, coordinate consistency across federated parts, revision agreement between what the model says and what the document register says, and a match against an ERP or material extract to see whether the join key actually joins.
This is analysis work — queries and comparisons over the model’s data, not a walkthrough — and it is the single highest-value hour anybody spends on a construction model.
One condition makes the whole thing real: acceptance must be refusable. A deliverable that cannot be rejected is not a deliverable, it is a formality. That is the narrow authority I argued for in The PLOT Master: the right to rule on whether the container meets the requirements the contract already specifies — and to refuse “take a look at the drawing” as the answer for a model that does not. Never a ruling on the engineering content itself. That belongs to engineering, exactly as how to erect a scaffold belongs to the scaffolders.
6. And now the real starting position
Everything above describes the ideal. Here is the situation most people reading this are actually in.
The contract is signed. It said nothing about model completeness, nothing about attribution, and nothing about carrying drawing-space information back. The maturity you have inherited is far from what section 5 describes. The clock is running, crews are mobilizing, and nobody is going to reopen the information requirements for you this year.
That is normal, and it is not a reason to wait. Six honest rules for that position:
1. Do not aim for complete. Aim for trustworthy where people act. A construction model does not have to cover the plant. It has to be right about the things people will attach decisions to — areas, access, elevations, the tags crews claim their work against. Complete coverage is a goal. A picture that is correct where people stand is a deliverable, and it is achievable this quarter.
2. Start where the plots will land. Not with the discipline that has the best model. With the areas where work is about to happen.
3. Never repair engineering’s data silently. This is the rule. Hiding is not repairing. Removing an object from the construction view, or reducing it to a bounding box, changes nothing about the source and can be undone in a minute — that is production, it is yours, do it freely. Changing what an object says — its tag, its elevation, its revision, which of two duplicates is real — is authoring, and it is not yours. Do that twice and the two models have begun to diverge permanently. Fix it at the source, or mark it and escalate it. Do not patch in silence.
4. Show what you do not trust. A model with an area visibly marked as unverified is safer than a model that looks uniformly confident. People calibrate to what they are shown. Uniform confidence in a model that has soft patches is how a picture becomes a trap.
5. Keep the record of every defect you find. Each mismatch, each superseded revision still in circulation, each tag that does not join — logged, escalated, dated. Not to build a case against anybody. The log is documented evidence that will incentivize the organization to put the model requirements into the next contracts, priced and named. This is how the ideal case in section 5 becomes reachable — some project later, with proof.
6. Expect the errors to surface during construction and treat that as the system working. Construction is when somebody finally has to act on the detail, so construction is when the detail’s problems appear. A model trusted absolutely is dangerous. A model whose errors surface fast is an asset.
7. Why this is the key factor
I have argued that the PLOT method is deliberately trivial, that a plot is three pieces of information, and that the whole practice can be taught in a quarter of an hour. All of that is true, and it is why the method can spread.
But a method that light needs a foundation that solid. The register does not create truth; it places claims on top of a picture and lets people see each other. If the picture is right, PLOT is close to free. If the picture is wrong, PLOT is a fast and confident way to be wrong together.
So if a site is going to fail at this, I can tell you now where it will fail. Not at the meetings. Not at the foremen — they adopt anything that helps them by Tuesday. It will fail because nobody owned the construction model, and after a few weeks the picture stopped matching the ground.
8. As a conclusion
If your project already names model completeness and attribution as deliverables, with acceptance criteria and the right to reject — I want to see that clause. It is the most useful paragraph in your contract and almost nobody has it.
If you have inherited the situation in section 6 and found a way through it that is not heroics, I especially want to hear it, because that is the section that will help the most people and it is the one written with the least certainty.
And if you are about to write the information requirements for a new project, this is the cheapest moment there will ever be. Everything in section 5 costs a paragraph now, and a year of argument later.
The method is simple. The register is simple. The model is the work — and it is the part that makes all the rest of it possible.