The Pre-Issue Technical Review: A Technical Director's Sign-Off Checklist
What to check, in what order, who does it and how to record the result
The pre-issue review is the last place a defect can be stopped cheaply. Done as a proofread, it catches typing errors. Done as a comparison, it catches the contradictions, orphan references and withdrawn standards that cost money after tender. This guide sets out the seven checks in order, who should carry them out, how to plan the time and how to record the sign-off so it can be relied on later.
A fixed order of checks, a reviewer who did not write the document, and a record that shows what was checked and who authorised the issue.
What is a pre-issue technical review?
A pre-issue technical review is the last check before a specification or drawing set leaves the practice. A reviewer compares the documents against each other, against the brief and against external standards, and records what was checked and who accepted the result.
Other guides in this series explain why defects reach issue. Why Specifications Fail the Same Way in Every Practice traces them to practice-level causes, and Common Specification Defects at Contract Issue lists the defect types and how often they appear. This guide does not repeat either. It covers the procedure that sits at the end of the process and stops those defects leaving the building: what to check, in what order, who checks, how long it takes and how the sign-off is recorded.
The key distinction is between a proofread and a comparison. A proofread reads one document from front to back for sense. A comparison puts two documents side by side and asks whether they say the same thing. Only the second finds an orphan reference, a door that has three fire ratings, or a standard that has been withdrawn. Most practices already have a review step. The change a technical director usually has to make is from reading to comparing.
Proofread
Reads the clause for sense and style. Finds typing errors and unclear sentences. Cannot see the schedule, the plan or the standard's status.
Comparison
Puts the clause beside the schedule, the plan and the standards list. Finds the value that disagrees, the tag that has no clause and the reference that goes nowhere.
Both have a place. Only the comparison finds the defects that cost money after tender.
What the review is not
It is not a design review. The reviewer is not asked whether the design is good, and it is not a substitute for consultants checking their own work. It is also not a way of passing responsibility to the technical director. The author remains responsible for the content, and the reviewer is responsible for the check. The record should make both clear.
What should a pre-issue review check, and in what order?
Check in seven steps, in this order: identity, extent, performance, references, standards status, decisions and responsibility. The order matters because each step makes the next one meaningful.
The sequence runs from the simplest and most mechanical comparison to the most judgement-heavy. Identity comes first because every later comparison depends on documents using the same names for the same things. If the door on the plan is D-14 and the schedule calls it DR-014, extent and performance checks will keep failing for a reason that has nothing to do with the design.
- 01
Identity
Do tags, type references and titles match across drawings, schedules, the model and the specification?
- Compare
- Drawing tags, schedule types, clause titles
- Typical failure
- Two names for one element
- 02
Extent
Is every tagged element covered by a clause, and every clause located on something real?
- Compare
- Schedules against clauses, both ways
- Typical failure
- A clause for a system the project does not have
- 03
Performance
Does every repeated value (fire, acoustic, thermal, structural, accessibility) agree wherever it appears?
- Compare
- Value in schedule, drawing note and clause
- Typical failure
- Three fire ratings for one door
- 04
References
Does every cross-reference to a clause, drawing, appendix or standard resolve?
- Compare
- Each 'refer to' against its target
- Typical failure
- Reference to a clause that was renumbered
- 05
Standards status
Is every cited standard current, correctly titled and appropriate to the project?
- Compare
- Standards list against published status
- Typical failure
- Withdrawn or superseded standard carried forward
- 06
Decisions
Is every option resolved and every TBC either closed or owned and dated?
- Compare
- Decision log against the text
- Typical failure
- The team knows the answer but the clause says TBC
- 07
Responsibility
Is each design portion assigned once, with inputs, interfaces and deliverables, and does the clause match the matrix?
- Compare
- Responsibility matrix against clauses and contract documents
- Typical failure
- Specialist design expected but not assigned
The first four are mechanical and can be partly automated. The last three need judgement and cannot be done without the person who knows the project.
Identity
List every tag that appears on the drawings and in the schedules, and confirm that each one appears in the specification. Do the same in reverse. A mismatch is not always an error, but it must be explained. The check is quick, and fixing a name before the other comparisons saves the reviewer a great deal of confusion.
Extent
Take each scheduled type and find its clause. Take each clause and find the element it covers. Elements without clauses and clauses without elements are the two symptoms. Leftover master content is usually found here, as clauses for systems the project does not have.
Performance
Choose the performance values that carry the most risk: fire resistance, acoustic performance, thermal values, structural loads, accessibility dimensions and security ratings. For each, list every place it appears and compare. Where the value appears in more than one place, name the source document and replace the repeats with references. The check is worthwhile because performance values are expensive to get wrong and easy to compare.
References
Resolve every cross-reference. This is dull work, and it is where software is most useful. A reviewer reading a 300-page specification will not reliably catch a reference to clause 12.4 if the section was reorganised. A tool will, every time.
Standards status
Check that each cited standard is current, correctly titled and still appropriate. Check the edition strategy as well: some clauses cite a dated edition on purpose, others cite undated references so that the latest edition applies, and the choice should be deliberate. Where the project is in England and a higher-risk building, make sure the standards cited agree with the approved documents relied on in the Building Regulations submission. Each practice should set its own policy on dated versus undated references.
Decisions
Take the decision log and check that each closed decision is in the document and each open item has an owner and a date. A TBC the team can answer from memory should be closed before issue. A TBC that cannot be answered should be converted to a stated provisional item with a defined scope, so that tenderers can price it. TBCs in Specifications at Tender sets out the consequences of leaving them open.
Responsibility
Compare the specification with the design responsibility matrix and the contract documents. Every descriptive row needs a performance clause, and every contractor's design portion needs a brief with inputs, interfaces and deliverables. This is the check most often skipped, because it needs the matrix to exist. The design responsibility matrix guide explains how to build one.
Who should carry out the review, and how long does it take?
A reviewer who did not write the specification should carry out the checks, usually the technical director or a delegate with enough authority to stop an issue. Time depends on the size and complexity of the project, and the practical way to plan it is to set an allowance per issue and measure it.
Independence is the main requirement. An author reviewing their own work reads what they meant, not what is there. In a small practice, the technical director or an experienced colleague on another project is usually the best reviewer. In a large practice, a technical review team or a rota of senior technical staff gives consistency across projects.
The reviewer needs three things: the complete issue set, access to the models or schedules and the authority to hold the issue. Without the last, the review becomes advisory, and findings are overridden by the programme.
Planning the time
No published figure applies to every project, and this guide does not invent one. The sensible approach is to set a planning allowance per issue, record the actual time on the first few reviews, and adjust. As a rule of thumb, the mechanical checks (identity, extent, references) take less time once they are partly automated and the judgement checks (performance, decisions, responsibility) take the most. Each practice should set its own planning allowance after three recorded reviews.
- 1
Issue minus 10 working days: Freeze
Author stops editing. Decision log closed or owned. Schedules and specification frozen at the same status.
- 2
Issue minus 8: Mechanical checks
Identity, extent, references and standards status are run. Findings returned to the author.
- 3
Issue minus 6: Judgement checks
Performance, decisions and responsibility are reviewed with the project architect and consultants.
- 4
Issue minus 3: Fix and re-run
Findings are corrected. The comparisons are run again on the corrected set.
- 5
Issue minus 1: Sign-off
Reviewer records the result. Technical director or project lead authorises issue.
The day counts are an example of a working pattern. Set them to the practice's own programme, and protect the freeze.
The most common way a review fails is that it starts the day before issue. By then the author has no time to fix findings, and the reviewer is under pressure to pass the set. A fixed review window, agreed in the project programme, changes that. If the programme cannot accommodate the window, say so openly and record the reduced check that was carried out instead.
How should sign-off be recorded?
Record the sign-off on a one-page review record kept with the issue: what was checked, what was found, what was fixed, what was accepted as a known issue and who authorised the issue. A record that can be read in two minutes will be used. A long one will not.
A sign-off record serves two purposes. It shows, during the project, that the check took place. It also gives the practice evidence if a dispute arises later about what the information was at the date of issue. Keep it factual and avoid language that overstates the check. A record that says "checked" is weaker than one that says "extent check: scheduled types compared with clauses in both directions, with the number unmatched, resolved and accepted stated".
Scroll horizontally to view all columns.
| Field | What to record | Example entry |
|---|---|---|
| Project and issue | Name, number, document set, status code and revision | Project 2214, specification Rev P03, status for tender |
| Date and reviewer | Date, reviewer's name and role, and whether independent of the author | Reviewer is the technical director, not the author |
| Checks run | Each of the seven checks, with the method and the documents compared | Identity and extent: schedules against clauses, both ways |
| Findings | Number found by check, and how many were fixed | Performance: number found and number fixed |
| Accepted issues | Anything left open on purpose, the reason, the owner and the date it will be closed | Roof fixing pattern: contractor's design, due by tender return |
| Not checked | Anything outside the scope of the review | Consultant drawings not available for comparison |
| Authorisation | Name and date of the person who authorised the issue | Project director, 12 October |
The entries are illustrative. The point is that a reader can see what was done and what remains, without asking the reviewer.
Where the record lives
Keep the record with the project information, not in the reviewer's email. On a higher-risk building the record forms part of the information that supports the golden thread, which is covered in the golden thread guide. On any project, filing it with the issue makes it easy to find when the contractor, client or insurer asks.
Handling disagreement
Sometimes the author and the reviewer disagree, or the programme pressures an issue with unresolved findings. The rule should be set in advance: the technical director decides, and the decision is recorded together with the risk accepted. This protects the practice more than a quiet override does.
What happens to findings, and how do you improve the process?
Classify findings by severity, fix the ones that block issue, record the rest and feed the pattern back to the master. A review that only corrects the current project does not stop the same defect on the next one.
Three severity levels are enough. A blocking finding must be fixed before issue: a contradiction in a performance value, a reference that goes nowhere, a withdrawn standard in a regulatory clause. A fix-before-tender finding can be corrected in a later issue, with the tenderers told. A note is an observation, such as a clause that could be shorter. Reviewers who record every finding at the same weight make it hard for the author to see what matters.
- Blocking findings are fixed and the comparison re-run on the corrected set.
- Accepted issues have an owner, a date and an entry in the issue record.
- Findings that repeat across projects are logged against the master clause that caused them.
- The review record is filed with the issue.
- Time taken is recorded for the next planning allowance.
The last two items turn the review into a learning loop. If the same defect keeps appearing at review, the cause is in the master or the handoff, not in the author. The guide to keeping the office master up to date covers how findings feed the master, and RIBA Stage 4: What Technical Design Must Cover Before Tender shows where the review sits in technical design. After issue, specification change control keeps later changes under the same discipline.
Questions technical directors ask about pre-issue technical reviews
What is a pre-issue technical review?
A comparison check carried out before a specification or drawing set is issued. The reviewer compares the documents against each other and against standards, and records what was checked and who authorised the issue. It is different from a proofread, which reads one document for sense.
What should a pre-issue review check?
Seven things, in order: identity, extent, performance, references, standards status, decisions and responsibility. The first four are mechanical comparisons, and the last three need judgement from someone who knows the project.
Who should carry out the pre-issue review?
A person who did not write the document, with the authority to hold the issue. In most practices that is the technical director or a delegate. The author stays responsible for the content and the reviewer for the check.
How long does a pre-issue review take?
It depends on the size of the project and how much of the checking is automated, so the practice should set its own allowance and measure it over the first few reviews. The review should be scheduled as a window ahead of the issue date, not as a final-day task.
How should the review be recorded?
On a one-page record kept with the issue: the checks run, findings and fixes, accepted open items with owners and dates, anything not checked, and the name of the person who authorised the issue.
Can software do the pre-issue review?
Software can do the mechanical comparisons reliably, such as unresolved references, repeated values that disagree, tags with no clause and standards that are no longer current. A person still needs to judge performance, decisions and responsibility, and to authorise the issue.
Where Avoice fits
The mechanical half of the pre-issue review is exactly the kind of comparison software does without tiring.
In Avoice, the pre-issue Technical Review compares the specification against schedules and drawings and flags tags without clauses, clauses without elements, values that disagree and references that do not resolve. Practice Rules enforce values, standards and wording while the specification is being written, so fewer findings reach the review. The office master and clause library keep wording consistent, and standards sets define which bodies a specification may cite. The review record sits with the project, and the Compliance module and Project Record hold the golden thread for projects that need it.
The reviewer's judgement is not replaced. Performance, open decisions and design responsibility need a person who knows the project, and the technical director still authorises the issue.