Mockup Review

A mockup is the only chance to see the assembly built by the people who will build it, with the materials they will use, before the decision costs a facade. It is usually wasted twice: once by reviewing it against appearance instead of against the documents, and once by never writing down what it established.

Workflow

Step 1. Establish what this mockup is for, before looking at it

Ask, in one message:

1. What does the specification say this mockup has to demonstrate? Quote it.
2. Visual, performance, or both? If performance, which tests, and have they been run?
3. Which shop drawings was it built from, and were those reviewed?
4. What did the design team want to learn from it? List the open questions.
5. Is this mockup the accepted standard for the work, or a trial?
6. Who was present, and when?

The list in question 4 matters more than it looks. A mockup reviewed without it becomes a hunt for defects, and the questions the mockup was actually built to answer go home unanswered.

Step 2. Observe in a fixed order

Appearance last, deliberately. Work the order:

1. What is behind. Control layers, where visible or where a section was left open. If nothing was left open, record that the mockup cannot demonstrate them and that this was a decision.
2. Junctions and terminations. Every place the assembly stops or meets something else. Same list the design skills use: head, jamb, sill, base, top, corners, penetrations, movement joints.
3. Sequence evidence. What the build order was, and whether the laps run the way the drawings show. Ask the trades; they will tell you, and the answer is often not what the drawing shows.
4. Workmanship in the field. The repeating condition, done at the pace it will be done at.
5. Appearance. Colour, alignment, reflection, how it reads at distance and in different light.

Record each observation with where it was seen and what document clause it relates to, or no clause identified.

Step 3. Sort every observation into three outcomes

Observation	Where	Clause	Demonstrated / Failed / Not addressed

The third column is the one that gets skipped and it is the most useful. Not addressed means the mockup did not put the question to the test, which is different from passing. A mockup with no rain on it has not demonstrated water tightness, however good it looks.

Count each category and report the counts.

Step 4. Record what has become the standard

If this mockup is the accepted standard for the work, say precisely what about it is the standard and what is not. Colour range, joint appearance, workmanship level, sequence: name each explicitly.

Anything not named here will be argued about later, and the mockup will be gone or weathered by then. State how the standard is being preserved: retained on site, photographed, sampled.

Step 5. Report

• The three counts, with not addressed first.
• Each failed observation with what was seen and what the quoted clause required.
• Each not-addressed item with what it would take to address it, and whether a second mockup or a test is proposed.
• What has become the accepted standard, itemised.
• What the design team's open questions got answered, and which did not.

Close with the standing limits: this is not acceptance, no criteria were supplied beyond what was quoted, and performance claims rest on the testing agency's report and not on this review.

Step 6. Save, if asked

Ask whether to write the review to a file and where, and write it directly, tables and photograph references included.

Rules

• Never supply a tolerance or an acceptance criterion. They come from the specification, quoted.
• Establish the purpose before the first observation. A review that starts at the mockup starts in the wrong place.
• Appearance is reviewed last, every time.
• Report not addressed before failed, and never fold it into passed.
• Every observation carries a clause reference or the words no clause identified.
• Never write the words accepted or rejected. That is the Architect of Record's act.
• Say on every run that performance rests on the test report, not on this.

Anti-patterns

• Reviewing the mockup against the rendering.
• Treating an absence of visible defects as a demonstration of performance.
• Reviewing a mockup built from shop drawings nobody reviewed.
• Recalling a joint tolerance or a colour range because the figure is common.
• Letting the trades' description of the build sequence go unrecorded because the drawing shows something else.
• Ending without naming what has become the standard.
• Quoting a specification clause from memory rather than from the section supplied.
• Proposing the fix inside the review.

Resources

None. This skill is one file. Output is written directly at the path you choose.