Writing a specification: adapt every clause to the project, value by value.

AI can help prepare the layout and a first draft of the clauses in a specification. How much time you save depends on the sources you provide and on the checking the draft still needs. The real risk lies elsewhere: a clause carried over from an earlier job, holding a value that no longer applies to this one. This article follows the method set out in AI for Architecture and Engineering: write the specification from the practice’s own clause library, have the tool sort every clause, then check that the specification agrees with the drawings and the priced breakdown before the tender documents go out.

01 · Weed out values inherited from another job

The book starts from a fictional example: the tender documents for a secondary school refurbishment, nine packages, nine specifications, issue in three weeks. The “internal partitions” clause in the library comes from a school handed over two years earlier. It specifies a fire resistance period chosen for that school’s occupancy category. The school now being designed changed category during the design stage.

The clause looks reusable as it stands. It is not. The value has to come from this project’s compliance register, not from the earlier job. A value like that stays plausible, which is exactly why it survives a quick read. It can then turn into a query during tendering, a qualification in a bid, or a variation during construction.

02 · Classify, then adapt the clauses, package by package

A specification is written neither from nothing nor by copying one job onto the next. It is written from an in-house library: clauses approved by the practice and kept up to date. Every clause the package needs falls into one of three categories:

• STANDARD: reused as it stands, because nothing in the project changes it;
• ADAPTABLE: reused, then adjusted to the project data (performance, dimensions, interfaces);
• PROJECT-SPECIFIC: written for this project, because no library clause covers it.

Open one conversation per package. Load the package’s clause library into it, together with the project requirements matrix (the one the book builds from the brief, in chapter 8). Then make this request, here for the drylining and partitions package:

Here is the clause library for the drylining and partitions package [file] and the project requirements matrix [file]. For each clause the package needs, propose a classification: STANDARD / ADAPTABLE / PROJECT-SPECIFIC.
For each ADAPTABLE clause, list the values to be adjusted and the source of the new value. Flag any value in the clause that appears to come from another project.

What you have to check: the classification is a proposal, and you go back over it clause by clause. The tool may spot an inherited value, but it may just as well let one through, especially when it stays plausible. Every value that commits you is checked against its source: compliance register, requirements matrix, design calculation.

The order of work is the same for every package:

1. The list of clauses and their classification. While you are there, check that every requirement in the matrix that concerns the package is covered by a clause.
2. The drafting: the tool writes the adaptable clauses and proposes a first draft of the project-specific ones.
3. The review: you read clause by clause and check every value against its source.

Once the package has been read through, save the specification with its revision and file it in the project. If the review turns up an error in a library clause, report it to whoever maintains the library. The next project will not inherit it.

For a first draft with no library to work from, plate 46 in the book shows another approach, on a surface water drainage system: every requirement is tied to an element of the works and to the evidence expected, missing data is marked “[to be fixed]”, and no standard is cited unless the reference has been provided or verified. The text ends with the list of decisions still to be made.

03 · Prepare the right documents and the right instructions

The quality of the specification depends on what the tool reads. Chapter 4 of the book sets the job up in a few steps:

• The account. Upload nothing until you know whether your professional account is cleared for project documents, and whether its contract rules out training on your data (chapter 3). On a sensitive job, that decision is taken with management, before the first conversation.
• One project per job, with a single version of each document. If two revisions sit side by side, the tool may cite the older one without saying so.
• Instructions: use only the project documents, cite the document and the page, and write “not found in the documents provided” rather than filling the gap.
• One conversation per subject: a specification package, the details, the cross-checks before issue.

Anonymising matters mainly for copies that leave the job — a specification that worked well, filed into the library as a model, for instance. The original stays in the job’s project, on an approved account.

04 · Cross-check the specification against the other tender documents

Every document can be right and the set still inconsistent. Before issue, the book runs four cross-checks:

• specification against drawings: does the text require what the drawing shows?
• specification against the priced breakdown: does every requirement have its line, and every line its clause?
• drawings against drawings: same revisions, same references, same dimensions?
• documents against sequencing: can what is being asked for be built in the sequence announced?

On the fictional school, the tool flags, for example, a clause referring to “drawings revision B” when the drawings have been issued at revision C, and fume cupboards connected in the specification with no connection line in the priced breakdown. Every discrepancy is checked by opening the two documents cited. A short list, or an empty one, proves nothing: ask the tool for the list of documents it analysed, with revision and page count, and compare it against the production register.

The book adds a “contractor’s read”: looking for what is described but not priced, priced but not described, quantified with no basis, or left between two packages. The link between the electrical panel and the fume cupboard, which neither the electrical package nor the laboratory package allows for, is the classic example. For quantities taken from the model, see AI for take-off and estimating. For reviewing specifications produced by others, see AI for the design review.

05 · Keep control of the technical choices

The tool classifies, drafts, compares and flags. What remains yours:

• the final classification of the clauses;
• the values that commit you;
• the scope boundaries between packages;
• for every gap: obtain the data, correct it, or have it explicitly decided before issue;
• the authority to issue.

Chapter 22 of the book reports a real commission: AI drafted a specification by work section from the design decisions. After the fire engineering consultant’s advice, the engineer rejected one of those decisions, and the smoke curtain was taken up to the slab. AI kept the revisions and the trail of decisions. The technical choice stayed with the engineer.

On time saved, the book offers no measurement. Its scenario rests on assumed durations, and the final professional validation keeps the same duration with or without the tool. Measure your own durations across several packages before drawing a conclusion. In your records, write down the real chain: prepared by the tool, checked by one person, approved by another. The tender documents carry your name.

The same principle applies on the other side of the enquiry: see AI for the tender technical submission.